في المادتين الأخيرتين ، تحدثنا عن IIoT - الإنترنت الصناعي للأشياء - أنشأنا بنية لتلقي البيانات من أجهزة الاستشعار ، ملحومًا بأجهزة الاستشعار نفسها. حجر الزاوية في معماريات IIoT وأي بنية تعمل مع BigData هي معالجة دفق البيانات. لأنه يقوم على مفهوم الرسائل والصفوف. أصبح معيار العمل مع الرسائل الآن Apache Kafka. ومع ذلك ، من أجل فهم مزاياها (وفهم عيوبها) ، سيكون من الجيد فهم أساسيات تشغيل أنظمة قائمة الانتظار ككل ، وآليات تشغيلها ، وأنماط الاستخدام ، والوظائف الأساسية.
لقد وجدنا سلسلة ممتازة من المقالات التي تقارن بين وظيفة Apache Kafka وعملاق آخر (تم تجاهله بلا تحفظ) بين أنظمة الطابور - RabbitMQ. لقد ترجمنا سلسلة المقالات هذه وزودناها بالتعليقات واستكملناها. على الرغم من أن المسلسل كتب في ديسمبر 2017 ، إلا أن عالم أنظمة الرسائل (وخاصة أباتشي كافكا) يتغير بسرعة كبيرة لدرجة أنه بحلول صيف 2018 ، تغيرت بعض الأشياء.
المصدر
RabbitMQ مقابل كافكا
المراسلة هي الجزء المركزي من العديد من الهياكل المعمارية ، والركيزتان في هذا المجال هما RabbitMQ و Apache Kafka. حتى الآن ، أصبح Apache Kafka معيارًا صناعيًا تقريبًا في معالجة البيانات والتحليلات ، لذلك في هذه السلسلة سنلقي نظرة فاحصة على RabbitMQ و Kafka في سياق استخدامها في البنى التحتية في الوقت الفعلي.
أباتشي كافكا في ازدياد الآن ، ولكن يبدو أنهم بدأوا في نسيان RabbitMQ. ركز كل الضجيج على كافكا ، وهذا يحدث لأسباب واضحة ، لكن RabbitMQ لا يزال خيارًا رائعًا للمراسلة. أحد الأسباب التي حولت كافكا انتباهها إليها هو هوسها العام بقابلية التوسع ، ومن الواضح أن كافكا أكثر قابلية للتطوير من RabbitMQ ، لكن معظمنا لا يهتم بالمقاييس التي تواجه RabbitMQ مشاكل فيها. معظمنا ليس Google أو Facebook. يتعامل معظمنا مع الأحجام اليومية للرسائل من مئات الآلاف إلى مئات الملايين ، وليس مع الأحجام من المليارات إلى التريليونات (ولكن بالمناسبة ، هناك حالات قام فيها الأشخاص بتوسيع RabbitMQ إلى مليارات الرسائل اليومية).
وبالتالي ، في سلسلة مقالاتنا ، لن نتحدث عن الحالات التي تتطلب قابلية التوسع القصوى (وهذا من اختصاص كافكا) ، بل نركز على المزايا الفريدة التي يقدمها كل نظام قيد النظر. ومن المثير للاهتمام أن لكل نظام مزاياه الخاصة ، ولكن في نفس الوقت تختلف تمامًا عن بعضها البعض. بالطبع ، لقد كتبت الكثير عن RabbitMQ ، لكني أؤكد لك أنني لا أعطي أي تفضيل خاص لها. أنا أحب الأشياء المصنوعة جيدًا ، و RabbitMQ و Kafka كلاهما ناضجان جدًا وموثوقان ، ونعم ، أنظمة رسائل قابلة للتطوير.
سنبدأ في المستوى الأعلى ، ثم نبدأ بدراسة الجوانب المختلفة لهاتين التقنيتين. هذه السلسلة من المقالات مخصصة للمهنيين المشاركين في تنظيم أنظمة المراسلة أو المهندسين المعماريين / المهندسين الذين يرغبون في فهم تفاصيل المستوى الأدنى وتطبيقاتهم. لن نكتب التعليمات البرمجية ، ولكن بدلاً من ذلك نركز على الوظائف التي يوفرها كلا النظامين ، وقوالب عملية المراسلة التي يقدمها كل منهما ، والقرارات التي يجب على مطوري القرار والمهندسين المعماريين اتخاذها.
في هذا الجزء ، سنلقي نظرة على ماهية RabbitMQ و Apache Kafka ، ونهجهما في المراسلة. كلا النظامين يقتربان من بنية المراسلة من زوايا مختلفة ، لكل منهما نقاط القوة والضعف. في هذا الفصل ، لن نتوصل إلى أي استنتاجات مهمة ؛ بدلاً من ذلك ، نقترح أن نأخذ هذه المقالة كدليل تقني للمبتدئين ، حتى نتمكن من التعمق أكثر في المقالات التالية من السلسلة.
Rabbitmq
RabbitMQ هو نظام إدارة طابور الرسائل الموزعة. يتم توزيعها ، لأنها تعمل عادةً كمجموعة من العقد ، حيث يتم توزيع قوائم الانتظار بين العقد ، وبشكل اختياري ، يتم نسخها من أجل أن تكون مقاومة للخطأ وتوفر عالي. بانتظام ، تنفذ AMQP 0.9.1 وتقدم بروتوكولات أخرى ، مثل STOMP و MQTT و HTTP من خلال وحدات إضافية.
يستخدم RabbitMQ كلا من أساليب المراسلة الكلاسيكية والمبتكرة. كلاسيكية بمعنى أنها تركز على قائمة انتظار الرسائل ، ومبتكرة - في إمكانية التوجيه المرن. ميزة التوجيه هذه هي ميزتها الفريدة. يعد إنشاء نظام رسائل موزعة سريع وقابل للتطوير وموثوق به إنجازًا في حد ذاته ، ولكن وظيفة توجيه الرسائل تجعله رائعًا حقًا بين العديد من تقنيات المراسلة.
الصرف والصفوف
مراجعة مبسطة للغاية:
- يرسل الناشرون (الناشرون) رسائل إلى التبادل
- Exchange'i إرسال الرسائل في قوائم الانتظار وإلى التبادلات الأخرى
- يرسل RabbitMQ تأكيدات للناشرين عند استلام رسالة
- يحافظ المستلمون (المستهلكون) على اتصالات TCP المستمرة بـ RabbitMQ ويعلنون عن قائمة (قوائم) الانتظار التي يتلقونها
- RabbitMQ يدفع الرسائل إلى المستلمين
- يرسل المستلمون تأكيدات النجاح / الخطأ
- عند الاستلام الناجح ، تتم إزالة الرسائل من قوائم الانتظار.
تحتوي هذه القائمة على عدد كبير من القرارات التي يجب على المطورين والمسؤولين اتخاذها للحصول على ضمانات التسليم التي يحتاجونها ، وخصائص الأداء ، وما إلى ذلك ، والتي سنناقش كل منها في وقت لاحق.
دعنا نرى مثالاً للعمل مع ناشر واحد ، وتبادل ، وقائمة انتظار ، وجهاز استقبال:
التين. 1. ناشر واحد ومستلم واحد
ماذا تفعل إذا كان لديك عدة ناشرين
رسائل؟ ماذا لو كان لدينا عدة مستلمين ، يرغب كل منهم في تلقي جميع الرسائل؟
التين. 2. العديد من الناشرين والعديد من المستلمين المستقلين
كما ترى ، يرسل الناشرون رسائلهم إلى نفس المبادل ، الذي يرسل كل رسالة في ثلاث قوائم انتظار ، لكل منها مستلم واحد. في حالة RabbitMQ ، تسمح قوائم الانتظار للمستلمين المختلفين بتلقي جميع الرسائل. قارن مع الرسم البياني أدناه:
التين. 3. العديد من الناشرين ، طابور واحد مع العديد من المتلقين المتنافسين
في الشكل 3 ، نرى ثلاثة مستلمين يستخدمون نفس قائمة الانتظار. هؤلاء هم المتلقون المتنافسون ، أي أنهم يتنافسون على تلقي الرسائل من قائمة الانتظار. وبالتالي ، من المتوقع أن يتلقى كل مستلم في المتوسط ثلث الرسائل في قائمة الانتظار. نحن نستخدم المستلمين المنافسين لتوسيع نطاق نظام معالجة الرسائل الخاص بنا ، وباستخدام RabbitMQ ، من السهل جدًا القيام بذلك: إضافة أو إزالة المستلمين عند الطلب. بغض النظر عن عدد المتلقين المتنافسين لديك ، فإن RabbitMQ سوف يسلم الرسائل إلى مستلم واحد فقط.
يمكننا الجمع بين الأرز. 2 و 3 لاستقبال مجموعات متعددة من المتلقين المتنافسين ، حيث تتلقى كل مجموعة كل رسالة.
التين. 4. العديد من الناشرين ، عدة طوابير مع المتلقين المتنافسين
تسمى الأسهم بين المبادلات وقوائم الانتظار بالربط ، وسوف نتحدث عنها بمزيد من التفصيل.
الضمانات
تقدم RabbitMQ ضمانات "التسليم لمرة واحدة" و "تسليم واحد على الأقل" ، ولكن ليس "تسليم واحد بالضبط".
ملاحظة المترجم: قبل الإصدار 0.11 من كافكا ، لم يكن تسليم رسالة التسليم مرة واحدة بالضبط ؛ حاليًا ، توجد وظائف مماثلة في كافكا.
يتم تسليم الرسائل بالترتيب الذي وصلت إليه في قائمة الانتظار (بعد كل شيء ، هذا هو تعريف قائمة الانتظار). هذا لا يضمن أن إتمام معالجة الرسائل يطابق نفس الترتيب عندما يكون لديك مستلمون منافسون. هذا ليس خطأ RabbitMQ ، ولكن الواقع الأساسي للمعالجة المتوازية لمجموعة مرتبة من الرسائل. يمكن حل هذه المشكلة باستخدام Exchange Hashing Exchange ، كما سترى في الفصل التالي حول القوالب والطوبولوجيا.
دفع المستلمين وجلبهم مسبقًا
يقوم RabbitMQ بدفع الرسائل إلى المستلمين (هناك أيضًا واجهة برمجة تطبيقات لسحب الرسائل من RabbitMQ ، ولكن تم إيقاف هذه الوظيفة الآن). يمكن أن يؤدي ذلك إلى إرباك المستلمين إذا وصلت الرسائل في قائمة الانتظار بشكل أسرع مما يمكن للمستلمين معالجتها. لتجنب ذلك ، يمكن لكل مستلم تعيين حد الجلب المسبق (المعروف أيضًا باسم حد جودة الخدمة). في الواقع ، حد جودة الخدمة هو حد لعدد الرسائل التي لم يتم التعرف عليها من قبل المستلم المتراكم. يعمل مثل الصمامات عندما يبدأ المتلقي بالتأخر.
لماذا تقرر دفع الرسائل في قائمة الانتظار (دفع) وعدم تفريغها (سحب)؟ أولاً ، لأن هناك وقت تأخير أقل. ثانيًا ، من الناحية المثالية ، عندما يكون لدينا متلقون متنافسون من قائمة الانتظار نفسها ، نريد توزيع الحمل بالتساوي. إذا طلب كل مستلم / تنزيل الرسائل ، فاعتمادًا على مقدار ما يطلبه ، يمكن أن يصبح توزيع العمل غير متكافئ إلى حد ما. وكلما كان توزيع الرسائل أكثر تفاوتًا ، زاد التأخير وفقدان ترتيب الرسائل أثناء المعالجة. هذه العوامل توجه بنية RabbitMQ نحو آلية دفع في رسالة واحدة في كل مرة. هذا هو واحد من قيود التحجيم RabbitMQ. يتم تخفيف القيد بحقيقة أنه يمكن تجميع التأكيدات.
التوجيه
إن Exchange هي في الأساس موجهات رسائل لقوائم الانتظار و / أو التبادلات الأخرى. لكي يتم نقل رسالة من التبادل إلى قائمة انتظار أو إلى تبادل آخر ، يلزم الربط. تتطلب التبادلات المختلفة روابط مختلفة. هناك أربعة أنواع من التبادلات والروابط المرتبطة بها:
- فانوت يوجه إلى جميع الطوابير والمبادلات ملزمة بتبديل النموذج القياسي القياسي للنشر.
- مباشر (مباشر). يقوم بتوجيه الرسائل بناءً على مفتاح التوجيه الذي تحمله الرسالة ، المعين من قبل الناشر. مفتاح التوجيه هو سلسلة قصيرة. ترسل المبادلات المباشرة رسائل إلى / قوائم انتظار التبادل التي تحتوي على مفتاح الاقتران الذي يتطابق تمامًا مع مفتاح التوجيه.
- موضوع (مواضيعي). يقوم بتوجيه الرسائل بناءً على مفتاح التوجيه ، ولكنه يسمح باستخدام المطابقة غير المكتملة (حرف البدل).
- رأس (رأس). يسمح لك RabbitMQ بإضافة رؤوس المستلمين إلى الرسائل. ترسل عمليات تبادل الرؤوس الرسائل وفقًا لقيم الرؤوس هذه. يتضمن كل ربط تطابق تام لقيم الرأس. يمكنك إضافة قيم متعددة للربط مع أي قيم أو كل القيم المطلوبة للمطابقة.
- تجزئة متناسقة. هذا عبارة عن مبادل يقوم بتجزئة إما مفتاح توجيه أو رأس رسالة ، ويرسل فقط في قائمة انتظار واحدة. هذا مفيد عندما تحتاج إلى الامتثال لضمانات أوامر المعالجة ولا تزال قادرًا على توسيع نطاق المستلمين.
التين. 5. مثال لتبادل الموضوع
سننظر أيضًا في التوجيه بمزيد من التفاصيل ، ولكن مثال تبادل الموضوعات موضح أعلاه. في هذا المثال ، ينشر الناشرون سجلات الأخطاء باستخدام تنسيق مفتاح التوجيه LEVEL (مستوى الخطأ) .AppName.
ستتلقى قائمة الانتظار 1 جميع الرسائل لأنها تستخدم رقم حرف بدل مع عدة كلمات.
ستتلقى قائمة الانتظار 2 أي مستوى من تسجيل تطبيق ECommerce.WebUI. يستخدم حرف البدل * ، وبالتالي التقاط مستوى تسمية موضوع واحد (ERROR.Ecommerce.WebUI ، NOTICE.ECommerce.WebUI ، وما إلى ذلك).
ستعرض قائمة الانتظار 3 جميع رسائل الخطأ من أي تطبيق. يستخدم حرف البدل # لتغطية جميع التطبيقات (ERROR.ECommerce.WebUi و ERROR.SomeApp.SomeSublevel ، وما إلى ذلك).
بفضل أربع طرق لتوجيه الرسائل ومع القدرة على تبادل الرسائل لإرسال الرسائل إلى التبادلات الأخرى ، يسمح لك RabbitMQ باستخدام مجموعة قوية ومرنة من قوالب تبادل الرسائل. علاوة على ذلك ، سوف نتحدث عن التبادلات مع تبادل الحروف الميتة ، حول التبادلات وقوائم الانتظار بدون بيانات (التبادلات المؤقتة وقوائم الانتظار) ، وسوف تتوسع RabbitMQ إلى إمكاناتها الكاملة.
صرف غير مسلّم
ملاحظة المترجم: عندما لا يمكن استلام الرسائل من قائمة الانتظار لسبب أو لآخر (طاقة المستهلك غير كافية ، مشاكل الشبكة ، إلخ) ، يمكن تأجيلها ومعالجتها بشكل منفصل.
يمكننا تكوين قوائم الانتظار بحيث يتم إرسال الرسائل للتبادل في الظروف التالية:
- تتجاوز قائمة الانتظار العدد المحدد من الرسائل.
- تتجاوز قائمة الانتظار العدد المحدد من وحدات البايت.
- انتهت صلاحية وقت إرسال الرسالة (TTL). يمكن للناشر تعيين مدة الرسالة ، ويمكن أن يكون لقائمة الانتظار نفسها TTL محددة للرسالة. في هذه الحالة ، سيتم استخدام TTL أقصر من الاثنين.
نقوم بإنشاء قائمة انتظار مرتبطة بالتبادل مع الرسائل التي لم يتم تسليمها ، ويتم تخزين هذه الرسائل هناك حتى يتم اتخاذ بعض الإجراءات.
مثل العديد من وظائف RabbitMQ ، تتيح عمليات التبادل مع الرسائل غير القابلة للتسليم إمكانية استخدام النماذج التي لم يتم توفيرها في الأصل. يمكننا استخدام رسائل TTL والتبادل مع الرسائل التي لم يتم تسليمها لتنفيذ قوائم الانتظار المؤجلة وإعادة محاولة قوائم الانتظار.
مبادلات وقوائم انتظار بدون بيانات
يمكن إنشاء التبادل وقوائم الانتظار بشكل ديناميكي ، ويمكنك تعيين معايير لإزالتها تلقائيًا. هذا يسمح باستخدام أنماط مثل RPCs المستندة إلى الرسائل.
وحدات إضافية
المكون الإضافي الأول الذي ربما تريد تثبيته هو المكون الإضافي للإدارة ، والذي يوفر خادم HTTP بواجهة ويب وواجهة برمجة تطبيقات REST. إنه سهل التثبيت للغاية وله واجهة سهلة الاستخدام. كما أن نشر البرامج النصية من خلال REST API بسيط للغاية.
بالإضافة إلى:
- التبادل المتناسق والتبادل المشترك والمزيد
- بروتوكولات مثل STOMP و MQTT
- خطاف الويب
- أنواع إضافية من المبادلات
- تكامل SMTP
هناك العديد من الأشياء الأخرى التي يمكن قولها عن RabbitMQ ، ولكن هذا مثال جيد يسمح لك بوصف ما يمكن أن يفعله RabbitMQ. الآن ننظر إلى Kafka ، التي تستخدم نهجًا مختلفًا تمامًا في المراسلة ، وفي نفس الوقت ، لديها أيضًا مجموعة خاصة بها من الميزات المميزة والمثيرة للاهتمام.
أباتشي كافكا
Kafka هو سجل التزام المنسوخة الموزعة. لا يوجد لدى كافكا مفهوم قوائم الانتظار ، والتي قد تبدو غريبة في البداية ، بالنظر إلى أنها تستخدم كنظام مراسلة. لطالما كانت قوائم الانتظار مرادفة لأنظمة المراسلة. أولاً ، دعنا نلقي نظرة على ما يعنيه "سجل التزام التغيير الموزع والمتكرر":
- يتم التوزيع لأن كافكا يتم نشره كمجموعة من العقد ، من أجل تحمل الخطأ والتدرج
- منسوخ ، حيث يتم نسخ الرسائل عادة على عدة عقد (خوادم).
- سجل تنفيذ لأنه يتم تخزين الرسائل في سجلات مجزأة ، إلحاق فقط تسمى الموضوعات. إن مفهوم قطع الأشجار هذا هو الميزة الفريدة الأساسية لكافكا.
إن فهم المجلة (والموضوع) والأقسام هو مفتاح فهم كافكا. فكيف يختلف السجل المقسم عن مجموعة قوائم الانتظار؟ دعونا نتخيل كيف يبدو.
التين. 6 منتج واحد ، جزء واحد ، مستلم واحد
بدلاً من وضع الرسائل في قائمة انتظار FIFO ومراقبة حالة هذه الرسالة في قائمة الانتظار ، كما يفعل RabbitMQ ، يضيفها كافكا ببساطة إلى السجل ، وهذا كل شيء.
تبقى الرسالة ، بغض النظر عما إذا تم تلقيها مرة واحدة أو أكثر. يتم حذفها وفقًا لسياسة الاحتفاظ ، وتسمى أيضًا الفترة الزمنية للنافذة. كيف يتم أخذ المعلومات من الموضوع؟
يتتبع كل مستلم مكانه في السجل: يوجد مؤشر لآخر رسالة تم تلقيها ويسمى هذا المؤشر بعنوان الإزاحة. يدعم المستلمون هذا العنوان من خلال مكتبات العملاء ، واعتمادًا على إصدار كافكا ، يتم تخزين العنوان إما في ZooKeeper أو في كافكا نفسها.
السمة المميزة لنموذج دفتر اليومية هي أنه يزيل على الفور العديد من الصعوبات المتعلقة بحالة تسليم الرسالة ، والأهم من ذلك بالنسبة إلى المستلمين ، يسمح لهم بإعادة الترجيع والعودة وتلقي الرسائل على العنوان النسبي السابق. على سبيل المثال ، تخيل أنك تنشر خدمة تصدر الفواتير التي تأخذ في الاعتبار الطلبات المقدمة من العملاء. يوجد خطأ في الخدمة ولا تحسب جميع الفواتير بشكل صحيح في غضون 24 ساعة. مع RabbitMQ في أفضل الأحوال ، ستحتاج إلى إعادة نشر هذه الطلبات بطريقة ما فقط على خدمة الحساب. ولكن مع Kafka ، يمكنك ببساطة نقل العنوان النسبي لهذا المستلم قبل 24 ساعة.
لذلك ، دعنا نرى كيف يبدو عندما يكون هناك موضوع يوجد فيه قسم واحد واثنين من المستلمين ، يجب أن يتلقى كل منهم كل رسالة.
التين. 7. منتج واحد ، قسم واحد ، اثنان من المستلمين المستقلين
كما يتبين من الرسم التخطيطي ، يتلقى مستلمان مستقلان نفس القسم ، لكنهما يقرأن بعناوين إزاحة مختلفة. ربما تستغرق خدمة الفوترة وقتًا أطول في معالجة الرسائل مقارنة بخدمة دفع الإشعارات. أو ربما كانت خدمة الفوترة غير متوفرة لبعض الوقت وحاولت اللحاق في وقت لاحق. أو ربما كان هناك خطأ ، وكان لا بد من تأجيل عنوان الإزاحة لعدة ساعات.
افترض الآن أن خدمة الفوترة تحتاج إلى تقسيمها إلى ثلاثة أجزاء ، لأنها لا تستطيع مواكبة سرعة الرسالة. مع RabbitMQ ، نقوم ببساطة بنشر تطبيقين آخرين لخدمة الفوترة يتم الحصول عليهما من قائمة انتظار الفواتير. لكن كافكا لا تدعم المتلقين المتنافسين في نفس القسم ؛ كتلة التزامن كافكا هي القسم نفسه. لذلك ، إذا كنا بحاجة إلى ثلاثة متلقين للفواتير ، فإننا بحاجة إلى ثلاثة أقسام على الأقل. حتى الآن لدينا:
التين. 8. ثلاثة أقسام ومجموعتان من ثلاثة متلقين
وبالتالي ، من المفهوم أنك بحاجة إلى عدد الأقسام على الأقل مثل المستلم الأفقي الأكثر تحجيمًا. لنتحدث قليلاً عن الأقسام.
أقسام ومجموعات المستلمين
كل قسم هو ملف منفصل يتم فيه ضمان تسلسل الرسائل. من المهم تذكر ذلك: يتم ضمان ترتيب الرسائل في قسم واحد فقط. في المستقبل ، قد يؤدي هذا إلى بعض التناقض بين متطلبات قائمة انتظار الرسائل ومتطلبات الأداء ، حيث يتم تحجيم الأداء في كافكا حسب الأقسام. لا يمكن للقسم دعم المستلمين المنافسين ، لذلك يمكن لتطبيق الفوترة لدينا استخدام جزء واحد فقط لكل قسم.
يمكن إعادة توجيه الرسائل إلى مقاطع بواسطة خوارزمية دورية أو من خلال وظيفة التجزئة: التجزئة (مفتاح الرسالة)٪ من الأقسام. , , , , , , . .
RabbitMQ. . , RabbitMQ , . , .
RabbitMQ . Kafka , .
, , Kafka , RabbitMQ — . RabbitMQ , . Kafka , . , , Kafka , .
, , , ( ). , , . , , , .
RabbitMQ — Consistent Hashing exchange, . Kafka' , Kafka , , , , , -. RabbitMQ , , , .
: , , Id 1000 , Id 1000 . , , . , .
(push) (pull)
RabbitMQ (push) , , . RabbitMQ . , Kafka (pull), . , , Kafka long-polling.
(pull) Kafka - . Kafka , , .
RabbitMQ, , , , . Kafka , .
Kafka /» , , . , .
التين. 9.
, , Kafka :
التين. 10. ,
, :
التين. 11.
, , .
, , , , .
التين. 12.
. .
:
, . , , .
Kafka – , , , , , . . , . , , .
— . , 50 . – . , , , .
, , . , , . , . , , , .
. , , .
, RabbitMQ, Kafka, Kafka . RabbitMQ , , ZooKeeper Consul.
RabbitMQ , Kafka. RabbitMQ, , . : .
. , . . , . . . , , - .
, Kafka, . . , , .
, . RabbitMQ , Kafka .
الاستنتاجات
RabbitMQ , . , , . , . , , .
Kafka . , . Kafka , RabbitMQ . , Kafka , RabbitMQ, , .
RabbitMQ.
, , IoT , . : t.me/justiothings