كافكا مقابل ناتس: مقارنة لمعالجة الرسائل

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

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

1. الهندسة المعمارية والتعقيد

ناتس

بنية تحتية ناتس تتألف من جزئين رئيسيين:

ناتس الأساسي

ناتس الأساسي هو إطار الرسائل الأساسي. يدعم هذا النمط النشر-الاشتراك (يسمح ببث الرسائل لعدة مشتركين)، والطلب-الرد (يمكّن التواصل المتزامن)، ومجموعات الطوابير (تيسير التوازن بين عدة مشتركين ضمن مجموعة).

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

JetStream

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

  1. احتفاظ بالتيار: مدى الوقت الذي تُحتفظ فيه الرسائل. يمكن أن يكون بناءً على الحجم، الوقت، أو حدود المُستهلك.
  2. دوام المُستهلك: تمكين المُستهلكين من استئناف العملية من حيث توقفوا.
  3. إقرار الرسالة: يضمن هذا موثوقية التسليم.

يضيف JetStream طبقة من التعقيد إلى Core NATS. ومع ذلك، يأتي هذا بميزة مهمة تدعم حالات الاستلام المضمون، الاستمرارية، وإمكانية الإعادة.

Kafka

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

2. التوافر العالي والأداء

ناتس

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

يدعم JetStream أيضًا عكس البيانات عبر مجموعات أو عقد متعددة. في JetStream، يتم انتخاب القادة لكل تدفق. يمكن تكوين النسخ لكل تدفق. كل هذه الأمور تضمن المتانة والتوافر في ناتس.

كافكا

التوفرية العالية في كافكا تعتمد على التكرار. يمكن لكل موضوع أن يحتوي على تقسيم واحد أو أكثر. يتم تكرير كل تقسيم عبر وسطاء كافكا. يضمن ذلك تكرار البيانات والتوافر. يتبع كافكا آلية تكرير القائد والمتبوع. يهتم القائد بالقراءة والكتابة. ويعمل المتبوع على تكرير البيانات. 

كافكا يحتفظ بشيء يسمى ISR (نسخ متزامنة) لكل تقسيم. إذا فشل القائد، يصبح أحد ISRs القائد. لإدارة بيانات العنقريب وانتخاب القائد، يعتمد كافكا على زووكيبر (KRaft في الإصدارات الأحدث).

Performance and Scalability
الميزة
ناتس
كافكا
الأداء
عالٍ أو منخفض الكفاءة. محسن للرسائل الصغيرة
محسن للأداء العالي والرسائل الكبيرة
التوسيع
قابل للتوسيع أفقيًا بالتجميع
قابل للتوسيع أفقيًا بالتقسيم
الكفاءة
دون مللي ثانية
مللي ثانية
Recovery and FAILOver
ميزة
NATS
كافكا
وقت الانتقال
دون ثانية (إعادة اتصال العميل بسرعة)
أبطأ (يعتمد على عملية انتخاب القائد)
انتعاش سلس
يقوم العملاء بالاتصال تلقائيًا دون انقطاع
يوجد بعض الوقت الضائع خلال انتخاب القائد
مخاطر فقدان البيانات
الحد الأدنى مع التكرار (JetStream)
الحد الأدنى إذا تم تكوين التكرار وISR

3. أنماط الرسائل

NATS

تستخدم NATS الرسائل القائمة على الموضوعات. يتيح ذلك للخدمات والتيارات استخدام أنماط Pub-Sub، وRequest-Reply، وQueue Subscriber. يمكن بناء المواضيع في NATS بتسلسل وباستخدام البطاقات النمطية. يمكن لتيار واحد في NATS تخزين مواضيع متعددة، ويمكن لتطبيقات العميل استخدام تصفية على الجانب الخادم لاستقبال فقط المواضيع المهتم بها. الاتصال في NATS ثنائي الاتجاه ويسمح للعملاء بالنشر والاشتراك في نفس الوقت. تدعم NATS أيضًا تكوين الطوابير بشكل مشابه لـ RabbitMQ.

Kafka

تدعم تيارات في Kafka النشر والاشتراك بناءً على الموضوعات. يمكن تحقيق توازن الحمل من خلال مجموعات المستهلكين وتقسيم المواضيع.

4. ضمانات التسليم

NATS

