يحصل عامل على قفل، ثم تتأخر مهمته حتى تنتهي المدة. يأخذ عامل ثان القفل نفسه، ويعود الأول لينفذ حذفًا غير مشروط للمفتاح. هنا يمكن للتنظيف المتأخر أن يزيل حماية المهمة الجديدة. اختبار الحصول على القفل وحده لا يكشف هذا المسار.
قيمة المفتاح تعبر عن الملكية
يعرض مرجع Redis لأمر SET نمطًا يقترن فيه إنشاء المفتاح المشروط بانتهاء صلاحية. ولتقوية التحرير، يقترح قيمة عشوائية مميزة، ثم سكربتًا لا يزيل المفتاح إلا إذا طابقت قيمته الرمز المتوقع. المقارنة والحذف ينبغي أن يكونا عملية ذرية؛ الفصل بينهما يترك نافذة منافسة.
أعد تمثيل العامل المتأخر
استخدم مهمة افتراضية ترسل نتائج إلى مخزن اختبار، لا إلى نظام دفع أو بريد حقيقي. سمِّ العاملين A وB، وسجل رموزًا مصطنعة للعرض فقط. لا تنسخ مفاتيح أو بيانات عملاء من الإنتاج إلى تقرير التجربة.
- يحصل A على المفتاح بقيمته ومدة قصيرة مناسبة للاختبار.
- أوقف تقدمه حتى تنتهي المدة دون إيقاف Redis.
- يحصل B على المفتاح بقيمة مختلفة.
- اطلب من A التحرير، ثم افحص أن قيمة B لم تُحذف.
مدة القفل لا تلغي آثار المهمة
حتى لو صح التحرير، لا تعني نهاية المهلة أن العامل الأول توقف عن التنفيذ. إذا كانت العملية تكتب في نظام آخر، راجع كيف يمنع ذلك النظام أثرًا متأخرًا أو مكررًا. قد يحتاج التصميم معرف عملية ثابتًا أو تسلسل ملكية تتحقق منه جهة الكتابة؛ لا تنسب هذه الحماية إلى المفتاح وحده.
اختبر أيضًا فقد الاتصال بعد محاولة الحجز. المهلة في العميل لا تثبت أن Redis لم ينفذ الأمر. سجل الحالة وأعد القراءة وفق تصميم المكتبة بدل إنشاء عمل ثان بلا تحقق.
حدد ما الذي أثبته الاختبار
في صيانة الأنظمة وثق إصدار Redis والمكتبة وسياسة الانتهاء. وتراجع أنظمة الشركات نتيجة العمل النهائية لا وجود المفتاح فقط. هذا اختبار لنمط محدد، وليس برهانًا عامًا على سلامة الأقفال الموزعة تحت كل أعطال الشبكة أو تبديل الخوادم.
صورة توضيحية أصلية لشرح الفكرة، وليست لقطة نظام عميل أو نتيجة قياس فعلية.
