ما الفرق بين RabbitMQ وRedis؟

RabbitMQ هو وسيط رسائل، بينما خادم القاموس البعيد (Redis) هو مخزن بيانات مفتاح-قيمة في الذاكرة. ومع ذلك، يُمكنك مقارنة التقنيتين لأنه يمكنك استخدامهما في إنشاء نظام رسائل النشر والاشتراك (pub/sub). في تصميم السحابة الحديث، تُفصَل التطبيقات إلى كتل برمجية إنشائية مستقلة أصغر تُسمى الخدمات. وتوفر رسائل النشر/الاشتراك إشعارات فورية للأحداث لهذه الأنظمة الموزعة. RabbitMQ هو وسيط رسائل موزَّع يجمع البيانات المتدفقة من مصادر متعددة ويوجهها إلى وجهات مختلفة للمعالجة. يدعم Redis نظامًا قائمًا على الدفع حيث يوزع الناشر الرسائل على جميع المشتركين عند وقوع حدث.

اقرأ حول Redis »

آلية العمل: RabbitMQ مقابل Redis

يسمح كل من RabbitMQ وRedis للتطبيقات والخدمات المصغرة ومكونات البرامج بتبادل الرسائل بطرق مختلفة. 

سير عمل RabbitMQ

يستخدم RabbitMQ بروتوكول وضع الرسائل في قوائم انتظار متقدمة (AMQP) في إرسال الرسائل بأمان من خلال وسطاء رسائل. وسيط الرسائل يتكون من تبادلات وقوائم انتظار. فيما يلي آلية عمل هذه العملية:

  1. يُرسل مُنتِج البيانات رسائل إلى RabbitMQ
  2. يقوم أحد التبادلات باستقبال البيانات وتوجيهها إلى قائمة الانتظار المعنية وفقًا لمجموعة من القواعد تُسمى روابط
  3. تبقى الرسالة في قائمة الانتظار حتى يلتقطها أحد مستهلكي RabbitMQ

عندما تصل قائمة الانتظار إلى السعة القصوى، يمنع RabbitMQ المنتجين من نشر الرسائل حتى يتعامل المستهلكون مع الرسائل غير المقروءة. يُمكن لـ RabbitMQ أيضًا استعادة الرسائل في حالة فشل التبادل قبل أن يقرأها المستهلكون.

سير عمل Redis

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

على سبيل المثال، يُمكنك فصل بيانات التجارة الإلكترونية إلى مفاتيح اسم العميل، والبريد الإلكتروني، والعناصر المشتراة، والتعليقات. بعد ذلك، تنشر لكل مفتاح البيانات ذات الصلة. 

يُمكّن Redis التبادل في الوقت الفعلي للرسائل المحتفظ بها لمدة قصيرة. إنه يعمل على النحو التالي:

  1. يُرسل مُنتِج البيانات رسائل إلى Redis
  2. تفحص عقدة Redis مفتاح الرسالة لتحديد المشتركين المهتمين
  3. يُسلّم Redis الرسالة إلى جميع المشتركين المتصلين

 

معالجة الرسائل: RabbitMQ مقابل رسائل النشر والاشتراك (pub/sub) في Redis

يوفر كل من Redis وRabbitMQ آليات للنشر والاشتراك (pub/sub) للتطبيقات لتوزيع الرسائل عبر البيئة السحابية. ومع ذلك، يختلفان اختلافًا كبيرًا في معالجة الرسائل.

القراءة عن رسائل النشر والاشتراك (pub/sub) »

تسليم الرسائل

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

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

حجم الرسائل

يمكن لـ RabbitMQ تسليم رسائل أكبر حجمًا بدون أن يحدث انخفاض كبير في الأداء. تم تصميمه في البداية للتعامل مع الرسائل التي يصل حجمها إلى 2 جيجابايت ولكن في وقتٍ لاحق تم تخفيض الحد إلى 128 ميجابايت.

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

استمرارية الرسالة

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

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

تشفير الرسائل

يستخدم RabbitMQ طبقة مآخذ التوصيل الآمنة (SSL) في تشفير البيانات المتنقلة بين المنتجين والوسطاء والمستهلكين. تشفير الرسائل يساعد المؤسسات في حماية المعلومات السرية وتقليل المخاطر المعرض لها البيانات.

وفي الوقت نفسه، لا يدعم Redis طبقة مآخذ التوصيل الآمنة (SSL). لا يتوفر دعم طبقة مآخذ التوصيل الآمنة (SSL) في Redis إلا في الإصدار 6.0 فما يليه. لتمكين طبقة مآخذ التوصيل الآمنة (SSL)، يجب على المطورين الحصول على شهادات طبقة مآخذ التوصيل الآمنة (SSL) من مجموعة Redis وإنشاء شهادة عميل لقاعدة البيانات لديهم.

