أدوات المطور · مولد UUID
مفاتيح العجز: استخدام UUID الذي أنشأه العميل لجعل عمليات إعادة المحاولات آمنة
· لماذا يهم
uuid التشفير متصفح API
إن انتهاء مهلة طلب الدفع يتركك غير متأكد مما إذا كان قد تم تنفيذه أم لا. تتيح لك مفاتيح العجز إمكانية إعادة المحاولة بأمان، ويعد CSPRNG الذي تم إنشاؤه UUID هو المفتاح الطبيعي. يشرح هذا المنشور النمط من النهاية إلى النهاية.
المهلة التي ربما تكون قد فرضت رسومًا على العميل مرتين - توجد مفاتيح عدم القدرة على وضع الفشل لإصلاحها
يؤدي انتهاء المهلة أثناء طلب الدفع إلى خلق حالة من عدم اليقين الحقيقي لدى العميل والنظام. لقد تخلى عميل HTTP عن انتظار الرد، ولكن ربما يكون خادم الدفع قد عالج المعاملة قبل إغلاق الاتصال أو انتهاء مهلته. إذا قمت بإعادة محاولة نفس الطلب، فقد يتم تحصيل الرسوم من العميل مرتين. إذا لم تقم بإعادة المحاولة، فلن تكتمل عملية الدفع أبدًا. يفشل نظام الدفع في حل وسط غير سعيد: قد تكون أموال العميل قد اختفت، أو قد تصل غدًا، أو قد تكون عالقة في قائمة انتظار المعالجة، أو ربما لم تترك الحساب على الإطلاق. وهذا الغموض غير مقبول بالنسبة للأنظمة المالية.
كيف تعمل مفاتيح الاختلال - يقوم الخادم بتخزين الاستجابة الأولى تحت المفتاح ويعيد تشغيلها للتكرار
تحل مفاتيح العجز هذه المشكلة بأناقة عن طريق جعل عمليات إعادة المحاولة آمنة وحتمية. ينشئ العميل مفتاحًا فريدًا لكل غرض — الدفع، والتحويل، والتكلفة — ويدرجه في كل طلب. يقوم الخادم بمعالجة الدفع، ويخزن الاستجابة مؤقتًا تحت هذا المفتاح ويخزن كلاً من المفتاح والنتيجة. إذا وصل نفس المفتاح مرة أخرى خلال فترة الاحتفاظ، فسيقوم الخادم بإعادة تشغيل الاستجابة المخزنة مؤقتًا دون معالجة الدفع مرة أخرى. يمكن للعميل إعادة المحاولة بثقة مع العلم أن نفس المفتاح بالضبط سيؤدي دائمًا إلى نفس النتيجة، بغض النظر عن عدد مرات إرساله. يزيل هذا النمط الغموض ويجعل منطق إعادة المحاولة آمنًا.
أنشئ قبل المحاولة الأولى - لماذا يجب أن يكون المفتاح موجودًا قبل مغادرة الطلب وإعادة استخدامه حرفيًا عند إعادة المحاولة
يعتبر هذا النمط أقدم من مواصفات HTTP الحديثة ولكنه اكتسب شهرة في المدفوعات بعد الخسائر المالية واسعة النطاق وشكاوى العملاء من الرسوم المتكررة. كل دفعة API والعديد من واجهات برمجة التطبيقات لخدمة الويب تدعم الآن مفاتيح العجز. يعد CSPRNG الذي تم إنشاؤه UUID هو الاختيار الطبيعي للمفتاح لأنه لا يمكن تخمينه وفريد من نوعه دون أي تنسيق بين العملاء ولا يتطلب أي تخصيص من جانب الخادم أو سلطة مركزية. يقوم العميل بإنشائه قبل المحاولة الأولى، ويعيد استخدامه حرفيًا في كل إعادة محاولة، ويتلقى نفس الاستجابة في كل مرة. ليست هناك حاجة إلى حالة من جانب الخادم لتنسيق إنشاء المفاتيح.
لماذا UUID عشوائي وليس تجزئة العداد أو الحمولة - التفرد بدون تنسيق وعدم إعادة الاستخدام العرضي عبر المقاصد
يجب أن يكون المفتاح موجودًا قبل أن يغادر الطلب العميل، لأن إنشائه عند إعادة المحاولة يكون متأخرًا جدًا لضمان العجز. إذا نجح الطلب الأول وتم تحصيل الرسوم من العميل، فإن إنشاء مفتاح جديد عند إعادة المحاولة سيؤدي إلى إخفاء المشكلة وإعادة الشحن مرة أخرى. يجب على العميل الالتزام بالمفتاح قبل المحاولة الأولى، وتخزينه في الذاكرة أو التخزين الدائم، وإعادة استخدام نفس المفتاح إذا أصبحت المهلة أو إعادة المحاولة ضرورية. بالنسبة للاختبار اليدوي API، يقوم المولد ToolAcre بإنتاج مفاتيح يمكنك لصقها في حليقة أو عميل REST، ونسخها وإعادة استخدامها عبر طلبات متعددة لاختبار سلوك القصور.
النطاق والعمر - المفاتيح لكل عملية، ولكل حساب، والمدة التي يجب أن يتذكرها الخادم
لماذا UUID بدلاً من تجزئة أو عداد تسلسلي لمفاتيح العجز؟ تبدو تجزئة حمولة الطلب بديهية، حيث تحصل الحمولات المتطابقة على تجزئة متطابقة وبالتالي مفاتيح متطابقة. لكن التجزئات ضعيفة بالنسبة لحالة الاستخدام هذه لأن الطلبين المتطابقين تقريبًا بكميات مختلفة أو مستلمين مختلفين أو معلمات مختلفة ينتجون تجزئات مختلفة تمامًا وبالتالي يولدون رسومًا منفصلة، وهو أمر صحيح ولكنه لا يوفر كل الحماية المطلوبة. يتطلب العداد المتسلسل التنسيق والحالة الموزعة: إذا قام عميلان بإنشاء مفاتيح تعتمد على العداد على البنية الأساسية الخاصة بك، فقد تتعارض العدادات الخاصة بهما. لا يتطلب UUID أي سلطة مركزية، ولا يمكن تخمينه ومن المستبعد للغاية أن يتصادم عن طريق الصدفة عبر الإنترنت بالكامل في جميع الأوقات.
مثال عملي — تسلسل إعادة المحاولة بنفس المفتاح، يوضح ما يرسله العميل وما يرجعه الخادم في كل مرة
يقوم التنفيذ من جانب الخادم بتخزين الاستجابات ضمن المفاتيح وإرجاع الاستجابات المخزنة مؤقتًا عند التكرارات. يكمن التعقيد في تحديد الأسئلة التشغيلية العملية: فترة الاحتفاظ، ومدة تذكر المفتاح، وحجم ذاكرة التخزين المؤقت، وعدد المفاتيح التي يجب تذكرها، والقفل، وكيفية منع طلبين متزامنين بنفس المفتاح من معالجة الدفع مرتين والتنظيف عند نسيان المفتاح. هذه أسئلة تتعلق بالتخزين والموثوقية خارج نطاق المولد UUID. تتمثل مهمة العميل في إنشاء مفتاح جيد وإعادة استخدامه عند إعادة المحاولة؛ تتمثل مهمة الخادم في تنفيذ ذاكرة التخزين المؤقت بشكل صحيح ودائم.
ما لا يغطيه هذا هو التخزين والقفل من جانب الخادم اللازم لتنفيذ النمط، وهو تصميم منفصل
يُظهر المثال العملي تسلسلًا نموذجيًا في الممارسة العملية. يحتاج تطبيق الهاتف المحمول إلى تحويل الأموال إلى صديق باستخدام API الذي يدعم العجز الجنسي. قبل إرسال الطلب، يقوم التطبيق بإنشاء UUID باستخدام مكتبة التشفير المحلية الخاصة به أو جلب واحدًا من منشئ ToolAcre لأغراض الاختبار: 3fa85f64-5717-4562-b3fc-2c963f66afa6. يرسل التطبيق طلب POST إلى /transfers بنص JSON ورأس HTTP مفتاح Idempotency-Key: 3fa85f64-5717-4562-b3fc-2c963f66afa6. يقوم الخادم بمعالجة النقل، ويخزن 3fa85f64-5717-4562-b3fc-2c963f66afa6 → {status: "success"، TransferId: "xfer-12345"} في ذاكرة التخزين المؤقت الخاصة به ويعيد استجابة 200 بالنتيجة.
الوجبات الجاهزة: هدف واحد، مفتاح واحد — يمنحك المولد ToolAcre CSPRNG مدعومًا UUID لاستخدامه كمفتاح عند اختبار التكامل يدويًا
تنتهي مهلة الشبكة ولا يرى العميل الاستجابة من المحاولة الأولى. يقوم التطبيق بإعادة محاولة نفس الطلب بنفس مفتاح العجز دون إنشاء UUID جديد. يتعرف الخادم على المفتاح الموجود في ذاكرة التخزين المؤقت الخاصة به، ويعثر على الاستجابة المخزنة مؤقتًا ويعيد على الفور {status: "success"، TransferId: "xfer-12345"} دون معالجة عملية نقل جديدة ودون تحصيل رسوم من العميل مرة أخرى. العملية غير فعالة: إعادة المحاولة تؤدي إلى نفس النتيجة الملحوظة في كل مرة. لإجراء اختبار ناجح، يمكن للمولد ToolAcre توفير المفتاح؛ قم بإنشاء UUID، وقم بتضمينه في الرأس، ولاحظ الاستجابة وأعد الإرسال باستخدام نفس المفتاح للتحقق من أن الخادم ينفذ التخزين المؤقت بشكل صحيح.