مجمّعات العمال في Go مقابل غوروتين لكل مهمة للمهام الخلفية

ما المشكلة التي نحاول حلها؟

معظم خدمات Go تقوم بأكثر من مجرد الاستجابة لطلبات HTTP. فهي أيضًا تُشغّل أعمالًا خلفية: إرسال بريد إلكتروني، تغيير حجم صور، إنشاء فواتير، مزامنة بيانات، معالجة أحداث، أو إعادة بناء فهرس بحث. بعض الوظائف سريعة ومستقلة. وأخرى تشكل سير عمل طويلًا حيث تعتمد كل خطوة على السابقة (خصم بطاقة، انتظار تأكيد، ثم إشعار العميل وتحديث التقارير).

عندما يقارن الناس "مجمّعات العمال في Go مقابل غوروتين لكل مهمة"، فهم عادةً يحاولون حل مشكلة إنتاجية واحدة: كيف تشغّل الكثير من العمل الخلفي دون أن تجعل الخدمة بطيئة أو مكلفة أو غير مستقرة.

تشعر بتأثير ذلك في عدد من الأماكن:

• الزمن (Latency): العمل الخلفي يسرق CPU والذاكرة واتصالات قاعدة البيانات وعرض النطاق الشبكي من الطلبات المواجهة للمستخدم.
• التكلفة: التزامن غير المسيطر عليه يدفعك إلى آلات أكبر، سعة قاعدة بيانات أكبر، أو فواتير قوائم انتظار وAPIs أعلى.
• الاستقرار: الارتفاعات (عمليات الاستيراد، حملات التسويق، عواصف إعادة المحاولة) قد تسبب مهلات، أعطال OOM، أو فشل تسلسلي.

التبادل الحقيقي هو بين البساطة مقابل السيطرة. إطلاق غوروتين لكل مهمة سهل الكتابة وغالبًا ما يكون كافياً عندما يكون الحجم منخفضًا أو محدودًا طبيعيًا. يضيف مجمّع العمال بنية: تزامن ثابت، حدود أوضح، ومكان طبيعي لوضع مهلات، محاولات إعادة، وقياسات. التكلفة هي كود إضافي وقرار حول ما يحدث عندما يكون النظام مشغولًا (هل تنتظر المهام، تُرفض، أم تُخزّن في مكان آخر؟).

هذا الموضوع يدور حول معالجة الخلفية اليومية: الإنتاجية، الذاكرة، والضغط العكسي (كيفية منع التحميل الزائد). لا يسعى لتغطية كل تقنيات الطوابير، محركات سير العمل الموزعة، أو ضمانات التنفيذ مرة واحدة تمامًا.

إذا كنت تبني تطبيقات كاملة منطقية خلفية باستخدام منصة مثل AppMaster (appmaster.io)، تظهر نفس الأسئلة بسرعة. عمليات الأعمال والتكاملات لا تزال بحاجة لحدود حول قواعد البيانات، APIs الخارجية، ومزودي البريد/SMS حتى لا يبطئ سير عمل واحد كل شيء.

نمطان شائعان بعبارات بسيطة

غوروتين لكل مهمة

هذا أبسط نهج: كلما وصلت وظيفة، ابدأ غوروتين للتعامل معها. “الطابور” غالبًا ما يكون ما يطلق العمل، مثل مُستقبِل قناة أو استدعاء مباشر من معالج HTTP.

الشكل المعتاد: استقبل وظيفة، ثم go handle(job). أحيانًا يكون هناك قناة كوسيلة نقل فقط، وليس كقيد.

ينجح هذا جيدًا عندما تنتظر الوظائف غالبًا على I/O (نداءات HTTP، استعلامات DB، تحميلات)، وحجم الوظائف معتدل، والارتفاعات صغيرة أو متوقعة.

الجانب السلبي أن التزامن قد ينمو دون حد واضح. هذا قد يسبّب قفزًا في الذاكرة، فتح اتصالات كثيرة جدًا، أو إغراق خدمة لاحقة.

مجمّع العمال