تدعم NATS مجموعة متنوعة من ضمانات التسليم. يمكن لـ NATS بمفرده دعم ضمان التسليم مرة واحدة على الأكثر. يمكن لخوادم NATS التي يتم تمكين JetStream عليها دعم نوعين إضافيين من الضمانات. هما “مرة واحدة على الأقل” و “مرة واحدة تمامًا” ضمانات. يمكن لـ NATS إرسال ‘تأكيدات’ للرسائل الفردية. يرجى الرجوع إلى الوثائق الرسمية لـ NATS لمعرفة الأنواع المختلفة من ‘التأكيدات’ التي يدعمها. بناءً على نوع ‘التأكيدات’، يمكن لـ NATS إعادة تسليم الرسائل.

Kafka

تدعم Kafka ضمانات “مرة على الأقل” و “مرة واحدة تمامًا”. يتم ضمان ترتيب الرسائل على مستوى التقسيم. لا يمكن تحقيق ترتيب عالمي في Kafka.

5. الاحتفاظ بالرسائل والثبات

NATS

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

Kafka

يدعم KAFKA فقط الاستمرارية القائمة على الملفات. يمكن إعادة تشغيل الرسائل من آخر offset، أول offset، أو offset معين. يتم دعم تنظيف السجلات في KAFKA.

6. اللغات والمنصات

NATS

ثمانية وأربعون نوعًا معروفًا من العملاء. يمكن لأي عمارة تدعم GOLANG دعم خوادم NATS.

Kafka

ثمانية عشر نوعًا معروفًا من العملاء. يمكن تشغيل خوادم Kafka على المنصات التي تدعم JVM.

حالات الاستخدام

حالة الاستخدام ١

المتطلبات

لدينا منصة بيانات بأنبوب تدفقي. تستخدم المنصة محرك Apache Flink للتدفق الزمني الحقيقي و Apache Beam لكتابة أنبوب التحليلات. فيما يلي المتطلبات الرئيسية:

  1. معالجة رسائل عالية الإنتاجية ومنخفضة الوقت
  2. دعم للتحقق ومعالجة ضغط العودة
  3. التعامل مع رسائل بحجم ميغابايت
  4. استدامة واستمرارية الرسائل

المقارنة

ميزة Kafkas:

  • عالية الإنتاجية
  • احتفاظ البيانات بسياسات احتفاظ قابلة للتكوين وتكرار البيانات للتحمل من الأعطال
  • دعم لضمان تسليم رسالة واحدة على الأقل
  • قراءة الرسائل من آخر offset/أول offset/offset معين
  • تأكيدات ‘acks’ على الخادم لتوصيل موثوق
  • التعامل مع تدفقات البيانات الضخمة وحجم رسالة كبير
  • دعم لموضوع التنظيف

عيوب Kafka:

  • استخدام موارد عالي. كانت عندنا مجموعة الخوادم في الموقع وكانت الموارد محدودة كافكا فقط في الوقت الحقيقي

مزايا NATS:

  • أداء عالي مع استخدام موارد أدنى. كانت مجموعتنا في الموقع وكانت هناك قيود على الموارد
  • دعم على الأقل مرة واحدة. كنا نبحث عن ضمان على الأقل مرة واحدة
  • معالجة الرسائل مع انخفاض التأخير

عيوب NATS:

  • لا توجد موصلات لـ Flink/Beam لذلك كان التكامل صعبًا
  • تقليل الأداء مع حجم الرسائل

القرار النهائي

بعد تحليل دقيق، تم اختيار كافكا. كان علينا أن نتنازل بين استخدام الموارد والفوائد الأخرى التي كانت تقدمها كافكا، خاصة الدمج الجيد المتاح مع Apache Beam و Flink. ميزة أخرى لكافكا كانت التعامل مع حجم الرسائل الكبيرة ومعالجة الرسائل عالية الكفاءة

حالة الاستخدام 2

المتطلبات

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

القرار

لماذا تم اختيار NATS:

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

لماذا لم يتم اختيار Kafka:

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

الملخص

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

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

المجالات الرئيسية التي يجب مراعاتها قبل الاختيار بين Kafka و NATS:

  1. الهندسة المعمارية والتعقيد
  2. التوفر العالي والأداء
  3. ضمانات تسليم الرسائل

كافكا هو مثالي للأنظمة الموزعة التي تتطلب تدفق الأحداث، وتخزين متين وقدرات معالجة متقدمة. ومع ذلك، يأتي كافكا مع استخدام موارد عالي وأثر ذاكرة. وتعقيد الإدارة هو عالي جدًا مقارنة بـ NATS.

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

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

Source:
https://dzone.com/articles/kafka-vs-nats-message-processing