ما الفرق بين Kafka وRedis؟
Redis عبارة عن مخزن بيانات المفاتيح والقيم في الذاكرة، في حين أن Apache Kafka هو محرِّك معالجة التدفق. ومع ذلك، يمكنك مقارنة التقنيتين لأنه يمكنك استخدام كلتيهما لإنشاء نظام رسائل النشر والاشتراك (pub/sub). في تصميم السحابة الحديث، تُفصَل التطبيقات إلى كتل برمجية إنشائية مستقلة أصغر تُسمى الخدمات. وتوفر رسائل النشر/الاشتراك إشعارات فورية للأحداث لهذه الأنظمة الموزعة. تدعم Kafka نظامًا قائمًا على السحب حيث يتشارك الناشرون والمشتركون في قائمة انتظار رسائل مشتركة يسحب منها المشتركون الرسائل حسب الحاجة. يدعم Redis نظامًا قائمًا على الدفع حيث يوزع الناشر الرسائل على جميع المشتركين عند وقوع حدث.
آلية العمل: Kafka مقابل رسائل النشر والاشتراك (pub/sub) في Redis
Apache Kafka عبارة عن منصة لتدفق الأحداث تتيح لتطبيقات متعددة تدفق البيانات بشكل مستقل عن بعضها البعض. وترسل هذه التطبيقات، المعروفة باسم المنتجين والمستهلكين، معلومات النشر والاشتراك إلى بعض أقسام البيانات المعروفة باسم الموضوعات، وتتلقاها منها.
من ناحية أخرى، Redis مصمم كقاعدة بيانات في الذاكرة لدعم نقل البيانات بزمن انتقال منخفض فيما بين التطبيقات. ويخزن كل الرسائل في ذاكرة الوصول العشوائي (RAM) بدلاً من القرص الثابت لتقليل وقت قراءة البيانات وكتابتها. يمكن للعديد من المستهلكين الاشتراك في تدفق البيانات في Redis لاسترداد الرسائل تمامًا مثل Kafka.
على الرغم من أنه يمكنك استخدام Kafka وRedis في رسائل النشر والاشتراك (pub/sub)، فإنهما يعملان بطريقة مختلفة.
سير عمل Kafka
تربط Apache Kafka بين المنتجين والمستهلكين من خلال كُتل الحوسبة. وتتكون كل كتلة من عدة وسطاء في Kafka موجودين على خوادم مختلفة.
تنشئ Kafka موضوعات وأقسامًا لتلبية الأغراض التالية:
- موضوعات الغرض منها تجميع البيانات المماثلة التي تنتمي إلى موضوع اهتمام معين، مثل البريد الإلكتروني والدفع والمستخدمين والشراء
- أقسام عبر مختلف الوسطاء لعمل نسخ متماثل للبيانات والتعامل مع الأعطال
يرسل المنتجون رسائل نشر إلى الوسيط. وعندما يتلقى الوسيط رسالة ما، فإنه يصنف البيانات حسب الموضوع ويخزنها في أحد الأقسام. ومن ثمّ، يتصل المستهلكون بالموضوع المناسب ويستخرجون البيانات من القسم الخاص به.
سير عمل Redis
يعمل Redis بهيكلة الخادم والعميل كنظام قاعدة بيانات NoSQL. ويقترن المنتجون والمستهلكون اقترانًا غير محكم، ولا يتعين عليهم معرفة بعضهم البعض عند إرسال الرسائل.
يستخدم Redis المفاتيح والعُقد الرئيسة والثانوية في تلبية الأغراض التالية:
- استخدام المفاتيح من أجل تجميع الرسائل المماثلة. فعلى سبيل المثال، "البريد الإلكتروني" هو مفتاح يشير إلى مخزن البيانات الذي يتضمن رسائل البريد الإلكتروني فقط.
- استخدام العُقد الرئيسة والثانوية في عمل نسخ متماثلة من الرسائل.
عندما يرسل منتج رسالة ما إلى عقدة معينة، يسلم Redis الرسالة إلى كل المشتركين المتصلين من خلال التحقق من مفتاح الرسالة. يجب على المستهلك دائمًا بدء اتصال نشط بخادم Redis والحفاظ عليه لتلقي الرسائل. ويُعرف ذلك بدلالات التسليم المتصلة.
معالجة الرسائل: Kafka مقابل رسائل النشر والاشتراك (pub/sub) في Redis
تزود Apache Kafka المطورين بأنظمة مراسلة موزَّعة قابلة للتحجيم بدرجة كبيرة. بينما يوفر Redis هياكل بيانات غنية تتيح للتطبيق دفع البيانات إلى عُقد متعددة بسرعة. توجد اختلافات عديدة بين آليتَي وضع الرسائل في قائمة الانتظار هاتين.
حجم الرسائل
يكون لكل من Kafka وRedis الأداء الأفضل عند إرسال حِزم بيانات صغيرة الحجم فيما بين المستهلكين والمشتركين.
إن Redis غير مُصمم بوجه خاص للتعامل مع أحجام البيانات الكبيرة بدون التأثير في معدل النقل. ولا يمكنه أيضًا تخزين كميات كبيرة من البيانات حيث تتوفر ذاكرة الوصول العشوائي (RAM) بسعة أصغر من سعة التخزين على القرص.
وفي المقابل، تدعم Kafka الرسائل الكبيرة بشكل معقول على الرغم من أنها غير مصممة خصيصًا لذلك. وتتعامل Kafka مع الرسائل بحجم 1 جيجابايت كحد أقصى في حالة ضغط الرسالة وتكوينها للتخزين المتدرج. وتستخدم التخزين عن بُعد لتخزين ملفات السجلات المكتملة بدلاً من تخزين كل الرسائل في وحدة التخزين المحلي.
تسليم الرسائل
يسحب المستهلكون في Kafka البيانات من قائمة انتظار الرسائل. ويتتبع كل مستهلك في Kafka الرسالة المقروءة باستخدام المُعرِّف المقابل، الذي يجري تحديثه لاسترداد الرسالة اللاحقة. يمكن للمستهلكين اكتشاف الرسائل المكررة، وتتبعها.
من ناحية أخرى، يدفع Redis تلقائيًا الرسالة إلى المشتركين المتصلين. وينتظر المشتركون في Redis بشكل غير نشط الرسائل الواردة الموجهة إليهم من الخادم. لا يمكن للمشتركين في Redis اكتشاف الرسائل المكررة نظرًا إلى إعداد التسليم لمرة واحدة على الأكثر.
الاحتفاظ بالرسائل
تحتفظ Kafka بالرسائل بعد أن يقرأها المستهلكون. لذلك في حالة أن تطبيق العميل قد فقد البيانات المستردة، يمكنه طلب هذه البيانات مرة أخرى من القسم المشترك فيه. وعند تعيين سياسة الاحتفاظ بالرسائل، يمكن للمستخدمين تحديد المدة التي تحتفظ Kafka خلالها بالبيانات.
على عكس ذلك، لا يخزن Redis الرسائل بعد تسليمها. وفي حالة عدم اتصال أي مشتركين بتدفق البيانات، يتجاهل Redis الرسائل. لا يمكن استرداد الرسائل المهملة حتى في حالة اتصال المشترك بـ Redis لاحقًا.
معالجة الأخطاء
يسمح كل من Kafka وRedis للتطبيقات بالحد من تسليم الرسائل غير الموثوق بها، ولكنهما يقومان بذلك بشكل مختلف.
تركز معالجة الأخطاء في Redis على التفاعل بين تطبيق العميل وخدمات Redis. وعند استخدام Redis، يمكن للمطورين معالجة حالات مثل مهلات العميل وتجاوز سعة التخزين المؤقت في الذاكرة والحد الأقصى للتقييدات المفروضة على العميل. نظرًا إلى هيكلة قاعدة بيانات زوج القيم الرئيسة، لا يمكن أن يعالج Redis أخطاء الرسائل بفعالية مثل Kafka.
يمكن للمطورين في Kafka تخزين الأحداث الخاطئة في قائمة انتظار (أو طابور) الرسائل الخامدة أو إعادة المحاولة أو إعادة توجيهها للسماح بتسليم الرسائل بشكل متسق لتطبيقات العميل. ويمكن للمطورين أيضًا استخدام واجهة برمجة التطبيقات Kafka Connect API لإعادة تشغيل مهام الموصِّل تلقائيًا في حالة بعض الأخطاء.
الاختلافات في الأداء: Kafka مقابل رسائل النشر والاشتراك (pub/sub) في Redis
بشكل عام، تتفوق Apache Kafka على Redis في رسائل النشر والاشتراك (pub/sub) نظرًا إلى أن Kafka مُصممة خصيصًا لتدفق البيانات. ويُستخدم Redis في العديد من حالات الاستخدام المختلفة التي يتعذر فيها استخدام Kafka.
التوازي
التوازي هو قدرة تلقي العديد من المستهلكين الرسالة نفسها في وقت واحد.
لا يدعم Redis التوازي.
من ناحية أخرى، تتيح Kafka توزيع الرسالة نفسها إلى عدة مستهلكين في وقت واحد. ويتناوب المستهلكون عادةً في مجموعات مستهلكي Kafka الأدوار لاسترداد الرسائل الجديدة من أحد الأقسام. في حالة وجود مستهلك واحد ضمن عدة مجموعات للمستهلكين، يمكنه استرداد كل الرسائل. وعند الاستفادة من هذا الإعداد والنسخ المتماثل للأقسام، يمكنك تعيين مستهلك واحد لكل مجموعة من المستهلكين في كل نسخة متماثلة للقسم. يتيح ذلك لكل المستهلكين استرداد تسلسل مماثل للرسائل.
معدل النقل
يقيس معدل النقل عدد الرسائل التي يمكن لكل نظام معالجتها في الثانية.
تتمتع Kafka عمومًا بمعدل نقل أعلى من إرسال رسائل النشر والاشتراك (pub/sub) في Redis. ويتعامل Kafka مع أحجام بيانات أكبر بكثير نظرًا إلى أنه لا يتعين عليها الانتظار حتى يتلقى كل مشترك الرسالة قبل الانتقال إلى آخر. بدلاً من ذلك، فإنها تخزن الرسائل الحالية في ذاكرة التخزين المؤقت ووحدة التخزين، ما يحسّن سرعة القراءة.
مع ذلك، قد ينخفض أداء Kafka إذا لم يسترد المستهلكون الرسالة بالسرعة الكافية حيث تتم في النهاية إزالة الرسائل غير المقروءة من ذاكرة التخزين المؤقت. وفي هذه الحالة، يجب على المستهلكين القراءة من القرص، ما يجعلها أبطأ.
في الوقت نفسه، يجب على Redis انتظار تلقي الإقرار لكل مستهلك، ما يقلل بشكل كبير من معدل النقل مع زيادة عدد العُقد المتصلة. ولحل هذه المشكلة، يمكن إرسال طلبات متعددة من خلال إجراء يُعرف باسم توزيع الطلبات في مسارات، ولكن هذا يقلل زمن استجابة الرسائل.
زمن الاستجابة
يكون استخدام Kafka وRedis مناسبًا عند معالجة البيانات بزمن استجابة منخفض. ويستخدم Redis وقتًا أقل في المراسلة يتراوح بالمللي ثانية، في حين يبلغ متوسط Kafka عشرات من المللي ثانية.
بما أن Redis يقرأ البيانات ويكتبها بشكل أساسي على ذاكرة الوصول العشوائي (RAM)، فإنه يقترب تدريجيًا من سرعة Kafka بشكل طبيعي. ومع ذلك، قد لا يحافظ Redis على عمليات البيانات بزمن انتقال منخفض للغاية عندما يتعامل مع الرسائل بأحجام أكبر. وفي المقابل، تحتاج Kafka إلى مزيد من الوقت لإجراء نسخ متماثل للأقسام على محركات أقراص مادية مختلفة من أجل استمرارية البيانات، ما يضيف أعباءً إلى وقت تسليم الرسائل.
يمكن تحسين زمن الاستجابة في Redis وKafka، ولكن يجب إجراء ذلك بعناية. فعلى سبيل المثال، يمكنك ضغط رسائل Kafka لتقليل زمن الاستجابة، لكن المنتجين والمستهلكين يحتاجون إلى مزيد من الوقت لفك ضغطها.
قد يتأثر زمن الاستجابة في Redis بعدة عوامل تشمل بيئة التشغيل أو عمليات الشبكات أو الأوامر البطيئة أو التفرع. ولتقليل تأخيرات التفرع، يوصي Redis بتشغيل نظام تسليم رسائل النشر والاشتراك (pub/sub) على مثيلات EC2 الحديثة استنادًا إلى آلة الأجهزة الافتراضية (HVM).
التعامل مع الأعطال
تكتب Kafka كل البيانات على قرص تخزين خاص بوسيط رائد وتجري لها نسخًا متماثلة عبر خوادم مختلفة. وعند فشل الخادم، يسترد العديد من المشتركين البيانات من أقسام النسخ الاحتياطي.
على عكس Kafka، لا ينسخ Redis البيانات احتياطيًا بشكل افتراضي ويجب على المستخدمين تمكين الميزة يدويًا. ويستخدم Redis مخزن البيانات في الذاكرة الذي يفقد كل البيانات عند إيقاف تشغيله. لتجنب ذلك، يشغّل المطورون استمرارية قاعدة بيانات Redis (RDB) لأخذ نُسخ احتياطية من بيانات ذاكرة الوصول العشوائي (RAM) بانتظام وتخزينها على القرص.
حالات استخدام Kafka مقابل رسائل النشر والاشتراك (pub/sub) في Redis
Apache Kafka هي الخيار الأفضل عند إنشاء التطبيقات التي تدعم تدفق مجموعات البيانات الكبيرة وتتطلب قابلية استرداد عالية. وهي مصممة أساسًا كمسار بيانات موزَّع واحد يمكنه معالجة ملايين الرسائل التي تمر عبره. وتجري Kafka نسخًا متماثلاً للأقسام عبر خوادم مختلفة لتجنب فقدان البيانات عند فشل العقدة. تستخدم المؤسسات Kafka لدعم الاتصال المباشر بين التطبيقات وأجهزة إنترنت الأشياء (IoT) المحمولة والخدمات المصغرة. وتُعد أيضًا الخيار الأفضل لتجميع السجلات ومعالجة التدفق وإجراء مهام تكامل البيانات الأخرى القائمة على السحابة.
ومن ناحية أخرى، يوفر Redis توزيعًا للأحداث بزمن استجابة منخفض للغاية للتطبيقات التي تتطلب نقلاً فوريًا للبيانات ولكنها تتحمل فقدان أحجام صغيرة من البيانات. ويُستخدم Redis عادةً كذاكرة تخزين مؤقت للجلسة بغرض تخزين البيانات التي يتم الوصول إليها باستمرار أو تسليم الرسائل العاجلة. ويكون أيضًا مناسبًا لتخزين بيانات الألعاب أو التجارة الإلكترونية أو وسائل التواصل الاجتماعي للاستمتاع بتجربة مستخدم أسهل.
ملخص الاختلافات: Kafka مقابل رسائل النشر والاشتراك (pub/sub) في Redis
| Apache Kafka |
Redis |
|
| حجم الرسائل |
تدعم الرسائل بحجم 1 جيجابايت كحد أقصى مع الضغط والتخزين المتدرج. |
يدعم الرسائل بحجم أصغر. |
| تسليم الرسائل |
يتلقى المشتركون الرسائل من قائمة الانتظار. |
يرسل خادم Redis الرسائل إلى المشتركين المتصلين. |
| الاحتفاظ بالرسائل |
تحتفظ بالرسائل بعد استردادها. |
لا يحتفظ بالرسائل. |
| معالجة الأخطاء |
تعالج الأخطاء بفعالية على مستوى الرسائل. إنشاء قائمة انتظار (أو طابور) الرسائل الخامدة، وإعادة محاولة الأحداث، وإعادة التوجيه. |
يجب معالجة استثناءات Redis على مستوى التطبيقات من خلال المهلات والتقييدات المفروضة على العملاء وسعة التخزين المؤقت في الذاكرة. |
| التوازي |
تدعم Kafka التوازي. يمكن للعديد من المستهلكين استرداد الرسالة نفسها في وقت واحد. |
لا يدعم التوازي. |
| معدل الانتقال |
تتمتع بمعدل نقل أعلى بسبب القراءة/الكتابة غير المتزامنة. |
تعمل بمعدل نقل أقل نظرًا إلى أن خادم Redis يحتاج إلى انتظار الرد قبل إرسال رسالة إلى مشترك آخر. |
| وقت الاستجابة |
تعمل بزمن استجابة منخفض. وهي أبطأ قليلاً من Redis بسبب النسخ المتماثل للبيانات بشكل افتراضي. |
يعمل بزمن استجابة منخفض للغاية عند توزيع رسائل بحجم أصغر. |
| التعامل مع الأعطال |
تنسخ الأقسام احتياطيًا بشكل تلقائي إلى وسطاء مختلفين. |
لا ينسخ الأقسام احتياطيًا بشكل افتراضي. يمكن للمستخدمين تمكين استمرارية عمل Redis يدويًا. يمكن التعرض لخطر فقدان أحجام صغيرة من البيانات. |
كيف تساعدك AWS في دعم متطلبات Kafka وRedis لديك؟
توفر Amazon Web Services (AWS) بنية تحتية قابلة للتحجيم ومُدارة لدعم متطلبات رسائل النشر والاشتراك (pub/sub).
استخدم Amazon Managed Streaming for Apache Kafka (Amazon MSK) لاستيعاب أحجام كبيرة من البيانات ومعالجتها مباشرةً بكل سهولة. ويمكنك إنشاء ناقل بيانات يتم الوصول إليه بشكل خاص لتوفير عُقد تدفق عالية التوافر على نطاق واسع. ويمكنك أيضًا الاتصال بسلاسة مع خدمات AWS الأخرى، مثل AWS IoT Core، والسحابة الخاصة الافتراضية بـ Amazon (Amazon VPC)، وخدمة Amazon المُدارة لـ Apache Flink.
استخدم Amazon MemoryDB لتوفير مخزن في الذاكرة عالي التوافر في أعباء عمل Redis لديك. يمكنك تشغيل موجزات بيانات التدفق عالية التزامن لاستيعاب نشاط المستخدم. ويمكنك دعم ملايين الطلبات يوميًا لتطبيقات الوسائط والترفيه.
بدلاً من استخدام Redis أو Kafka، يمكنك أيضًا استخدام خدمة الإشعارات البسيطة في Amazon (Amazon SNS) لإنشاء نظام رسائل النشر والاشتراك (pub/sub). ويمكنك إرسال رسائل مباشرةً من تطبيقاتك إلى العملاء أو التطبيقات الأخرى بطريقة قابلة للتحجيم وفعالة من حيث التكلفة. توفر خدمة الإشعارات البسيطة في Amazon (Amazon SNS) عدة ميزات مثل:
- إرسال رسائل بمعدل نقل عال وقائمة على الدفع مع إمكانية الإرسال من عدة أطراف إلى عدة أطراف فيما بين الأنظمة الموزعة والخدمات المصغرة والتطبيقات بلا خوادم المدفوعة بالأحداث.
- تشفير الرسائل وخصوصية حركة المرور.
- إمكانات تشعُّب الرسائل عبر فئات AWS، ويتضمن ذلك التحليلات والحوسبة والحاويات وقواعد البيانات وإنترنت الأشياء (IoT) وتعلّم الآلة (ML) والأمان والتخزين.
بادر اليوم باستخدام رسائل النشر والاشتراك (pub/sub) وRedis وKafka على AWS من خلال إنشاء حساب.