يبدأ مجمّع العمال بعدد ثابت من غوروتينات العمال ويغذّيها بالمهام من طابور، عادة قناة مُخزّنة في الذاكرة. كل عامل يقوم بحلقة: أخذ مهمة، معالجتها، تكرار.

الفرق الرئيسي هو السيطرة. عدد العمال هو حد صارم للتزامن. إذا وصلت المهام أسرع من قدرة العمال على إنهائها، تنتظر المهام في الطابور (أو تُرفض إذا كان الطابور ممتلئًا).

مجمّعات العمال مناسبة عندما يكون العمل مكثفًا على CPU (معالجة الصور، توليد تقارير)، أو عندما تحتاج استخدام موارد متوقعًا، أو عندما يجب حماية قاعدة بيانات أو API طرف ثالث من الارتفاعات.

أين يعيش الطابور

كلا النمطين يمكن أن يستخدم قناة في الذاكرة، وهي سريعة لكنها تختفي عند إعادة التشغيل. للمهام التي "يجب ألا تفقد" أو لسير العمل الطويل، ينتقل الطابور خارج العملية (جدول DB، Redis، أو وسيط رسائل). في هذا الإعداد، لا تزال تختار بين غوروتين لكل مهمة ومجمّع العمال، لكن كمتلقّين للطابور الخارجي.

كمثال بسيط، إذا احتاج النظام فجأة لإرسال 10,000 بريد إلكتروني، غوروتين لكل مهمة قد يحاول إرسالها كلها دفعة واحدة. المجمّع يمكنه إرسال 50 في المرة وترك الباقي ينتظر بطريقة مسيطر عليها.

الإنتاجية: ما الذي يتغير وما الذي لا يتغير

من الشائع توقع فرق كبير في الإنتاجية بين مجمّعات العمال وغوروتين لكل مهمة. في غالب الأحيان، سقف الإنتاجية يُحدّد بشيء آخر، ليس بطريقة إطلاق الغوروتينات.

الإنتاجية عادةً تصل إلى حد أقصى عند أبطأ مورد مشترك: قاعدة البيانات أو حدود API الخارجية، قرص أو عرض نطاق الشبكة، عمل مكثف على CPU (JSON/PDF/تغيير حجم صور)، الأقفال والحالة المشتركة، أو خدمات لاحقة تتباطأ تحت الحمل.

إذا كان المورد المشترك هو عنق الزجاجة، إطلاق مزيد من غوروتينات لن يُنهي العمل أسرع. سيخلق أساسًا مزيدًا من الانتظار عند نفس نقطة الاختناق.

غوروتين لكل مهمة قد يفوز عندما تكون المهام قصيرة ومعلّقة على I/O ولا تتنافس على حدود مشتركة. بدء الغوروتينات رخيص، وGo تُجدول أعدادًا كبيرة منها جيدًا. في حلقة "جلب، تحليل، كتابة صف واحد" هذا قد يبقي المعالجات مشغولة ويخفي تأخير الشبكة.

مجمّعات العمال تفوز عندما تحتاج تحديد موارد مكلفة. إذا كانت كل مهمة تحتفظ باتصال DB، تفتح ملفات، تخصّص مخازن كبيرة، أو تضرب حصة API، فإن التزامن الثابت يحافظ على استقرار الخدمة ويصل للاستيعاب الآمن الأقصى.

الفرق يظهر غالبًا في الزمن (خصوصًا p99). غوروتين لكل مهمة قد يبدو ممتازًا عند حمل منخفض، ثم ينهار فجأة عندما تتكدس المهام. المجمّعات تضيف تأخير صف (انتظار المهام لعامل متاح)، لكن السلوك أكثر استقرارًا لأنك تتجنّب هجوم القطيع على نفس الحد.

نموذج ذهني بسيط:

• إذا كان العمل رخيصًا ومستقلاً، المزيد من التزامن يمكن أن يزيد الإنتاجية.
• إذا كان العمل مُقيَّدًا بحد مشترك، المزيد من التزامن سيزيد الانتظار.
• إذا كنت تهتم بـ p99، قِس وقت الانتظار في الطابور منفصلًا عن وقت المعالجة.

