تنهار المهام الخلفية أولًا عند الذروة. تتبّع إعدادًا واحدًا من عامل تسلسلي أنجز 20 إلى 26% فقط من المهام في وقتها، إلى طوابير منفصلة ومجموعة عمليات Horizon تتوسع خلال ثوانٍ.
Author
Anichur Rahaman
أمام مهندس المناوبة في منصة امتحانات دقيقة واحدة فقط، صباح يوم الاختبار، الساعة 8:59. وفي التاسعة تمامًا يضغط 1,000 طالب زر «إرسال» في الدقيقة نفسها. خوادم الويب تردّ على كل نقرة في أجزاء من الثانية، ولوحات المراقبة خضراء. وعند 9:03 يبدأ صندوق الدعم بالامتلاء: رأى الطلاب كلمة «تم الإرسال» على الشاشة، لكن لم يصل أي تأكيد، وفريق التصحيح لا يرى سوى عدد قليل من الإجابات. هذا مشهد توضيحي، لكنني جهّزت منصة حقيقية لضغط من هذا النوع بالضبط.
لم يكن السبب في طبقة الويب. كان عامل خلفي واحد يعالج الإرسالات واحدًا بعد الآخر. الطابور يحوّل الدفعة المفاجئة إلى صفّ، ولذلك فإن جودة العمال هي التي تحدد هل يستغرق الصفّ ثلاث ثوانٍ أم ست عشرة دقيقة.
يتتبّع هذا المقال الطريق الذي سلكته من عامل تسلسلي واحد إلى مجموعة عمليات تكبر وتصغر من تلقاء نفسها، مع عادات تصميم المهام التي تجعل هذه المجموعة آمنة التشغيل.
هذا هو الجزء الثاني من سلسلة «هندسة الأنظمة عالية الحمل». يتناول الجزء الأول مسار الطلب من الحافة إلى التطبيق: التوسّع التلقائي أمام ذروات الزيارات: ما الذي يتوسّع فعلًا.
في طلب الويب هناك إنسان ينتظر، فنلاحظ البطء فورًا. أما المهمة في الطابور فلا ينتظرها أحد في تلك اللحظة، فيختبئ البطء حتى يتضخم التراكم. كما يحوّل الطابور الدفعة المفاجئة إلى صفّ طويل: إذا وصلت 1,000 مهمة في دقيقة واحدة واستغرقت كل منها ثانية، فسيحتاج عامل واحد إلى أكثر من 16 دقيقة لإنهائها.
هذه كانت نقطة البداية عندي تمامًا. عامل واحد، يعمل بأمر مثل queue:work --queue=retakes,default، يعالج 1,000 مهمة من الدفعة واحدة تلو الأخرى. والأسوأ أن الأعمال منخفضة الأولوية كانت تقف في الصفّ نفسه مع الإرسالات الحيّة، فقد تتقدّم دفعة من المهام غير المهمة على عمل ينتظره عميل. وفي إعادة تشغيل ذلك الذروة، انتهى بين 20 و26 بالمئة فقط من المهام في وقتها. هذه أرقام إعداد واحد وليست معيارًا عامًّا، لكن شكل الإخفاق شائع جدًّا.
قاعدة البيانات كانت بخير. النسخة المُدارة لم تقترب من حدودها. العائق كان قرار تصميم: عملية واحدة، وصفّ واحد، ولا أولويات.
كان التغيير الأول ماديًّا. كان الويب والعمال يتشاركون جهازًا واحدًا بسعة 8 جيجابايت، وحين ينشغل العمال كانوا يسحبون المعالج والذاكرة من PHP-FPM. فيبطؤ الموقع بسبب المهام التي وضعها هو نفسه في الطابور.
انتقل العمال إلى عقدة خاصة بهم. الآن يستطيع الطابور المزدحم أن يستخدم كل الأنوية التي يريدها دون أن يمسّ تحميل صفحة واحدة، ولا يمنع أي عطل في الويب الطابور من التفريغ. وهذا يتيح تحجيم كل جهاز بحسب عمله: عقد الويب لطلبات كثيرة قصيرة، وعقدة العمال لمهام تستهلك ذاكرة كبيرة.
التغيير الثاني كان التوقف عن خلط كل شيء في صفّ واحد. أنشأت طوابير منفصلة بحسب معنى العمل بالنسبة إلى العميل:
الطوابير المنفصلة تتيح لكل طابور عددًا خاصًّا من العمال ومهلة (timeout) خاصة وقواعد إعادة محاولة خاصة. لم يعد بوسع مهمة تقرير تعمل أربع دقائق أن تعطّل تأكيد دفعة. القاعدة العملية: إذا اختلفت أنواع العمل في درجة الاستعجال أو حاجة الذاكرة أو سلوك الفشل، ففي طوابير مختلفة مكانها.
ترتيب الطوابير بحسب الأولوية داخل عامل واحد (الأول يفوز دائمًا) أفضل من صفّ مختلط، لكنها تبقى عملية واحدة. أما العمليات المخصصة لكل طابور فهي التي تُنهي مشكلة تقدّم عمل على آخر نهائيًّا.
أضف عمالًا يفرغ الصفّ أسرع، إلى حدّ معين. في اختباراتي، أنجزت نحو 12 عملية عامل 1,000 مهمة في نحو 3 ثوانٍ حين كانت المهام خفيفة، وفي نحو 10 ثوانٍ حين كانت ثقيلة. وبعد نحو 20 عاملًا لم تفد الإضافة: صار العمال ببساطة يصطفّون خلف بعضهم على كتابات قاعدة البيانات.
| عمليات العمال | ما لاحظته (إعداد واحد) |
|---|---|
| 1 | المهام تعمل واحدة تلو الأخرى؛ 20–26% فقط في الوقت |
| نحو 12 | 1,000 مهمة خفيفة في ~3 ثوانٍ، والثقيلة في ~10 ثوانٍ |
| أكثر من ~20 | لا فائدة؛ العمال ينتظرون كتابات قاعدة البيانات |
تتماسك الأرقام بحساب بسيط. أزمنة المهام هنا مستنتجة من النتائج، فاعتبرها توضيحية: مهمة خفيفة زمنها نحو 0.03 ثانية تجعل 1,000 مهمة تساوي 30 ثانية من العمل، وتقتسمها 12 عاملًا في نحو 2.5 ثانية. ومهمة ثقيلة زمنها نحو 0.12 ثانية تجعل العمل 120 ثانية، ويُنهيها 12 عاملًا في نحو 10 ثوانٍ. أما عامل واحد فيحتاج إلى 120 ثانية كاملة، وتكون مهلة الإرسالات الحيّة قد فاتت منذ زمن.
هذا هو الدرس وراء ورقة تقدير السعة في الخاتمة: الرقم الصحيح ليس «أكبر عدد ممكن». إنه النقطة التي لا يعود فيها العامل التالي يقصّر الصفّ. اعثر عليها باختبار حمل لا بالتخمين، ولا تُرقِّ قاعدة البيانات قبل أن يُثبت الاختبار أنها مشبعة فعلًا. أتناول طبقة البيانات في الجزء الثالث.
مجموعة ثابتة من 12 هدر في يوم ثلاثاء هادئ، وقد تكون صغيرة في يوم كبير. التوسع التلقائي هو الجواب، لكن الطبقة التي توسّعها هي المهمة. تشغيل جهاز افتراضي جديد يستغرق من دقيقة إلى ثلاث، والضغط المجدول يبلغ ذروته في ثوانٍ. وكما شرحت في الجزء الأول، تُوسَّع الموارد مسبقًا للأحداث المعروفة. وللطوابير خيار أفضل: وسّع العمليات داخل جهاز يعمل أصلًا.
يفعل Laravel Horizon ذلك عبر إعداد balance. وبحسب وثائق Laravel الرسمية، يقدّم Horizon ثلاث استراتيجيات: simple توزّع المهام الواردة بالتساوي على عمليات العمال، وauto تضبط عدد العمليات لكل طابور بحسب حمله الحالي، وfalse توقف الموازنة. ومع auto، تحدد بضعة خيارات سرعة الاستجابة.
| الإعداد | ما الذي يتحكم فيه | القيمة التي استخدمتها لطابور الإرسال |
|---|---|---|
| balance | الاستراتيجية: auto أو simple أو false | auto |
| minProcesses | العمليات المحفوظة لكل طابور حتى في حالة الخمول | 1 |
| maxProcesses | الحد الأعلى لعدد العمليات الذي يمكن أن يصل إليه Horizon | 10 |
| balanceMaxShift | كم عملية تُضاف أو تُزال في تعديل واحد | 3 |
| balanceCooldown | الثواني بين تعديل وآخر | 3 |
القيم الافتراضية الموثّقة في Horizon أكثر هدوءًا: عملية واحدة لكل تعديل، كل ثلاث ثوانٍ. رفعتُ الإزاحة إلى ثلاث لأن الدفعة المفاجئة لا ينبغي أن تستغرق نصف دقيقة لتبلغ طاقتها. النتيجة: حين كبر الصفّ أنشأ Horizon عمليات عمال إضافية خلال ثوانٍ، وحين فرغ أزالها. دون جهاز جديد، ودون عنقود، ودون تكلفة إضافية.
في التوسع على مستوى العمليات فخّ واحد. يجب أن تتّسع الحاوية للحد الأقصى لا للمتوسط. إذا بلغت ذروة كل مهمة نحو 128 ميجابايت وسمحتَ بـ10 عمليات، فالمجموع نحو 1.3 جيجابايت، ولذلك ضبطت الحاوية على نحو 2 جيجابايت. وإذا حجّمتها لحالة الهدوء، فستنتهي أول دفعة حقيقية بعمليات إنهاء بسبب نفاد الذاكرة، وسينتزع النواة العمال في منتصف المهام.
يستحق الأمر قياس الذاكرة لكل مهمة لا لكل عامل، لأن نوعًا واحدًا من المهام الثقيلة قد يستأثر بالميزانية كلها.
بلغت ذروة إحدى المهام في إعدادي 288 ميجابايت. كانت تجلب صورها بنفسها عبر HTTP وتقرأ ملفات من القرص المحلي، وتحتفظ بكل ذلك في الذاكرة دفعة واحدة. وبقراءة الملفات تدفقًا (streaming) من تخزين الكائنات انخفضت الذروة إلى نحو 128 ميجابايت. هذا التغيير وحده وفّر علينا فئة كاملة من أحجام الأجهزة.
قبل إضافة ذاكرة أو عقدة أكبر، اسأل ثلاثة أسئلة عن كل مهمة ثقيلة:
والمهام الصغيرة تناسب موازنة Horizon أكثر أيضًا، لأنه يستطيع تحريك السعة بخطوات صغيرة.
Horizon ليس الطريقة الوحيدة لتوسيع العمال. هكذا تتقابل الخيارات الأربعة الشائعة لطابور على نمط Laravel.
| الخيار | ما الذي يتوسع | زمن الاستجابة | التكلفة والجهد |
|---|---|---|---|
| نسخ ثابتة (Compose أو Swarm) | لا شيء؛ أنت تحدد عددًا ثابتًا | يدوي | بسيط، لكنك تدفع ثمن سعة الذروة طوال الوقت |
| Kubernetes مع HPA | الحاويات (pods) بحسب المعالج أو مقاييس مخصصة | دقائق | يحتاج عنقودًا وخط مقاييس |
| Kubernetes مع KEDA | الحاويات بحسب طول الطابور | دقائق | يحتاج عنقودًا؛ يتوسع وفق الإشارة الحقيقية |
| Horizon auto-balance | العمليات داخل حاوية | ثوانٍ | مجاني، بلا عنقود، ومحدود بجهاز واحد |
KEDA مشروع جيد. فبحسب وثائقه، يفحص كل مشغّل (trigger)، مثل طول قائمة Redis، في كل فترة استطلاع (30 ثانية افتراضيًّا)، ثم يتولى Horizontal Pod Autoscaler في Kubernetes التوسع من نسخة واحدة إلى نسخ كثيرة. وإضافة الحاويات تعني أيضًا جدولتها وتشغيلها. وبالنسبة إلى ضغط مجدول يبلغ ذروته في ثوانٍ، يبقى ذلك بطيئًا، والعنقود تكلفة حقيقية على فريق صغير.
قاعدتي: استخدم Horizon auto-balance للاستجابة السريعة، ووسّع الجهاز أو الحد الأدنى مسبقًا قبل حدث تعرف أنه قادم. وفكّر في KEDA حين لا تكفي عقدة واحدة للعمل اليومي.
مجموعة من العمال السريعين تكشف كل ضعف في طريقة كتابة مهامك. هذه العادات أبقت مهامي آمنة:
يجب أن تعمل المهام المجدولة على نمط cron في عقدة واحدة بالضبط. فإذا وسّعت عقد الويب أو العمال وشغّلت كل واحدة منها المجدوِل، فسيُنشأ كل تقرير مجدول عدة مرات، وسيصدر كل تذكير مرتين، وسيصطدم كل تنظيف بنفسه.
اختر عقدة واحدة ووثّقها وأبقِها خارج أي مجموعة توسع تلقائي. وتحتاج الأوامر الخلفية إلى العناية نفسها التي تحتاجها طلبات الويب. ففي إحدى البيئات المستضافة ذاتيًّا، كان المجدوِل يُقلع الإطار كله لكل أمر صغير، دون OPcache لسطر الأوامر وبحدود ذاكرة ضيقة، فتسبب في مئات عمليات الإنهاء بسبب نفاد الذاكرة. وقد حُلّ ذلك بتشغيل الـrelays داخل عملية طويلة العمر وتفعيل OPcache لسطر الأوامر.
العامل عملية طويلة العمر، فيحتفظ بالشيفرة القديمة في الذاكرة حتى تعيد تشغيله، وإعادة التشغيل المفاجئة تقتل المهمة الجارية. الترتيب الآمن هو التوقف عن أخذ مهام جديدة، ثم ترك الجارية تنتهي، ثم تشغيل العمال الجدد.
أستعرض تسلسل النشر كاملًا، بما فيه blue/green والرجوع إلى إصدار سابق، في الجزء الخامس.
استخدم هذه القائمة القصيرة قبل ذروتك القادمة:
نعود إلى التاسعة صباح يوم الامتحان. الإرسالات الـ1,000 نفسها، لكن لطابور الإرسال الآن عملياته الخاصة ولا يقف أي شيء آخر أمامه. ينتقل Horizon من عملية واحدة إلى عشر في نحو عشر ثوانٍ، وتنتهي الدفعة في الوقت الذي يستغرقه الطالب ليعيد النظر إلى الشاشة، وتخرج التأكيدات قبل أن تُكتب أول رسالة إلى الدعم. أما مهام التقارير والصور فتنتظر، كما ينبغي لها.
الجزء التالي، طبقة البيانات تحت الحمل، يتناول ما يحدث حين يصبح العمال سريعين بما يكفي للضغط على قاعدة البيانات: تجميع الاتصالات، وأدوار Redis، ومخزن منفصل لتضمينات الذكاء الاصطناعي.
Anichur Rahaman مهندس برمجيات معماري ومؤسس StoreConsole، يصمّم أنظمة التجارة وERP للشركات النامية، ويهتم خصوصًا بالبنية القائمة على الأحداث وسلامة البيانات وتشغيل الأنظمة على خوادم الشركة نفسها.
About the Author
Anichur Rahaman
Continue Reading