الأداء: RabbitMQ مقابل رسائل النشر والاشتراك (pub/sub) في Redis

إن الاختلافات في معالجة الرسائل تؤثر على أداء RabbitMQ وRedis في السيناريوهات المختلفة.

السرعة

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

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

على سبيل المقارنة، يستطيع Redis إرسال ما يصل إلى عشرات الملايين من الرسائل في الثانية، بينما RabbitMQ يعالج ما يصل إلى عشرات الآلاف من الرسائل في الثانية. 

التوافر

يختلف كل من RabbitMQ وRedis في طريقة التعامل مع التجميع الذي يسمح لأنظمة وسيط الرسائل بتكرار العُقد.

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

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

حالات الاستخدام: RabbitMQ مقابل رسائل النشر والاشتراك (pub/sub) في Redis

يتفوق RabbitMQ على Redis في مجالات كثيرة، ولكن هذا لا يعني أن RabbitMQ هو أفضل نظام لتوزيع الرسائل لجميع التطبيقات. 

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

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

ملخص الاختلافات: RabbitMQ مقابل رسائل النشر والاشتراك (pub/sub) في Redis

 

RabbitMQ

Redis

تسليم الرسائل

يضمن تسليم الرسائل. يدعم المنطق المعقد.

لا يضمن تسليم الرسائل. يتطلب اتصالاً نشطًا من المشتركين.

حجم الرسائل

حجم الرسالة محدود بـ 128 ميجابايت. يمكن التعامل مع الرسائل الكبيرة. 

لا يوجد حد للرسائل، ولكن الأداء يتدهور مع الرسائل الكبيرة (التي تزيد عن 1 ميجابايت).

استمرارية الرسالة

يدعم الرسائل المستمرة والرسائل العابرة. يكتب الرسائل المستمرة على القرص.

بشكل افتراضي، لا يدعم الرسائل المستمرة.

تشفير الرسائل

يدعم تشفير طبقة مآخذ التوصيل الآمنة (SSL).

تشفير طبقة مآخذ التوصيل الآمنة (SSL) متوفر في Redis بدايةً من الإصدار 6.0 فما يليه. 

السرعة

يصل إلى عشرات الآلاف من الرسائل في الثانية.

يصل إلى ملايين الرسائل في الثانية.

التوفر

يقوم بإنشاء العديد من عُقد النظير إلى النظير في مجموعة.

يستخدم نموذج القائد-المتابع (leader-follower) في التجميع. 

كيف تساعدك AWS في تلبية متطلبات RabbitMQ وRedis؟

توفر Amazon Web Services (AWS) خدماتٍ مُدارةَ لتشغيل أنظمة وسيط الرسائل مفتوحة المصدر على نطاق واسع. يسهل عليك إعداد خدمات النشر والاشتراك (pub/sub) ودمجها مع خدمات AWS الأخرى.

فيما يلي عروض AWS التي يُمكنك استخدامها مع Redis وRabbitMQ:

  • مع Amazon MemoryDB for Redis، يُمكنك إضافة قوة التحمل عند تسليم الرسائل على Redis. يُمكنك تشغيل تغذيات بيانات التدفق بتزامن عالٍ لاستيعاب نشاط المستخدم ودعم الملايين من الطلبات يوميًا لتطبيقات الوسائط وتطبيقات الترفيه.
  • مع Amazon MQ، يُمكنك توفير وسطاء RabbitMQ بدون عمليات إعداد تستغرق وقتًا طويلاً. إنه يُشفّر رسائل RabbitMQ أثناء النقل وفي أوقات عدم النشاط، ما يساعد في ضمان التوافر العالي لمسارات البيانات عبر مناطق توافر الخدمات من AWS.

بدلاً من استخدام Redis أو RabbitMQ، يُمكنك أيضًا استخدام خدمة الإشعارات البسيطة في Amazon (Amazon SNS) لإنشاء نظام رسائل النشر والاشتراك (pub/sub). يُمكنك مباشرةً إرسال رسائل من تطبيقاتك إلى العملاء أو التطبيقات الأخرى بطريقة قابلة للتوسع وميسورة التكلفة.

توفر خدمة Amazon SNS عدة ميزات:

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

بادر اليوم باستخدام رسائل النشر والاشتراك (pub/sub) وRedis وRabbitMQ على AWS من خلال إنشاء حساب.

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

ابدأ التطوير باستخدام RabbitMQ
تعرَّف على كيفية بدء استخدام Amazon MQ