الذاكرة واستخدام الموارد

الكثير من النقاش حول مجمّع العمال مقابل غوروتين لكل مهمة هو في الواقع عن الذاكرة. يمكن غالبًا زيادة CPU أفقياً أو عمودياً. فشلات الذاكرة أكثر مفاجأة وقد تقلب الخدمة بالكامل.

الغوروتين رخيص لكنه ليس مجانيًا. كل واحد يبدأ بمكدس صغير ينمو عند استدعاءات دوال أعمق أو عند الاحتفاظ بمتغيرات محلية كبيرة. هناك أيضًا حسابات جدولة وبيانات تشغيلية في runtime. عشرة آلاف غوروتين قد تكون مقبولة. مئة ألف قد تكون مفاجأة إذا احتفظ كل واحد بمراجع لبيانات مهمة كبيرة.

التكلفة المخفية الأكبر غالبًا ليست الغوروتين نفسها، بل ما تحييه. إذا وصلت المهام أسرع من انتهائها، غوروتين لكل مهمة يخلق تراكمًا غير محدود. قد يكون "الطابور" ضمنيًا (غوروتينات تنتظر أقفال أو I/O) أو صريحًا (قناة مخزنة، شريحة، دفعة في الذاكرة). في كلتا الحالتين، تنمو الذاكرة مع التراكم.

مجمّعات العمال تساعد لأنها تفرض حدًا. مع عمال ثابتين وطابور محدود، تحصل على حد ذاكرة حقيقي ونمط فشل واضح: عند امتلاء الطابور، إما تحجب، تفرّغ التحميل، أو ترسل العمل للخارج.

حساب تقريبي بسرعة:

• أقصى عدد غوروتينات = العمال + الوظائف الجارية + "المهام المنتظرة" التي أنشأتها
• الذاكرة لكل مهمة = الحمولة (بايت) + ميتاداتا + أي شيء مرجعي (طلبات، JSON مفكك، صفوف DB)
• الذاكرة القصوى للتراكم ~= عدد المهام المنتظرة * الذاكرة لكل مهمة

مثال: إذا كانت كل مهمة تحمل 200 كيلوبايت من البيانات وتركت 5,000 مهمة تتكدس، فهذا نحو 1 جيجابايت فقط للحمولات. حتى لو كانت الغوروتينات مجانية سحريًا، فالتراكم مستقل عن ذلك.

الضغط العكسي: منع ذوبان النظام

الضغط العكسي بسيط: عندما تصل الأعمال أسرع من قدرتك على إنجازها، يدفع النظام للخلف بطريقة مسيطرة بدلًا من التراكم بصمت. بدونه، لا تحصل فقط على بطء؛ بل على مهلات، نمو ذاكرة، وأخطاء يصعب إعادة إنتاجها.

عادةً تلاحظ غياب الضغط العكسي عندما تسبّب دفعة مفاجئة أنماطًا مثل ارتفاع الذاكرة وعدم هبوطها، زيادة زمن الطابور بينما تظل وحدة المعالجة مشغولة، قفزات زمنية لطلبات غير ذات صلة، تراكم محاولات إعادة، أو أخطاء مثل "عدد كبير جدًا من الملفات المفتوحة" واستنفاد مجموعة الاتصال.

أداة عملية هي قناة محدودة: حد عدد المهام التي يمكن أن تنتظر. المنتجون يحجبون عند امتلاء القناة، ما يبطئ إنشاء المهام عند المصدر.

الحجب ليس دائمًا الخيار الصحيح. للعمل الاختياري، اختر سياسة واضحة حتى يكون التحميل الزائد متوقعًا:

• إسقاط المهام منخفضة القيمة (مثل الإشعارات المكررة)
• تجميع العديد من المهام الصغيرة في كتابة واحدة أو استدعاء API واحد
• تأخير العمل مع jitter لتفادي عواصف إعادة المحاولة
• إحالة إلى طابور دائم والعودة سريعًا
• تفريغ التحميل بإرجاع خطأ واضح عند التحميل الزائد

