تصميم Scheduler يمنع تشغيل نفس المهمة مرتين

في نظام فيه أكثر من Process أو Worker، كل واحد قد يرى المهمة المستحقة في نفس اللحظة. إذا لم توجد آلية Claim ذرية، يمكن أن يبدأ التنفيذ مرتين. الحل ليس الاعتماد على التوقيت بل جعل حجز المهمة عملية واحدة لا ينجح فيها إلا عامل واحد.

استخدم Claim ذري

UPDATE ... WHERE status=scheduled AND due<=now RETURNING أو lock مناسب يحدد الفائز.

Lease أفضل من Lock أبدي

الحجز له expiry حتى لا تبقى المهمة عالقة إذا مات worker.

أضف Idempotency في المهمة

حتى مع Scheduler جيد قد يحدث retry بعد غموض. المهمة نفسها يجب أن تمنع الأثر المكرر.

اختبر Race عمدًا

شغل عاملين يحاولان أخذ نفس job وتأكد أن واحدًا فقط يبدأ.

سيناريو تطبيقي قبل الاعتماد

تخيل المهمة تعمل عشرات المرات يوميًا، ويحدث في إحدى المرات timeout بعد خطوة لها أثر خارجي. التصميم الجيد يجب أن يعرف أين توقف وما الذي تم بالفعل. في موضوع «تصميم Scheduler يمنع تشغيل نفس المهمة مرتين»، نفّذ تجربة صغيرة قبل تعميم القرار. ابدأ بـ1- claim job.، 2- سجل worker.، 3- حدد lease expiry.، ثم سجل النتيجة قبل توسيع النطاق. لا تحاول تحسين كل شيء في أول Run؛ المطلوب أولًا إنشاء حالة مرجعية تستطيع العودة إليها ومقارنتها. عندما تنجح التجربة، كررها مرة ثانية بنفس الشروط للتأكد أن النتيجة لم تكن صدفة أو أثر Cache أو حالة مؤقتة.

كيف تقيس نجاح التجربة؟

راقب نسبة النجاح من أول محاولة، عدد retries، زمن كل خطوة، عدد التدخلات اليدوية، وحالات التكرار أو الـloop. هذه المقاييس أهم من مجرد انتهاء Run واحدة بنجاح. حوّل النقاط الموجودة في المقال إلى مؤشرات قابلة للرصد: قراءة ثم تحديث خطوتان غير ذريتين.؛ leader واحد يقلل الخطر لكنه ليس البديل الوحيد.؛ database constraint قد يحمي بعض الحالات.. احتفظ بالقياسات مع timestamp ونسخة التطبيق أو البيئة، لأن مقارنة أرقام من إصدارات أو شروط مختلفة قد تعطي استنتاجًا خاطئًا. وإذا كانت النتيجة رقمية، استخدم أكثر من عينة بدل أفضل أو أسوأ قيمة منفردة.

عند الفشل: ماذا تراجع أولًا؟

عند الفشل، لا تبدأ من أول Workflow تلقائيًا. تحقق من آخر checkpoint والأثر الخارجي، ثم اختر retry أو resume أو manual review وفق حالة مؤكدة. عند التحقيق استخدم هذه القائمة كحد أدنى: claim ذري.؛ lease موجود.؛ run ID ثابت.؛ retry لا يكرر الأثر.. سجل ما الذي جربته وما الذي لم يتغير بعد التجربة. هذه المعلومة تمنع الفريق من إعادة نفس المحاولات وتساعد على تحديد ما إذا كان الخطأ في الإعداد أو الأداة أو الشبكة أو بيانات المهمة.

متى تعتمد القرار على نطاق أوسع؟

قرار الاعتماد لا يجب أن يعتمد على أن التجربة «عملت مرة». في «تصميم Scheduler يمنع تشغيل نفس المهمة مرتين» اعتبر الحل جاهزًا عندما تستطيع إعادة نفس السيناريو بنتيجة متقاربة، ويفهم شخص آخر خطوات الاختبار وحدود النتيجة، وتعرف ماذا ستفعل لو فشلت الحالة الطبيعية. لو لم تتحقق هذه الشروط، احتفظ بالحل كتجربة أو إعداد مبدئي ولا تحوله إلى Default لكل الحسابات أو المهام.