نمط المفاعل

نمط تصميم البرمجيات المفاعل هو استراتيجية لمعالجة الأحداث قادرة على الاستجابة للعديد من طلبات الخدمة المحتملة في وقت واحد . المكون الرئيسي لهذا النمط هو حلقة أحداث ، تعمل في خيط أو عملية واحدة ، تقوم بفصل الطلبات الواردة وتوجيهها إلى معالج الطلبات الصحيح. ^{[ 1 ]}

بالاعتماد على آليات قائمة على الأحداث بدلاً من عمليات الإدخال/الإخراج المتزامنة أو تعدد الخيوط ، يستطيع المفاعل معالجة العديد من طلبات الإدخال/الإخراج المتزامنة بأقل تأخير ممكن. ^{[ 2 ]} كما يتيح المفاعل تعديل أو توسيع إجراءات معالجة الطلبات المحددة بسهولة، على الرغم من أن هذا النمط له بعض العيوب والقيود. ^{[ 1 ]}

بفضل توازنه بين البساطة وقابلية التوسع ، أصبح المفاعل عنصرًا معماريًا أساسيًا في العديد من تطبيقات الخوادم وأطر البرمجيات الخاصة بالشبكات . كما توجد مشتقات مثل المفاعل المتعدد والمفاعل التنافسي لحالات خاصة تتطلب إنتاجية أو أداءً أو تعقيدًا أكبر في الطلبات. ^{[ 1 ] [ 2 ] [ 3 ] [ 4 ]}

كانت الاعتبارات العملية لنموذج العميل والخادم في الشبكات الكبيرة، مثل مشكلة C10k لخوادم الويب ، هي الدافع الأصلي لنمط المفاعل. ^{[ 5 ]}

تتمثل إحدى الطرق البسيطة للتعامل مع طلبات الخدمة من نقاط نهاية متعددة محتملة، مثل منافذ الشبكة أو مُعرّفات الملفات ، في الاستماع إلى الطلبات الجديدة من داخل حلقة أحداث، ثم قراءة أول طلب على الفور. بمجرد قراءة الطلب بالكامل، يمكن معالجته وإعادة توجيهه عن طريق استدعاء المعالج المناسب مباشرةً. يُعدّ خادم "تكراري" بالكامل كهذا، والذي يتعامل مع طلب واحد من البداية إلى النهاية في كل تكرار لحلقة الأحداث، صحيحًا منطقيًا. ومع ذلك، سيتأخر هذا الخادم عند تلقيه طلبات متعددة متتالية بسرعة. لا يمكن للنهج التكراري التوسع لأن قراءة الطلب تُعطّل مؤشر الترابط الوحيد للخادم حتى يتم استلام الطلب بالكامل، وعادةً ما تكون عمليات الإدخال/الإخراج أبطأ بكثير من العمليات الحسابية الأخرى. ^{[ 2 ]}

إحدى استراتيجيات التغلب على هذا القيد هي المعالجة المتعددة الخيوط: فمن خلال فصل كل طلب جديد فورًا إلى خيط معالجة مستقل، لن يعيق الطلب الأول حلقة الأحداث، مما يسمح لها بالتكرار ومعالجة طلب آخر مباشرةً. يتميز تصميم "خيط لكل اتصال" هذا بقابلية توسع أفضل من التصميم التكراري البحت، ولكنه لا يزال يعاني من أوجه قصور متعددة، وسيواجه صعوبات بعد حد معين. من منظور موارد النظام الأساسية ، يفرض كل خيط أو عملية جديدة تكاليف إضافية في الذاكرة ووقت المعالجة (بسبب تبديل السياق ). كما أن عدم الكفاءة الأساسي المتمثل في انتظار كل خيط لانتهاء عمليات الإدخال/الإخراج لم يُحل بعد. ^{[ 1 ] [ 2 ]}

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

1. احتفظ بمعالج أحداث أحادي الخيوط؛ إذ أن تعدد الخيوط يُضيف عبئًا وتعقيدًا دون حل المشكلة الحقيقية المتمثلة في حظر عمليات الإدخال/الإخراج
2. استخدم آلية إشعار الأحداث لفك تعدد إرسال الطلبات فقط بعد اكتمال عمليات الإدخال/الإخراج (بحيث تكون عمليات الإدخال/الإخراج غير محظورة بشكل فعال).
3. قم بتسجيل معالجات الطلبات كوظائف رد نداء مع معالج الأحداث لتحسين فصل الاهتمامات

يؤدي الجمع بين هذه الأفكار إلى نمط المفاعل، الذي يوازن بين مزايا المعالجة أحادية الخيوط والإنتاجية العالية وقابلية التوسع. ^{[ 1 ] [ 2 ]}

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

مع ذلك، فإن نمط المفاعل له قيود، أبرزها استخدام دوال الاستدعاء، مما يزيد من صعوبة تحليل البرنامج وتصحيح الأخطاء ، وهي مشكلة شائعة في التصاميم ذات التحكم المعكوس . ^{[ 1 ]} تتجنب الأساليب الأبسط، مثل استخدام خيط لكل اتصال والأساليب التكرارية الكاملة، هذه المشكلة، ويمكن أن تكون حلولًا فعالة إذا لم تكن قابلية التوسع أو الإنتاجية العالية مطلوبة. ^{[ أ ]}