تحديد السرعة والمهلات أدوات ضغط عكسي أيضًا. يقيّد تحديد السرعة مدى سرعك في ضرب تبعية (مزود البريد، DB، API طرف ثالث). المهلات تحدد كم يمكن للعامل أن يعلق. معًا، يمنعان تبعية بطيئة من التحول إلى انقطاع كامل.

مثال: توليد كشوف شهرية. إذا وصلت 10,000 طلب دفعة واحدة، غوروتينات غير محدودة قد تطلق 10,000 عملية توليد PDF ورفع. مع طابور محدود ومجمّع ثابت، تولد وتعيد المحاولة بوتيرة آمنة.

كيف تبني مجمّع عمال خطوة بخطوة

مجمّع العمال يحد التزامن عبر تشغيل عدد ثابت من العمال وإطعامهم مهام من طابور.

1) اختر حد تزامن آمن

ابدأ بما تقضي عليه مهامك من الوقت.

• للعمل المكثف على CPU، ضع عدد العمال قريبًا من عدد أنوية CPU.
• للعمل المعتمد على I/O (DB، HTTP، التخزين)، يمكنك زيادة العدد، لكن توقف عندما تبدأ التبعيات في إصدار مهلات أو ضغط.
• للعمل المختلط، قسَّ وضبط. نطاق مبدئي معقول غالبًا من 2x إلى 10x عدد أنوية CPU، ثم اضبط.
• احترم الحدود المشتركة. إذا كانت مجموعة اتصالات DB = 20، فوجود 200 عامل سيجعلهم يتنافسون على تلك الـ 20.

2) اختر الطابور وحجمه

القناة ذات التخزين المؤقت شائعة لأنها مدمجة وسهلة الفهم. العلبة هي ممتص الصدمات للدفعات.

العتبات الصغيرة تُظهر التحميل الزائد بسرعة (المرسلون يحجبون مبكرًا). العلب الكبيرة تُملّس الارتفاعات لكنها قد تخفي المشاكل وتزيد الذاكرة والزمن. عيّن حجم العلبة بعناية وقرّر ماذا يحدث عند امتلائها.

3) اجعل كل مهمة قابلة للإلغاء

مرّر context.Context لكل مهمة وتأكد أن كود المهمة يستخدمه (DB، HTTP). هذه هي طريقة الإيقاف النظيف عند النشر، الإغلاق، والمهلات.

func StartPool(ctx context.Context, workers, queueSize int, handle func(context.Context, Job) error) chan<- Job {
    jobs := make(chan Job, queueSize)
    for i := 0; i < workers; i++ {
        go func() {
            for {
                select {
                case <-ctx.Done():
                    return
                case j := <-jobs:
                    _ = handle(ctx, j)
                }
            }
        }()
    }
    return jobs
}

(ملاحظة: لا تُعدّل الكود أعلاه إلا بعد اختبار سلوك الإغلاق والمهلات في تطبيقك.)

4) أضف المقاييس التي ستستخدمها بالفعل

لو تتابع بضعة أعداد فقط، اجعلها هذه:

• عمق الطابور (مقدار التأخر)
• وقت انشغال العمال (مدى تشبع المجمّع)
• مدة المهمة (p50، p95، p99)
• معدل الأخطاء (ومعدلات إعادة المحاولة إن وُجدت)

هذا كافٍ لضبط عدد العمال وحجم الطابور بناءً على الأدلة لا على التخمين.

أخطاء ومزالق شائعة

معظم الفرق لا تتضرر من اختيار نمط "خطأ" بقدر ما تتضرر من افتراضات صغيرة تتحول إلى حوادث عند ارتفاع الحمل.

عندما تتكاثر الغوروتينات

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

