Stripe تتذكر طلبك عندما يختفي الرد
يمكن أن يؤدي انتهاء المهلة إلى ترك عملية الدفع غير مؤكدة بعد أن يكون الخادم قد أكمل العملية.
يمكن أن يؤدي انتهاء المهلة إلى ترك عملية الدفع غير مؤكدة بعد أن يكون الخادم قد أكمل العملية. يستخدم هذا الشرح "تحت الغطاء" عقد المعاودة idempotency الموثق لـ Stripe API v1 لعرض مفاتيح التشغيل المستقرة، وإعادة تشغيل الاستجابة المحفوظة، وحدود المعلمات والتزامن، وأفق الاحتفاظ ومطابقة النتائج.
اقرأ النسخة المكتوبة (الإنجليزية) ↗
ما يغطيه هذا الفيديو
- تتعلق المعاودة (Idempotency) بالتأثير المقصود لتكرار عملية ما. يضيف Stripe API v1 عقد إعادة تشغيل استجابة محفوظة موثق.
- تستخدم إعادة محاولة نفس الإجراء المنطقي نفس المفتاح والمعلمات. احتفظ بمفتاح التشغيل عبر استدعاءات SDK منفصلة أو عمليات إعادة تشغيل التطبيق؛ يحتاج الإجراء الجديد تمامًا إلى مفتاحه الخاص.
- بعد بدء تنفيذ نقطة النهاية، يحفظ Stripe API v1 حالة و"متن" الطلب الأول، بما في ذلك أخطاء 500، ويعيد هذه الاستجابة المحفوظة عند إعادة المحاولة.
- تؤدي المعلمات المتغيرة بنفس المفتاح إلى عدم تطابق. لا تحفظ أخطاء التحقق وتعارضات التنفيذ المتزامن أي نتيجة معاودة لتلك المحاولة ويمكن إعادة محاولتها.
- يحتفظ Stripe بمفاتيح API v1 لمدة 24 ساعة على الأقل ويمكنه حذفها بعد ذلك. حدد عمليات إعادة محاولة الشبكة غير المحلولة بالساعات الـ 24 الأولى، ثم توقف وقم بالمطابقة قبل تكرار العملية.
- يمكن أن تستمر استجابة 500 المخزنة مؤقتًا في إعادة التشغيل بعد استعادة الاتصال. قد تكون للعملية الأصلية آثار جانبية؛ استخدم الكائن ذي الصلة، وطلب لوحة المعلومات، وخطافات الويب (webhooks) لتحديد نتيجتها.
- يستخدم API v2 دلالات إعادة تشغيل مختلفة. لا يضمن المفتاح تسليمًا عالميًا لمرة واحدة بالضبط للبريد الإلكتروني والمخزون وكل عملية قاعدة بيانات محلية.
النص المترجم
مترجم من السرد الإنجليزي الأصلي. يتم التحكم في الصوت والتعليقات التوضيحية المتاحة بواسطة YouTube.
هل ألغى انتهاء المهلة دفعتك؟
0:00 تعتقد أن انتهاء المهلة يعني فشل دفعتك. يمكن للخادم أن ينتهي بينما يختفي الرد، تاركا عملية الدفع الخاصة بك تعرض بثقة لا شيء على الإطلاق. لماذا يمكن لعملية إعادة المحاولة أن تفرض رسومًا مرة أخرى؟ كيف يتذكر Stripe المحاولة؟ متى يجب أن تتوقف عن إعادة المحاولة؟ واضع في اعتبارك تفصيلًا سيئًا واحدًا. خطأ محفوظ يمكن أن يطول عمر مشكلة الشبكة.
0:17 سنعود إلى ذلك. هذا هو The Daily Diff، تحت الغطاء.
ماذا يحدد مفتاح المعاودة؟
0:21 الاستقلالية تعني أن تكرار العملية له نفس التأثير المقصود لعملها مرة واحدة. مفتاح الاستقلالية يصف إجراء منطقيا واحدا. إصدار Stripe's API واحد يتعرف على هذا التسمية عند إعادة المحاولات ويعيد تشغيل استجابة محفوظة. تخيل شراء قهوة. يكمل Stripe طلب الدفع الخاص بك، ويتم فقدان الاستجابة عند العودة إلى المنزل. يرى العميل مؤشر تحميل. قد يكون لدى بنكهم تفسير أكثر إثارة. طلب إنشاء غير محمي يمكن أن يكرر الأثر الجانبي.
كيف يجعل نفس المفتاح إعادة المحاولة آمنة؟
0:45 أرفق مفتاحًا فريدًا قبل المحاولة الأولى واحتفظ به لإعادة المحاولات. إذا أعيد تشغيل تطبيقك، فاحتفظ بهذا المفتاح مع العملية في سجلاتك. بالنسبة لـ Stripe's version one API، بمجرد بدء تنفيذ نقطة النهاية، يتم حفظ حالة ونص الطلب الأول. أرسل نفس المفتاح والمعلمات مرة أخرى، ويعيد Stripe الاستجابة المحفوظة. تبقى القهوة في مكانها بينما تنتقل إيصالها مرة أخرى.
ماذا يحفظ Stripe بالضبط؟
1:07 هذه هي صياغة Stripe الفعلية. إعادة المحاولات بنفس المفتاح تعيد الاستجابة المحفوظة، بما في ذلك أخطاء الخمسمائة. توثيق العمل أكثر من مساعد إعادة المحاولة الذي سميته بتفاؤل. ينقر العميل مرة أخرى. يقرر تطبيقك ما إذا كان ذلك يستأنف عملية الشراء المعلقة أو يبدأ عملية شراء أخرى. قهوة جديدة تمامًا تحصل على مفتاح جديد. مفتاح جديد لكل إعادة محاولة شبكة يبطل الحماية.
1:27 معلمات مختلفة بنفس المفتاح تطلق عدم تطابق.
ماذا يحدث عندما يتغير الطلب؟
1:30 إذا فشلت المعلمات في التحقق من الصحة، أو كان هناك طلب آخر بنفس المفتاح لا يزال قيد التنفيذ، لا يحفظ Stripe أي نتيجة متساوية لذلك المحاولة. يمكن إعادة محاولة هذه الطلبات. الطلب المتسابق يحصل على تعارض. هذه قواعد الإصدار الأول. يتصرف الإصدار الثاني بشكل مختلف. لا يمكن لـ header أن يعد بالتسليم مرة واحدة بالضبط عبر نظامك. تحتاج رسائل البريد الإلكتروني والمخزون وقاعدة البيانات الخاصة بك إلى معالجة الفشل.
1:52 يحمي المفتاح العملية ضمن نطاقها الموثق. يحتفظ Stripe بمفاتيح الإصدار الأول لمدة أربع وعشرين ساعة على الأقل ويمكنه حذفها
ما هي المدة التي تكون فيها النتيجة المحفوظة آمنة لإعادة المحاولة؟
1:59 بعد ذلك. يمكن لمفتاح محذوف تنفيذ طلب جديد. احتفظ بإعادة المحاولات غير المحلولة في اليوم الأول. بعد ذلك، توقف وقم بتسوية النتيجة الأصلية. استخدم التراجع الأسي والتذبذب لإعطاء الخادم مساحة للتنفس. وإلا فإن عمليات إعادة المحاولة تشكل طابورًا خارج مقهى محترق. تتعامل مكتبات Stripe مع عمليات إعادة المحاولة، ولكن تحقق من الإعدادات الافتراضية لمكتبتك. هذا الخطأ اللاصق هو المشكلة.
لماذا يمكن لخطأ محفوظ أن يستمر في الظهور؟
2:20 تستمر استجابة خمسمائة المخزنة مؤقتًا في إعادة التشغيل بعد استعادة الاتصال. قد تكون للعملية الأصلية آثار جانبية. حل نتيجتها باستخدام الكائنات ولوحة التحكم وخطافات الويب. يمكن لمفتاح جديد تكرار الإجراء. إذا كنت تفضل قراءة هذا بدلاً من سماعي أقوله، فإن الفرق يصل إلى بريدك الوارد كل صباح، مجانًا على daily diff dot dev، الرابط أدناه.
هل سأشحن زر إعادة محاولة بهذا العقد؟
2:39 الحكم، تحت الغطاء. اشحنها. سأشحن مفاتيح مستقرة مع إعادة محاولات محدودة ومصالحة، حتى يحصل العملاء على القهوة دون تمويل تعليم أنظمتك الموزعة. وهذا هو الفرق لهذا اليوم. أنا نيكو من 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



