الأخبار التكنولوجية والاستعراضات والنصائح!

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

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

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

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

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

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

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

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

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

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

لماذا تحتاج إلى نظام طابور؟

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

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

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

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

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

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

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

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

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

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

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

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

الفجل

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

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

مزايا Redis هي:

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

    تعلم Redis سهل.

    الأرنب

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

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

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

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

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

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

    اكتيفمق

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

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

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

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

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

    Amazon MQ

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

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

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

    Amazon SQS

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

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

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

    لذا متى ترغب في استخدام Amazon QS؟ فيما يلي بعض الأسباب:

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

    شجرة الفاصولياء

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

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

    استنتاج

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

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