خطأ آخر هو اعتبار قناة مخزنة ضخمة كـ"ضغط عكسي". المخزن الكبير طابور مخفي. قد يشتري وقتًا لكنه يخفي المشاكل حتى تصل إلى جدار الذاكرة. إذا كنت تحتاج طابورًا، عيّنه عن قصد وقرّر ماذا يحدث عند الامتلاء (حجب، إسقاط، إعادة المحاولة لاحقًا، أو الاستمرار في التخزين الدائم).

عنق الزجاجة المخفي

العديد من الوظائف الخلفية ليست مقيدة بالـ CPU. هي محددة بشيء لاحق. إذا تجاهلت تلك الحدود، مٌنتج سريع سيغمر مستهلكًا بطيئًا.

الفخاخ الشائعة:

• عدم وجود إلغاء أو مهلة، فيعلق العمال على استدعاء API أو استعلام DB إلى الأبد
• اختيار أعداد عمال دون التحقق من حدود حقيقية مثل اتصالات DB أو I/O القرص أو حصص طرف ثالث
• إعادة المحاولات التي تضخّم الحمل (محاولات فورية عبر 1,000 مهمة فاشلة)
• قفل مشترك أو معاملة تُسلسل كل شيء، فـ"المزيد من العمال" يزيد فقط العبء
• غياب الرؤية: لا توجد مقاييس لعمق الطابور، عمر المهمة، عدد المحاولات، واستغلال العمال

مثال: تصدير ليلي يولد 20,000 مهمة "إرسال إشعار". إذا كانت كل مهمة تضرب DB ومزود البريد، فمن السهل تجاوز مجموعات الاتصال أو الحصص. مجمّع 50 عامل مع مهلات لكل مهمة وطابور صغير يوضح الحد. غوروتين لكل مهمة مع مخزن ضخم يجعل النظام يبدو جيدًا حتى لا يكون كذلك فجأة.

مثال: تصدير وإشعارات متقطعة

تخيّل فريق دعم يحتاج بيانات من أجل تدقيق. يضغط شخص زر "تصدير"، ثم يفعله بعض الزملاء، وفجأة تُخلق 5,000 مهمة تصدير خلال دقيقة. كل تصدير يقرأ من DB، يهيئ CSV، يخزن ملفًا، ويرسل إشعارًا (بريد أو Telegram) عند الانتهاء.

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

مع مجمّع عمال، البداية أبطأ لكن العملية العامة أكثر هدوءًا. مع 50 عاملًا، فقط 50 تصديرًا تعمل في وقت واحد. استخدام DB يبقى ضمن نطاق متوقع، المخازن تُعاد استخدامُها أكثر، والزمن أكثر ثباتًا. زمن الإكمال الإجمالي أصبح أسهل للتقدير: تقريبًا (الوظائف / العمال) * متوسط زمن المهمة، مع بعض الزيادة.

الفرق الرئيسي ليس أن المجمّعات أسرع سحريًا، بل أنها تمنع النظام من إيذاء نفسه أثناء الارتفاعات. تشغيل متحكم به بمعدل 50 في المرة غالبًا ما ينتهي أسرع من 5,000 مهمة تتقاتل.

أين تطبّق الضغط العكسي يعتمد على ما تريد حمايته:

• عند طبقة الAPI، ارفض أو أخر طلبات التصدير عند انشغال النظام.
• عند الطابور، اقبل الطلبات ولكن صفّها وافرغها بوتيرة آمنة.
• في مجمّع العمال، حد التزامن للأجزاء المكلفة (قراءات DB، إنشاء ملفات، إرسال إشعارات).
• لكل مورد، قسّم الحدود (مثلاً 40 عاملًا للتصدير و10 فقط للإشعارات).
• على الاستدعاءات الخارجية، ضع تحديد سرعة للبريد/SMS/Telegram حتى لا تُحجب.

قائمة تحقق سريعة قبل الإطلاق

قبل تشغيل المهام الخلفية في الإنتاج، مرّ على الحدود، الرؤية، ومعالجة الفشل. معظم الحوادث ليست بسبب "كود بطيء" بل بسبب غياب حواجز أمان عندما يرتفع الحمل أو تتعطل تبعية.

