Stripe זוכרת את בקשתך כאשר התגובה נעלמת
פסק זמן עלול להותיר קופה לא ודאית לאחר שהשרת השלים את הפעולה.
פסק זמן עלול להותיר קופה לא ודאית לאחר שהשרת השלים את הפעולה. הסבר זה של Under the Hood משתמש בחוזה האידמפוטנטיות המתועד של Stripe API v1 כדי להציג מפתחות פעולה יציבים, הפעלה חוזרת של תגובות שמורות, מגבלות פרמטרים ומקביליות, אופק השמירה ויישור תוצאות.
קראו את המהדורה הכתובה (אנגלית) ↗
מה מכסה הסרטון הזה
- אידמפוטנטיות מתייחסת להשפעה המיועדת של חזרה על פעולה. Stripe API v1 מוסיף חוזה מתועד של הפעלה חוזרת של תגובות שמורות.
- ניסיון חוזר של אותה פעולה לוגית משתמש באותו מפתח ובאותם פרמטרים. שמור את מפתח הפעולה על פני קריאות SDK נפרדות או הפעלות מחדש של יישומים; פעולה חדשה באמת זקוקה למפתח משלה.
- לאחר תחילת ביצוע נקודת הקצה, Stripe API v1 שומר את הסטטוס והגוף של הבקשה הראשונה, כולל שגיאות 500, ומחזיר את התגובה השמורה הזו בניסיונות חוזרים.
- פרמטרים שונו עם אותו מפתח יוצרים חוסר התאמה. כשלים באימות וניגודי ביצוע מקבילים אינם שומרים תוצאה אידמפוטנטית עבור ניסיון זה וניתן לנסות אותם שוב.
- Stripe שומרת מפתחות API v1 למשך 24 שעות לפחות ויכולה למחוק אותם לאחר מכן. הגבל ניסיונות חוזרים לא פתורים של רשת ל-24 השעות הראשונות, ולאחר מכן הפסק ויישר לפני חזרה על הפעולה.
- שגיאת 500 שמורה יכולה להמשיך להישמע לאחר שחזרו הקישוריות. הפעולה המקורית עלולה להיות בעלת תופעות לוואי; השתמש באובייקט הרלוונטי, בבקשת ה-Dashboard וב-webhooks כדי לקבוע את תוצאתה.
- API v2 משתמש בסמנטיקה שונה של הפעלה חוזרת. מפתח אינו קובע מסירה אוניברסלית בדיוק פעם אחת עבור דואר אלקטרוני, מלאי וכל פעולת מסד נתונים מקומית.
תמליל מתורגם
תורגם מהקריינות המקורית באנגלית. זמינות אודיו וכתוביות נשלטת על ידי YouTube.
האם פסק זמן ביטל את התשלום שלך?
0:00 אתה חושב שפסק זמן אומר שהתשלום שלך נכשל. השרת יכול לסיים בזמן שהתגובה נעלמת, מותיר את הקופה שלך מציגה בביטחון מוחלט כלום. מדוע ניסיון חוזר יכול לחייב שוב? כיצד Stripe זוכרת ניסיון? מתי עליך להפסיק לנסות שוב? וזכור פרט אחד מגעיל. שגיאה זכורה יכולה לשרוד את בעיית הרשת.
0:17 נחזור לכך. זהו The Daily Diff, מאחורי הקלעים.
מה מזהה מפתח אידמפוטנטיות?
0:21 אידמפוטנטיות פירושה שחזרה על פעולה יש את אותה השפעה מיועדת כמו ביצוע זה פעם אחת. מפתח אידמפוטנטיות מתייג פעולה לוגית אחת. גרסה אחת של API של Stripe מזהה את התווית הזו בניסיונות חוזרים ומפעילה מחדש תגובה שמורה. תאר לעצמך קניית קפה. Stripe משלימה את בקשת התשלום שלך, והתגובה אובדת בחזרה הביתה. הלקוח רואה גלגל טעינה. ייתכן שלבנק שלהם יש פרשנות מרגשת יותר. בקשה לא מוגנת של יצירה יכולה לחזור על תופעת הלוואי.
כיצד אותו מפתח הופך ניסיון חוזר לבטוח?
0:45 צרף מפתח ייחודי לפני הניסיון הראשון ושמור אותו לניסיונות חוזרים. אם היישום שלך מופעל מחדש, שמור את המפתח הזה עם הפעולה ב רשומות שלך. עבור API גרסה אחת של Stripe, ברגע שמתחיל ביצוע נקודת הקצה, הסטטוס והגוף של הבקשה הראשונה נשמרים. שלח שוב את אותו מפתח ואותם פרמטרים, ו-Stripe תחזיר את התגובה השמורה. הקפה נשאר במקומו בזמן שהקבלה שלו נוסעת שוב.
מה בדיוק Stripe שומרת?
1:07 הנה הניסוח המקורי של Stripe. ניסיונות חוזרים עם אותו מפתח מחזירים את התגובה השמורה, כולל שגיאות חמש מאות. התיעוד עושה יותר עבודה מעוזר הניסיון החוזר האופטימי שלך. הלקוח מקיש שוב. האפליקציה שלך מחליטה אם זה מחדש את הרכישה הממתינה או מתחיל רכישה חדשה. קפה חדש באמת מקבל מפתח חדש. מפתח רענן לכל ניסיון חוזר ברשת מביס את ההגנה.
1:27 פרמטרים שונים עם אותו מפתח מפעילים חוסר התאמה.
מה קורה כשהבקשה משתנה?
1:30 אם הפרמטרים נכשלים באימות, או שבקשה אחרת עם מפתח זה עדיין בביצוע, Stripe לא שומרת תוצאה אידמפוטנטית עבור ניסיון זה. ניתן לנסות שוב בקשות אלה. בקשה מהירה מקבלת התנגשות. אלה הם חוקי גרסה אחת. גרסה שתיים מתנהגת באופן שונה. כותרת לא יכולה להבטיח מסירה בדיוק פעם אחת בכל המערכת שלך. דואר אלקטרוני, מלאי ומסד הנתונים שלך זקוקים כל אחד לטיפול בכשלים.
1:52 המפתח מגן על הפעולה במסגרת התחום המתועד שלה. Stripe שומרת מפתחות גרסה אחת למשך 24 שעות לפחות ויכולה למחוק
כמה זמן בטוח לנסות שוב את התוצאה שנזכרה?
1:59 אותם לאחר מכן. מפתח שנמחק יכול לבצע בקשה חדשה. שמור ניסיונות חוזרים לא פתורים ביום הראשון. מעבר לכך, עצור ויישר את התוצאה המקורית. השתמש ב-exponential backoff וב-jitter כדי לתת לשרת מרחב נשימה. אחרת, ניסיונות חוזרים יוצרים תור מחוץ לבית קפה בוער. ספריות של Stripe מטפלות בניסיונות חוזרים, אך בדוק את ברירות המחדל של הספרייה שלך. השגיאה הדביקה הזו היא המלכוד.
מדוע שגיאה שנזכרה יכולה לחזור שוב ושוב?
2:20 תגובת חמש מאות שמורה ממשיכה להישמע לאחר שהקישוריות מתאוששת. הפעולה המקורית ייתכן שיצרה תופעות לוואי. פתור את תוצאתה באמצעות אובייקטים, ה-Dashboard ו-webhooks. מפתח חדש יכול לחזור על הפעולה. אם אתה מעדיף לקרוא את זה מאשר לשמוע אותי אומר את זה, הדיף נוחת בתיבת הדואר הנכנס שלך כל בוקר, בחינם ב-thedailydiff.dev, קישור למטה.
האם הייתי שולח כפתור ניסיון חוזר עם חוזה זה?
2:39 פסק דין, מאחורי הקלעים. SHIP IT. הייתי שולח מפתחות יציבים עם ניסיונות חוזרים מוגבלים ויישור, כך שלקוחות יקבלו קפה מבלי לממן את השכלת המערכות המבוזרות שלך. וזה הדיף להיום. אני ניקו מ-Axrisi. מזג באחריות.
מקורות
- Idempotent requestsStripe Docs
- Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
- Advanced error handlingStripe Docs
- HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor



