أفضل 6 أنظمة انتظار لمطوري الواجهة الخلفية

هل تبحث عن نظام طابور؟ أو ربما تبحث عن أفضل؟ هنا كل المعلومات التي تحتاجها!

تعد أنظمة قائمة الانتظار من أفضل أسرار تطوير الواجهة الخلفية.

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

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

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

ما هو نظام الطابور؟

لنبدأ بفهم ما هي قائمة الانتظار.

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

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

لماذا تحتاج أنظمة الطابور؟

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

معالجة الخلفية

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

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

التنفيذ الموازي

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

  كيفية اختراق جهاز Wii U لتشغيل ألعاب وتطبيقات البيرة

بمجرد أن ينمو تطبيقك ويبدأ في تلقي أكثر من 100 طلب في الدقيقة في المتوسط ​​، سيبدأ في التخلف أكثر فأكثر ولن يكون قادرًا على إكمال جميع الوظائف.

في نظام الطابور ، يمكن تجنب هذا الموقف عن طريق إعداد عدة عمال ، يمكن لكل منهم اختيار وظيفة (تحتوي على 100 تقرير يتم إنجازها لكل منهم) والعمل بالتوازي لإنهاء المهمة في وقت أقرب بكثير.

التعافي من الفشل

لا نفكر عمومًا في الفشل كمطورين على الويب. نحن نعتبر أن خوادمنا وواجهات برمجة التطبيقات التي نستخدمها ستكون دائمًا على الإنترنت أمرًا مفروغًا منه. لكن الواقع مختلف – انقطاع الشبكة أمر شائع جدًا ، وقد تكون واجهات برمجة التطبيقات الممتازة التي تعتمد عليها معطلة بسبب مشكلات البنية التحتية (قبل أن تقول “لست أنا!” ، لا تنسَ انقطاع كبير في خدمة Amazon S3). لذا ، بالعودة إلى مثال إعداد التقارير ، إذا كان جزء من إنشاء التقرير يتطلب منك الاتصال بواجهة برمجة تطبيقات المدفوعات وكان هذا الاتصال معطلاً لمدة دقيقتين ، فماذا يحدث للتقارير الـ 200 التي فشلت؟

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

مع هذا بعيدًا ، دعنا نلقي نظرة على بعض الخيارات الشائعة بين قوائم الانتظار الخلفية / الأنظمة اليوم.

ريديس

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

مزايا Redis هي:

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

يرجى ملاحظة أن Redis ليس لديه أي رسائل تجريدية / قائمة انتظار / استرداد ، لذلك تحتاج إما إلى استخدام حزمة أو إنشاء نظام خفيف الوزن بنفسك. مثال على ذلك هو أن Redis هي الواجهة الخلفية الافتراضية لقائمة الانتظار لإطار عمل Laravel PHP ، حيث تم تنفيذ جدولة من قبل مؤلفي إطار العمل.

تعلم Redis سهل.

الأرنب

هناك بعض الفروق الدقيقة بين Redis و الأرنب، فلنخرجهم من الطريق أولاً.

بادئ ذي بدء ، يمتلك RabbitMQ دورًا أكثر تخصصًا ومُحددًا جيدًا ، ولذا فقد تم تصميمه ليعكس ذلك – الرسائل. بعبارة أخرى ، النقطة الرائعة هي العمل كوسيط بين نظامين ، وهذا ليس هو الحال بالنسبة لـ Redis ، التي تعمل كقاعدة بيانات. نتيجة لذلك ، يوفر RabbitMQ عددًا قليلاً من التسهيلات المفقودة في Redis: توجيه الرسائل ، وإعادة المحاولة ، وتوزيع الأحمال ، وما إلى ذلك.

  خطأ وكيل Netflix - كيفية تجاوز Netflix وإلغاء حظره

إذا فكرت في الأمر ، يمكن أيضًا اعتبار قوائم انتظار المهام كنظام مراسلة ، حيث يمكن اعتبار المجدول والعاملين و “مقدمو المهام” كيانات تشارك في تمرير الرسائل.

يتمتع RabbitMQ بالمزايا التالية:

  • تجريدات أفضل لتمرير الرسائل ، وتقليل العمل على مستوى التطبيق إذا كان تمرير الرسائل هو ما تحتاجه.
  • أكثر مرونة في مواجهة حالات انقطاع التيار الكهربائي وانقطاع التيار (من Redis ، على الأقل افتراضيًا).
  • دعم الكتلة والاتحاد لعمليات النشر الموزعة.
  • أدوات مفيدة لإدارة ومراقبة عمليات النشر الخاصة بك.
  • دعم عمليا لجميع لغات البرمجة غير التافهة الموجودة هناك.
  • النشر باستخدام الأداة التي تختارها (Docker ، Chef ، Puppet ، إلخ).

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

اكتيفمق

إذا كنت تعمل في مجال المؤسسة (أو تنشئ تطبيقًا موزعًا بدرجة عالية وواسع النطاق) ، ولا تريد إعادة اختراع العجلة طوال الوقت (وارتكاب أخطاء على طول الطريق) ، اكتيفمق يستحق نظرة.

هنا حيث يتفوق ActiveMQ:

  • يتم تنفيذه في Java وكذلك تكامل Java الأنيق حقًا (يتبع معيار JMS).
  • دعم بروتوكولات متعددة: AMQP ، MQTT ، STOMP ، OpenWire ، إلخ.
  • يتعامل مع الأمان والتوجيه وانتهاء صلاحية الرسائل والتحليلات وما إلى ذلك خارج الصندوق.
  • دعم متكامل لأنماط الرسائل الموزعة الشائعة ، مما يوفر لك الوقت والأخطاء المكلفة.

هذا لا يعني أن ActiveMQ متاح فقط لـ Java. لديها عملاء لـ Python و C / C ++ و Node و .Net والنظم البيئية الأخرى ، لذلك يجب ألا تكون هناك مخاوف من حدوث انهيار محتمل في المستقبل. إلى جانب ذلك ، تم تصميم ActiveMQ وفقًا لمعايير مفتوحة تمامًا ، كما يجب أن يكون بناء عملاءك خفيفي الوزن أمرًا سهلاً.

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

أمازون إم كيو

أمازون MQ يستحق ذكرًا سريعًا ولكنه مهم هنا. إذا كنت تعتقد أن ActiveMQ هو الحل المثالي لاحتياجاتك ولكنك لا ترغب في التعامل مع إنشاء البنية التحتية وصيانتها بنفسك ، فإن Amazon MQ تقدم خدمة مُدارة للقيام بذلك. إنه يدعم جميع البروتوكولات التي يقوم بها ActiveMQ – لا يوجد اختلاف في الميزات على الإطلاق – لأنه يستخدم ActiveMQ نفسه تحت السطح.

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

أمازون SQS

لا يمكننا أن نتوقع من أمازون الجلوس بهدوء عندما يتعلق الأمر بأجزاء البنية التحتية الحيوية ، هل يمكننا ذلك؟ 🙂

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

  كيفية استنساخ تكوين Kodi ونسخ الإعداد الخاص بك

إذن ، متى تريد استخدام Amazon SQS؟ فيما يلي بعض الأسباب:

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

بشكل عام ، يعد Amazon SQS خيارًا قويًا لأي شخص يرغب في دمج قوائم انتظار الوظائف في نظامه دون الحاجة إلى القلق بشأن تثبيت / مراقبة الأشياء بأنفسهم.

فاصولياء

فاصولياء كان موجودًا منذ فترة طويلة وهو عبارة عن واجهة خلفية مجربة وسريعة وسهلة لصفوف الوظائف. هناك بعض خصائص Beanstalkd التي تجعلها تختلف اختلافًا كبيرًا عن Redis:

  • إنه نظام طابور وظيفي بشكل صارم ولا شيء آخر. أنت تدفع بالوظائف إليها ، والتي يتم سحبها من قبل عمال الوظائف في وقت لاحق. لذلك إذا كان التطبيق الخاص بك لديه حاجة صغيرة لتمرير الرسائل ، فأنت تريد تجنب Beanstalkd.
  • لا توجد هياكل بيانات متقدمة مثل المجموعات وقوائم الانتظار ذات الأولوية وما إلى ذلك.
  • Beanstalkd هو ما يسمى بقائمة انتظار First In ، First Out (FIFO). لا توجد طريقة لترتيب الوظائف حسب الأولوية.
  • لا توجد خيارات للتجميع.

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

استنتاج

إذا كنت قد قرأت هذا الحد (أو وصلت هنا إلى القراءة السريعة 😉) ، فهناك فرصة جيدة جدًا لأنك مهتم بأنظمة قائمة الانتظار أو تحتاج إلى واحد. إذا كان الأمر كذلك ، فإن القائمة الموجودة في هذه الصفحة ستخدمك جيدًا ، إلا إذا كنت تبحث عن نظام قائمة انتظار خاص بلغة / إطار عمل.

أتمنى أن أقول لكم إن قائمة الانتظار بسيطة وموثوقة بنسبة 100٪ ، لكنها ليست كذلك. إنه فوضوي ، وبما أن كل شيء في الخلفية ويحدث بسرعة كبيرة (يمكن أن تمر الأخطاء دون أن يلاحظها أحد وتصبح مكلفة للغاية). ومع ذلك ، فإن قوائم الانتظار ضرورية للغاية بعد نقطة واحدة ، وستجد أنها سلاح قوي (ربما حتى الأقوى) في ترسانتك. حظا طيبا وفقك الله! 🙂