• ضع حدًا أقصى صارمًا للتزامن لكل تبعية. لا تختَر رقمًا عالميًا واحدًا وتأمل أن يناسب كل شيء. قُدّم حدودًا لكتابات DB، استدعاءات HTTP الخارجة، والعمل المكثف على CPU منفصلة.
• اجعل الطابور محدودًا وقابلًا للرصد. ضع حدًا حقيقيًا للمهام المعلقة وكشف بعض المقاييس: عمق الطابور، عمر أقدم مهمة، ومعدل المعالجة.
• أضف محاولات مع jitter ومسار صندوق رسائل فاشلة. أعد المحاولة انتقائيًا، فرِّق المحاولات، وبعد N فشل حرك المهمة إلى صندوق رسائل فاشلة أو جدول "فشل" مع تفاصيل كافية للمراجعة وإعادة التشغيل.
• تحقّق من سلوك الإغلاق: التصريف، الإلغاء، والاستئناف بأمان. قرّر ماذا يحدث عند النشر أو التعطّل. اجعل المهام idempotent حتى يكون إعادة المعالجة آمنًا، واحتفظ بتقدم سير العمل الطويل.
• حمِ النظام بمهلات وكواشف الدائرة (circuit breakers). كل استدعاء خارجي يحتاج مهلة. إذا كانت تبعية متوقفة، افشل بسرعة (أو أوقف الاستقبال) بدلًا من تراكم العمل.

خطوات عملية تالية

اختر النمط الذي يتناسب مع شكل النظام في يوم عادي، لا يوم مثالي. إذا كانت الأعمال تأتي دفعات (رفوع، تصديرات، حملات بريد)، فمجمّع ثابت وطابور محدود هو الافتراض الآمن عادة. إذا كان العمل ثابتًا وكل مهمة صغيرة، غوروتين لكل مهمة قد يكون كافيًا، بشرط أن تضع حدودًا في مكان ما.

الخيار الفائز عادة هو الذي يجعل الفشل مملاً. المجمّعات توضح الحدود. غوروتين لكل مهمة يسهل نسيان الحدود حتى أول ارتفاع حقيقي.

ابدأ بسيطًا، ثم أضف حدودًا ورؤية

ابدأ بشيء واضح، لكن أضف عنصرين تحكمان مبكرًا: حد على التزامن وطريقة لرؤية الطوابير والأخطاء.

خطة نشر عملية:

• حدِّد شكل عبء العمل: دفعات، ثابت، أم مختلط (وماذا يعني "الذروة").
• ضع حدًا صارمًا على العمل الجاري (حجم المجمّع، سمافور، أو قناة محدودة).
• قرّر ماذا يحدث عند الوصول إلى الحد: حجب، إسقاط، أو إرجاع خطأ واضح.
• أضف مقاييس أساسية: عمق الطابور، وقت البقاء في الطابور، زمن المعالجة، المحاولات، وصناديق الرسائل الفاشلة.
• اختبر التحميل بدفعة تعادل 5x ذروة متوقعة وراقب الذاكرة والزمن.

متى لا يكفي المجمّع

إذا كانت سير العمل تستمر دقائق أو أيام، قد يكافح المجمّع البسيط لأن العمل ليس "نفذ مرة" فقط. تحتاج حالة، محاولات إعادة، وقابلية الاستئناف. هذا يعني عادةً حفظ التقدم، خطوات idempotent، وتطبيق backoff. قد تحتاج أيضًا تقسيم مهمة كبيرة إلى خطوات أصغر لتتمكن من استئنافها بأمان بعد عطل.

إذا أردت شحن باك‌اند كامل مع سير عمل أسرع، AppMaster (appmaster.io) يمكن أن يكون خيارًا عمليًا: تصمّم البيانات والمنطق بصريًا، ويولّد كود Go حقيقي للباك‌اند حتى تحافظ على نفس الانضباط حول حدود التزامن، الطوابير، والضغط العكسي دون توصيل كل شيء يدويًا.