متى تستخدم Queue ومتى تستخدم Scheduler في مهام المتصفح

المهام المتكررة والمجدولة تحتاج توقيتًا، والمهام الكثيرة تحتاج backpressure وتوزيعًا. أحيانًا يُستخدم Scheduler كأنه Queue فيحاول تشغيل مئات الوظائف مباشرة، أو تستخدم Queue مع delay طويل لإدارة تقويم كامل. الفصل بين الدورين يجعل السعة والتكرار والمواعيد أسهل في الفهم.

استخدم Scheduler للزمن

وظيفته إنشاء أو إطلاق المهمة عند وقت معين أو وفق recurrence. يجب أن يكون idempotent حتى لا ينشئ نفس occurrence مرتين بعد restart. لا تجعله ينفذ Browser workload الثقيل داخل tick نفسه.

استخدم Queue للسعة

بعد أن تصبح المهمة due، ضعها في Queue يستهلكها workers بعدد محدود. Queue تتحكم في concurrency و retry و priority. إذا كانت هناك 500 مهمة الساعة التاسعة، لا يعني ذلك فتح 500 متصفح في اللحظة نفسها.

عرّف backpressure

إذا وصل العمل أسرع من التنفيذ، يجب أن تزيد queue depth لا عدد المتصفحات بلا حد. راقب age لأقدم job ووقت الانتظار. إذا تجاوز SLA، زد السعة أو غيّر الجدولة بدل تجاوز resource limit.

فرق retry عن reschedule

retry يعالج فشل occurrence نفسها، أما reschedule فينشئ occurrence مستقبلية حسب القاعدة. لا تجعل retry يغير موعد الدورة التالية أو يخلق نسختين منها. احتفظ ب ـschedule ID و job ID منفصلين.

اختبر duplicate delivery

Queues غالبًا توفر at-least-once semantics. افترض أن job قد تصل مرتين وصمم worker idempotent. هذا يعيدنا إلى operation key بدل الاعتماد على أن البنية لن تكرر الرسالة.

قِس هل المشكلة في الجدولة أم التنفيذ

عندما تتأخر مهمة، اسأل أين قضت وقتها. Scheduled delay هو الفرق بين الموعد المفترض ووقت enqueue، queue delay بين enqueue و start، execution time بين start و finish. جمع هذه الثلاثة يكشف هل scheduler تأخر بسبب tick أو clock، أم queue مزدحمة، أم browser workload بطيء. بدون الفصل قد تزيد workers بينما المشكلة في scheduler lock، أو تعدل recurrence بينما السبب saturation. أنشئ SLO لكل طبقة وراقبها بشكل مستقل، خصوصًا عند دفعات كبيرة لها نفس الوقت.

تعامل مع Clock و Timezone كجزء من التصميم

Scheduler يعتمد على الزمن، ولذلك تغير timezone أو DST أو clock drift يمكن أن ينتج occurrence مكررًا أو مفقودًا. خزن المواعيد الداخلية بصيغة UTC مع timezone الأصلية عندما تكون recurrence محلية مثل كل يوم 9 صباحًا في القاهرة. استخدم مصدر وقت موثوقًا وراقب drift على الخوادم. عند restart، لا تنفذ كل المواعيد القديمة بلا حد؛ ضع misfire policy تحدد هل تفوت occurrence أم تنفذ واحدة فقط. اختبر الانتقال عبر تغير التوقيت إن كانت المناطق المستخدمة تطبق DST.

حوّل الفكرة إلى سيناريو قابل للإعادة

لتقييم «متى تستخدم Queue ومتى تستخدم Scheduler في مهام المتصفح» اكتب workflow صغيرًا له بداية معروفة ونهاية قابلة للقياس، ثم اختبر happy path وحالة timeout وحالة إعادة التشغيل. يجب أن يكون واضحًا ما إذا كانت الخطوة قابلة للتكرار بأمان، وما الذي يحدث إذا نُفذت مرتين، وأين تحفظ حالة التقدم. بعد ذلك شغّل السيناريو على بيانات اختبار لا على حساب إنتاجي، وسجّل سبب كل retry والوقت المستغرق. هذه التفاصيل تمنع نجاحًا ظاهريًا في أول تشغيل ثم فشلًا صعب التفسير عندما تعمل المهام بالتوازي أو تستأنف بعد crash.