في نظام مخزون افتراضي، يطلب موظفان إعادة تجهيز الفهرس للفرع نفسه. قد يمر اختبار الإرسال المكرر على جهاز المطور، ثم يفشل في الإنتاج إذا كان كل خادم يحتفظ بالقفل في مخزن مختلف. افحص القفل من نقطتي إرسال مستقلتين.
حدد نطاق المفتاح قبل تجربة الطابور
يمكن استخدام ShouldBeUnique لمنع إدراج مهمة عندما يتعذر اكتساب قفل التفرد. اجعل uniqueId يعبر عن الوحدة الفعلية للعمل: مثل المؤسسة والفرع معًا. إذا كان المفتاح يعتمد على الفرع وحده ومعرفاته تتكرر بين مؤسسات، قد تمنع مهمة تخص مؤسسة أخرى دون قصد.
المرجع: Laravel 12 Queues.
اختبر مثيلين لا طلبين على جهاز واحد
شغّل مثيلين من التطبيق في بيئة اختبار، وأوقف العامل مؤقتًا حتى تبقى المهمة الأولى في الطابور. أرسل الطلب نفسه من المثيلين وتحقق من ظهور إدخال واحد. بعد ذلك أرسل مهمة لفرع مختلف وتحقق أنها تُقبل. افحص إعداد مخزن القفل المشترك الفعلي، لا مجرد تطابق اسم Redis أو قيمة الإعداد المكتوبة.
افصل لحظة تحرير القفل عن العمل
مع ShouldBeUnique يستمر القفل عادةً إلى اكتمال المهمة أو استنفاد المحاولات، مع مراعاة مدة انتهاء محددة إذا ضُبطت. أما ShouldBeUniqueUntilProcessing فيحرره قبل المعالجة. اختبر الإرسال أثناء تنفيذ المهمة إذا كان هذا الفارق مهمًا. لا تعمم التفرد على المهام المضافة إلى Laravel batches حيث لا تنطبق هذه القيود.
راجع الآثار عند الفشل
فشل العامل بعد تنفيذ الأثر وقبل تسجيل النجاح لا يعالجه منع الإدراج وحده. استخدم معرّف عملية عند كتابة الأثر، ثم اختبر استئناف المحاولة بعد توقف مصطنع. سلم نتيجة منفصلة لعدد إدخالات الطابور ونتيجة أخرى لعدد الآثار المحفوظة حتى يمكن معرفة أي طبقة تحتاج إصلاحًا.
لربط الاختبار بتنفيذ مشروعك، راجع الصيانة التقنية والمراجعة التقنية.
صورة توضيحية أصلية لشرح الفكرة، وليست لقطة نظام عميل أو نتيجة قياس فعلية.
