عندما تُشغَّل كل الأتمتة داخل Process واحدة، Crash في Renderer أو تسرب ذاكرة في مهمة قد يؤثر في بقية العمل. Browser Worker architecture تفصل التخطيط عن التنفيذ: Scheduler يضع Jobs في Queue، Workers مستقلة تسحب العمل، وكل Worker يحجز Profile لمدة محددة ويرسل Heartbeat. هذا يجعل الانهيار محدود النطاق ويتيح الاستعادة أو إعادة المهمة دون إعادة تشغيل المنظومة كلها.
Queue هي الحد الفاصل بين القرار والتنفيذ
ال ـScheduler لا يفتح المتصفح؛ يقرر أن Job مستحقة ويضعها في Queue مع taskId و profileId و payload وإصدار Workflow. Worker يطلب Job عندما تكون لديه سعة. هذا الفصل يسمح لك بإضافة Workers أو إيقافها بدون تغيير الجدولة، ويمنع اندفاع مئة مهمة في اللحظة نفسها.
اعزل Profile ب Lease واضح
قبل فتح Profile، يحصل Worker على Lease يمنع Worker آخر من استخدام نفس Profile في الوقت نفسه. يجدد ال ـLease أثناء المهمة. إذا مات Worker، ينتهي lease بعد مدة معروفة بدل أن يبقى Profile محجوزًا للأبد. قبل إعادة المهمة، تحقق من آخر checkpoint لأن الانهيار قد يحدث بعد تنفيذ أثر خارجي.
خطوات عملية
- اسحب Job من Queue.
- احجز Profile atomically.
- سجل Worker ID و lease expiry.
- ابدأ المهمة وأرسل heartbeat/checkpoints.
- عند النهاية حرر Profile وأغلق الموارد المرتبطة به.
اجعل نطاق الفشل صغيرًا
لو Renderer crash، حاول إعادة التبويب أو Profile قبل قتل Worker. لو child process الخاص بالبروفايل مات، أعد ذلك البروفايل. Restart لل ـWorker كامل يجب أن يكون لمشكلة Worker-level. بهذا تقل الخسارة وتظل Jobs الأخرى تعمل. صمم IPC بحيث فشل child لا يوقف Main loop أو ينتظر sendSync بلا مهلة.
قائمة مراجعة
- كل Profile له process/partition معروف.
- IPC له timeout.
- Crash في Profile لا يغلق Profiles أخرى.
- المهمة تملك checkpoint قبل الأثر الحساس.
- Worker يمكنه drain قبل التحديث.
الاستعادة تحتاج Idempotency ومراقبة
بعد crash لا تعيد Job من البداية تلقائيًا. اقرأ checkpoint، افحص هل الأثر الخارجي حدث، ثم قرر resume أو retry أو manual review. اجمع metrics مثل active workers، queue depth، lease expirations، crash count، و mean task duration. هذه الأرقام توضح هل المشكلة Worker بعينه أم حمل النظام كله.
حدّث ال ـWorkers بدون إسقاط المهام الجارية
عند نشر إصدار جديد لا تقتل كل ال ـWorkers في الوقت نفسه. ضع Worker في حالة Drain تمنعه من سحب Jobs جديدة، واترك المهمة الحالية تصل إلى Checkpoint أو تنتهي، ثم أوقف العملية وشغل النسخة الجديدة وأعدها إلى ال ـPool بعد Health check. نفذ التحديث على دفعات حتى يبقى جزء من السعة متاحًا. هذا الأسلوب يجعل rollback أسهل أيضًا، لأنك تستطيع إيقاف الدفعة الجديدة إذا زاد crash rate قبل تعميمها على بقية العمال.
خطوات عملية
- حوّل Worker إلى Drain.
- انتظر انتهاء أو checkpoint للمهمة الحالية.
- أوقف العملية Gracefully.
- شغل الإصدار الجديد ونفذ Health check.
- أعد Worker لل ـPool وراقب metrics قبل تحديث الدفعة التالية.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…