قد يُصبح استخدام خيط معالجة واحد عائقًا في حالات الاستخدام التي تتطلب أقصى إنتاجية، أو عندما تتضمن الطلبات معالجة مكثفة. يمكن لتصميمات متعددة الخيوط التغلب على هذه القيود، وفي الواقع، لا يزال بعضها يستخدم نمط المفاعل كمكون فرعي لمعالجة الأحداث وعمليات الإدخال/الإخراج. ^{[ 1 ]}

• 
  مخطط مكونات UML 2 لتطبيق تفاعلي. ^{[ 1 ]}
• 
  مخطط تسلسل UML 2 لخادم تفاعلي. ^{[ 1 ]}

يتكون التطبيق التفاعلي من عدة أجزاء متحركة وسيعتمد على بعض آليات الدعم: ^{[ 1 ]}

مقبض

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

مُزيل الإشارات

مُرسِل أحداث قادر على مراقبة حالة مُعرِّف بكفاءة، ثم إخطار الأنظمة الفرعية الأخرى بتغيير الحالة ذي الصلة (عادةً ما يكون مُعرِّف الإدخال/الإخراج جاهزًا للقراءة). تقليديًا، كان يتم أداء هذا الدور بواسطة استدعاء النظام select() ، ولكن من الأمثلة الحديثة epoll و kqueue و IOCP .

المرسل

حلقة الأحداث الفعلية للتطبيق التفاعلي، يحتفظ هذا المكون بسجل معالجات الأحداث الصالحة، ثم يستدعي المعالج المناسب عند حدوث حدث ما.

معالج الأحداث

يُعرف هذا أيضًا باسم معالج الطلبات، وهو عبارة عن منطق مُحدد لمعالجة نوع واحد من طلبات الخدمة. يقترح نمط المُفاعل تسجيل هذه المعالجات ديناميكيًا مع المُوزِّع كوظائف رد نداء (callbacks) لمزيد من المرونة. افتراضيًا، لا يستخدم المُفاعل تعدد الخيوط، ولكنه يستدعي معالج الطلبات ضمن نفس خيط المُوزِّع.

واجهة معالج الأحداث

فئة واجهة مجردة، تمثل الخصائص والأساليب العامة لمعالج الأحداث. يجب على كل معالج أحداث محدد تطبيق هذه الواجهة، بينما سيعمل الموزع على معالجات الأحداث من خلال هذه الواجهة.

يُعد نمط المفاعل القياسي كافياً للعديد من التطبيقات، ولكن بالنسبة للتطبيقات التي تتطلب متطلبات خاصة، يمكن أن توفر التعديلات طاقة أكبر على حساب زيادة التعقيد.

يتمثل أحد التعديلات الأساسية في استدعاء معالجات الأحداث في سلاسل عمليات منفصلة لزيادة التزامن. إن تشغيل المعالجات في مجمع سلاسل عمليات ، بدلاً من إنشاء سلاسل عمليات جديدة عند الحاجة، سيبسط عملية تعدد سلاسل العمليات ويقلل من الحمل الزائد. وهذا يجعل مجمع سلاسل العمليات مكملاً طبيعياً لنمط المفاعل في العديد من حالات الاستخدام. ^{[ 2 ]}

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

يُعرف هذا النوع باسم "المفاعل المتعدد"، وهو يضمن استخدام الخادم المخصص لكامل قدرة معالجة الأجهزة. ولأن الخيوط المنفصلة عبارة عن حلقات أحداث طويلة الأمد، فإن عبء إنشاء الخيوط وتدميرها يقتصر على بدء تشغيل الخادم وإيقافه. ومع توزيع الطلبات على موزعات مستقلة، يوفر المفاعل المتعدد أيضًا توافرًا وموثوقية أفضل؛ ففي حال حدوث خطأ وتعطل موزع واحد، فإنه سيقاطع فقط الطلبات المخصصة لحلقة الأحداث تلك. ^{[ 3 ] [ 4 ]}

بالنسبة للخدمات المعقدة بشكل خاص، حيث يجب الجمع بين المتطلبات المتزامنة وغير المتزامنة، يُعد نمط المُفاعل البديل الآخر. هذا النمط أكثر تعقيدًا من نمط المُفاعل، وله تفاصيله الهندسية الخاصة، ولكنه لا يزال يستخدم مكونًا فرعيًا للمُفاعل لحل مشكلة حجب الإدخال/الإخراج. ^{[ 3 ]}

• مشكلة C10k
• البرمجة القائمة على الأحداث
• المدخلات/المخرجات
• ليبفينت
• البرمجة التفاعلية

أنماط ذات صلة:

• الكائن النشط
• نمط المراقب
• نمط Proactor ، الذي يسمح بمزج معالجة الأحداث المتزامنة وغير المتزامنة

تطبيقات محددة:

• أليكسييف، أندرو (30 مارس 2012). "الفصل 14: nginx" . في: براون، إيمي؛ ويلسون، جريج (محرران). بنية تطبيقات المصادر المفتوحة . المجلد  2. Lulu.com. ISBN 9781105571817.

أمثلة على التطبيقات:

• شبكات APR ونمط المفاعل
• بنية خادم قابل للتوسع بدرجة عالية يعتمد على تقنية NIO