RabbitMQ बनाम काफ्का: दो अलग संदेश दृष्टिकोण

पिछले दो लेखों में, हमने IIoT के बारे में बात की थी - चीजों का औद्योगिक इंटरनेट - सेंसर से डेटा प्राप्त करने के लिए एक वास्तुकला का निर्माण किया, सेंसर को खुद को मिलाया। IIoT आर्किटेक्चर की आधारशिला और वास्तव में बिगडेटा के साथ काम करने वाले किसी भी आर्किटेक्चर का डेटा स्ट्रीम प्रोसेसिंग है। यह मैसेजिंग और कतार की अवधारणा पर आधारित है। मैसेजिंग के साथ काम करने का मानक अब अपाचे काफ्का बन गया है। हालांकि, इसके फायदे (और इसके नुकसानों को समझने) को समझने के लिए कतार प्रणालियों के संचालन की मूल बातें, उनके संचालन के तंत्र, उपयोग के पैटर्न और बुनियादी कार्यक्षमता को समझना अच्छा होगा।

हमें लेखों की एक उत्कृष्ट श्रृंखला मिली जो अपाचे काफ्का की कार्यक्षमता की तुलना करती है और कतार प्रणालियों के बीच एक और (अवांछनीय रूप से अनदेखा) विशाल की तुलना करती है - RabbitMQ। हमने लेखों की इस श्रृंखला का अनुवाद किया है, उन्हें टिप्पणियां प्रदान की हैं और उन्हें पूरक बनाया है। हालाँकि यह श्रृंखला दिसंबर 2017 में लिखी गई थी, संदेश प्रणाली (और विशेष रूप से अपाचे काफ्का) की दुनिया इतनी तेज़ी से बदल रही है कि 2018 की गर्मियों तक, कुछ चीजें बदल गई हैं।

स्रोत

रैबिटएमक्यू बनाम काफ्का

मैसेजिंग कई आर्किटेक्चर का केंद्रीय हिस्सा है, और इस क्षेत्र में दो स्तंभ हैं रैबिटएमक्यू और अपाचे काफ्का। आज तक, अपाचे काफ्का डेटा प्रोसेसिंग और एनालिटिक्स में लगभग औद्योगिक मानक बन गया है, इसलिए इस श्रृंखला में हम रियल-टाइम इन्फ्रास्ट्रक्चर में उनके उपयोग के संदर्भ में RabbitMQ और काफ्का पर करीब से नज़र डालेंगे।

अपाचे काफ्का अब बढ़ रहा है, लेकिन ऐसा लगता है कि वे RabbitMQ के बारे में भूलना शुरू कर दिया। सभी प्रचार काफ्का पर केंद्रित थे, और यह स्पष्ट कारणों के लिए होता है, लेकिन रैबिटएमक्यू अभी भी संदेश के लिए एक बढ़िया विकल्प है। काफ्का ने जिन कारणों से अपना ध्यान अपनी ओर खींचा है, उनमें से एक है इसका स्केलिबिलिटी के प्रति सामान्य जुनून, और जाहिर है कि काफ्का रैबिटएमक्यू की तुलना में अधिक स्केलेबल है, लेकिन हम में से अधिकांश को उस पैमाने से कोई सरोकार नहीं है जिस पर रैबिटमक्यू को समस्या है। हममें से ज्यादातर लोग गूगल या फेसबुक नहीं हैं। हममें से अधिकांश दैनिक संदेशों को सैकड़ों हजारों से लेकर लाखों लोगों तक पहुंचाते हैं, न कि अरबों से लेकर खरबों तक के संस्करणों के साथ (लेकिन वैसे भी, ऐसे मामले हैं जब लोगों ने अरबों-खरबों दैनिक संदेशों को स्केल किया)।

इस प्रकार, हमारे लेखों की श्रृंखला में हम उन मामलों के बारे में बात नहीं करेंगे जहां चरम स्केलेबिलिटी की आवश्यकता होती है (और यह काफ्का का विशेषाधिकार है), बल्कि उन अनूठे फायदों पर ध्यान केंद्रित करते हैं जो कि प्रत्येक सिस्टम विचार के तहत प्रदान करता है। दिलचस्प है, प्रत्येक प्रणाली के अपने फायदे हैं, लेकिन साथ ही वे एक-दूसरे से काफी अलग हैं। बेशक, मैंने RabbitMQ के बारे में बहुत कुछ लिखा है, लेकिन मैं आपको विश्वास दिलाता हूं कि मैं इसे कोई विशेष प्राथमिकता नहीं देता। मुझे अच्छी तरह से बनाई गई चीजें पसंद हैं, और RabbitMQ और Kafka दोनों काफी परिपक्व, विश्वसनीय और, हां, स्केलेबल मैसेजिंग सिस्टम हैं।

हम शीर्ष स्तर पर शुरू करेंगे, और फिर इन दोनों प्रौद्योगिकियों के विभिन्न पहलुओं का अध्ययन करना शुरू करेंगे। लेखों की यह श्रृंखला उन मैसेजिंग सिस्टम या आर्किटेक्ट / इंजीनियरों को संगठित करने वाले पेशेवरों के लिए है जो निचले स्तर और उनके आवेदन के विवरण को समझना चाहते हैं। हम कोड नहीं लिखेंगे, लेकिन इसके बजाय दोनों प्रणालियों द्वारा पेश की जाने वाली कार्यक्षमता पर ध्यान केंद्रित करते हैं, मैसेजिंग प्रक्रिया टेम्प्लेट्स जो उनमें से प्रत्येक प्रदान करता है, और निर्णय जो डेवलपर्स और आर्किटेक्ट को करना चाहिए।

RabbitMQ बनाम काफ्का: दो अलग संदेश दृष्टिकोण

इस भाग में, हम देखेंगे कि RabbitMQ और Apache Kafka क्या हैं, और संदेश के लिए उनका दृष्टिकोण। दोनों प्रणालियां अलग-अलग कोणों से मैसेजिंग आर्किटेक्चर का रुख करती हैं, जिनमें से प्रत्येक में ताकत और कमजोरियां हैं। इस अध्याय में, हम किसी भी महत्वपूर्ण निष्कर्ष पर नहीं आएंगे, इसके बजाय, हम इस लेख को शुरुआती लोगों के लिए प्रौद्योगिकी मैनुअल के रूप में लेने का प्रस्ताव करते हैं, ताकि हम श्रृंखला के अगले लेखों में गहराई से गोता लगा सकें।

RabbitMQ

RabbitMQ एक वितरित संदेश कतार प्रबंधन प्रणाली है। वितरित, क्योंकि यह आमतौर पर नोड्स के क्लस्टर के रूप में काम करता है, जहां नोड्स के बीच कतारें वितरित की जाती हैं और, वैकल्पिक रूप से, त्रुटि प्रतिरोधी और उच्च उपलब्धता के क्रम में दोहराया जाता है। नियमित रूप से, यह AMQP 0.9.1 को लागू करता है और अतिरिक्त प्रोटोकॉल, जैसे STOMP, MQTT और HTTP अतिरिक्त मॉड्यूल प्रदान करता है।

RabbitMQ क्लासिक और इनोवेटिव मैसेजिंग दोनों दृष्टिकोणों का उपयोग करता है। क्लासिक इस अर्थ में कि यह संदेश कतार पर केंद्रित है, और अभिनव - लचीला रूटिंग की संभावना में। यह रूटिंग सुविधा इसका अनूठा लाभ है। एक तेज़, स्केलेबल और विश्वसनीय वितरित मैसेजिंग सिस्टम बनाना अपने आप में एक उपलब्धि है, लेकिन मैसेजिंग रूटिंग कार्यक्षमता कई मैसेजिंग तकनीकों के बीच इसे वास्तव में उत्कृष्ट बनाती है।

विनिमय और कतार

सुपर सरलीकृत समीक्षा:

• प्रकाशक (प्रकाशक) एक्सचेंजों को संदेश भेजते हैं
• Exchange'i कतारों और अन्य एक्सचेंजों में संदेश भेजते हैं
• संदेश प्राप्त होने पर RabbitMQ प्रकाशकों को पुष्टिकरण भेजता है
• प्राप्तकर्ता (उपभोक्ता) RabbitMQ के लिए लगातार टीसीपी कनेक्शन बनाए रखते हैं और घोषणा करते हैं कि उन्हें कौन सी कतार मिलती है
• RabbitMQ संदेश प्राप्तकर्ताओं को धक्का देता है
• प्राप्तकर्ता सफलता / त्रुटि पुष्टिकरण भेजते हैं
• सफल प्राप्ति पर, संदेश कतारों से हटा दिए जाते हैं।

इस सूची में बड़ी संख्या में ऐसे निर्णय शामिल हैं, जिन्हें डेवलपर्स और प्रशासकों को अपनी आवश्यकता, प्रदर्शन विशेषताओं, आदि की गारंटी देने के लिए लेना चाहिए, जिनमें से प्रत्येक पर हम बाद में चर्चा करेंगे।

आइए एक प्रकाशक, विनिमय, कतार और रिसीवर के साथ काम करने का एक उदाहरण देखें:

अंजीर। 1. एक प्रकाशक और एक प्राप्तकर्ता

यदि आपके पास उसी के कई प्रकाशक हैं तो क्या करें
पदों? क्या होगा यदि हमारे पास कई प्राप्तकर्ता हैं, जिनमें से प्रत्येक सभी संदेश प्राप्त करना चाहता है?

अंजीर। 2. कई प्रकाशक, कई स्वतंत्र प्राप्तकर्ता

जैसा कि आप देख सकते हैं, प्रकाशक अपने संदेशों को उसी एक्सचेंजर को भेजते हैं, जो प्रत्येक संदेश को तीन कतारों में भेजता है, जिनमें से प्रत्येक के पास एक प्राप्तकर्ता होता है। RabbitMQ के मामले में, कतारें अलग-अलग प्राप्तकर्ता को सभी संदेश प्राप्त करने की अनुमति देती हैं। नीचे दिए गए चार्ट से तुलना करें:

अंजीर। 3. एकाधिक प्रकाशकों, कई प्रतिस्पर्धी प्राप्तकर्ताओं के साथ एक कतार

चित्र 3 में, हम तीन प्राप्तकर्ता देखते हैं जो एक ही कतार का उपयोग करते हैं। ये प्रतियोगी प्राप्त कर रहे हैं, अर्थात, वे कतार से संदेश प्राप्त करने के लिए प्रतिस्पर्धा कर रहे हैं। इस प्रकार, यह उम्मीद की जा सकती है कि प्रत्येक प्राप्तकर्ता औसतन कतार में एक तिहाई संदेश प्राप्त करेगा। हम अपने संदेश प्रसंस्करण प्रणाली को स्केल करने के लिए प्रतिस्पर्धी प्राप्तकर्ताओं का उपयोग करते हैं, और RabbitMQ का उपयोग करते हुए ऐसा करना बहुत सरल है: अनुरोध पर प्राप्तकर्ता को जोड़ें या निकालें। कोई फर्क नहीं पड़ता कि आपके पास कितने प्रतिस्पर्धी प्राप्तकर्ता हैं, RabbitMQ केवल एक प्राप्तकर्ता को संदेश देगा।

हम चावल को मिला सकते हैं। प्रतिस्पर्धी प्राप्तकर्ताओं के कई सेट प्राप्त करने के लिए 2 और 3, जहां प्रत्येक सेट प्रत्येक संदेश प्राप्त करता है।

अंजीर। 4. कई प्रकाशकों, प्रतिस्पर्धी प्राप्तकर्ताओं के साथ कई कतारें

एक्सचेंजर्स और क्वीन्स के बीच के तीर को बाइंडिंग कहा जाता है, और हम उनके बारे में अधिक विस्तार से बात करेंगे।

सुरक्षा उपायों

RabbitMQ "वन-टाइम डिलीवरी" और "कम से कम एक डिलीवरी" की गारंटी देता है, लेकिन "बिल्कुल एक डिलीवरी" नहीं।

अनुवादक का नोट: काफ्का संस्करण ०.११ से पहले, बिल्कुल-एक बार वितरण संदेश उपलब्ध नहीं था, वर्तमान में, इसी तरह की कार्यक्षमता काफ्का में मौजूद है।

संदेशों को कतार में पहुंचने के क्रम में वितरित किया जाता है (आखिरकार, यह कतार की परिभाषा है)। यह गारंटी नहीं देता है कि जब आपके पास प्रतिस्पर्धी प्राप्तकर्ता हों, तो संदेश संसाधन का पूरा होना उसी क्रम से मेल खाता है। यह एक RabbitMQ त्रुटि नहीं है, लेकिन संदेशों के एक सेट के समानांतर प्रसंस्करण की मौलिक वास्तविकता है। यह समस्या निरंतर हैशिंग एक्सचेंज का उपयोग करके हल की जा सकती है, जैसा कि आप अगले अध्याय में टेम्प्लेट और टोपोलॉजी पर देखेंगे।

पुश और प्रीफ़ैच प्राप्तकर्ता

RabbitMQ संदेशों को प्राप्तकर्ताओं तक पहुंचाता है (RabbitMQ के संदेशों को खींचने के लिए एक API भी है, लेकिन यह कार्यक्षमता अभी ठीक नहीं है)। यह प्राप्तकर्ता को अभिभूत कर सकता है यदि संदेश कतार में तेजी से पहुंचते हैं, तो प्राप्तकर्ता उन्हें संसाधित कर सकते हैं। इससे बचने के लिए, प्रत्येक प्राप्तकर्ता प्रीफ़ेट सीमा (जिसे क्यूओएस सीमा के रूप में भी जाना जाता है) सेट कर सकता है। वास्तव में, क्यूओएस सीमा उन संदेशों की संख्या पर एक सीमा है जिन्हें प्राप्तकर्ता द्वारा संचित नहीं किया गया है। यह फ्यूज की तरह काम करता है जब रिसीवर पिछड़ने लगता है।

यह क्यों तय किया गया था कि कतार में संदेशों को धक्का (धक्का) दिया जाता है, न कि अनलोड (पुल) किया जाता है? सबसे पहले, क्योंकि देरी का समय कम है। दूसरे, आदर्श रूप से, जब हमारे पास उसी कतार से प्राप्त करने वाले प्रतियोगी हैं, तो हम उनके बीच लोड को समान रूप से वितरित करना चाहते हैं। यदि प्रत्येक प्राप्तकर्ता संदेशों को डाउनलोड / डाउनलोड करने का अनुरोध करता है, तो वे कितना अनुरोध करते हैं, उसके आधार पर कार्य का वितरण असमान हो सकता है। संदेशों का वितरण जितना अधिक असमान होता है, प्रसंस्करण के दौरान संदेशों के क्रम में उतनी ही अधिक देरी और नुकसान होता है। ये कारक एक संदेश-ऑन-ए-टाइम पुश तंत्र की ओर RabbitMQ आर्किटेक्चर को उन्मुख करते हैं। यह RabbitMQ स्केलिंग की सीमाओं में से एक है। सीमा को इस तथ्य से कम किया जाता है कि पुष्टि को समूहीकृत किया जा सकता है।

मार्ग

एक्सचेंज के मूल रूप से कतार और / या अन्य एक्सचेंजों के लिए संदेश राउटर हैं। संदेश को एक्सचेंज से कतार में या किसी अन्य एक्सचेंज में ले जाने के लिए, बंधन आवश्यक है। विभिन्न एक्सचेंजों को अलग-अलग बाइंडिंग की आवश्यकता होती है। एक्सचेंज और संबद्ध बाइंडिंग के चार प्रकार हैं:

• फैनआउट (शाखाओं)। पब के स्टैंडर्ड सबमॉडल के आदान-प्रदान के लिए बाध्य सभी कतारों और एक्सचेंजों को निर्देश।
• प्रत्यक्ष (प्रत्यक्ष)। राउटिंग कुंजी के आधार पर संदेशों को रूट करता है कि संदेश प्रकाशक द्वारा निर्धारित किया जाता है। रूटिंग कुंजी एक छोटी स्ट्रिंग है। प्रत्यक्ष एक्सचेंजर्स संदेश / विनिमय कतारों को भेजते हैं जिनके पास एक युग्मन कुंजी है जो रूटिंग कुंजी से बिल्कुल मेल खाती है।
• विषय (विषयगत)। रूटिंग कुंजी के आधार पर संदेशों को रूट करता है, लेकिन अधूरे मिलान (वाइल्डकार्ड) के उपयोग की अनुमति देता है।
• हेडर (हेडर)। RabbitMQ आपको संदेशों में प्राप्तकर्ता हेडर जोड़ने की अनुमति देता है। हेडर एक्सचेंज इन हेडर मूल्यों के अनुसार संदेश भेजते हैं। प्रत्येक बंधन में हेडर मानों का सटीक मिलान शामिल होता है। आप मिलान करने के लिए आवश्यक किसी भी या सभी मानों के साथ बाइंडिंग में कई मान जोड़ सकते हैं।
• लगातार होशिंग। यह एक एक्सचेंजर है जो या तो एक रूटिंग कुंजी या एक संदेश शीर्षलेख हैश करता है, और केवल एक कतार में भेजता है। यह तब उपयोगी होता है जब आपको प्रोसेसिंग ऑर्डर गारंटी का पालन करने की आवश्यकता होती है और फिर भी प्राप्तकर्ता प्राप्त करने में सक्षम होते हैं।

अंजीर। 5. उदाहरण विषय विनिमय

हम अधिक विस्तार से रूटिंग पर भी विचार करेंगे, लेकिन विषय विनिमय उदाहरण ऊपर दिया गया है। इस उदाहरण में, प्रकाशक रूटिंग कुंजी प्रारूप LEVEL (त्रुटि स्तर) .AppName का उपयोग करके त्रुटि लॉग प्रकाशित करते हैं।

कतार 1 को सभी संदेश प्राप्त होंगे क्योंकि यह कई शब्दों के साथ वाइल्डकार्ड नंबर का उपयोग करता है।

कतार 2 को किसी भी स्तर का ECommerce.WebUI एप्लिकेशन लॉगिंग प्राप्त होगा। यह वाइल्डकार्ड * का उपयोग करता है, इस प्रकार एकल विषय नामकरण (ERROR.Ecommerce.WebUI, NOTICE.ECommerce.WebUI, आदि) के स्तर को कैप्चर करता है।

कतार 3 किसी भी एप्लिकेशन से सभी ERROR संदेश प्रदर्शित करेगा। यह सभी एप्लिकेशन (ERROR.ECommerce.WebUi, ERROR.SomeApp.SomeSittlevel, आदि) को कवर करने के लिए वाइल्डकार्ड # का उपयोग करता है।

संदेश के चार तरीकों के लिए धन्यवाद और अन्य एक्सचेंजों को संदेश भेजने के लिए संदेशों का आदान-प्रदान करने की क्षमता के साथ, RabbitMQ आपको संदेश विनिमय टेम्पलेट्स के एक शक्तिशाली और लचीले सेट का उपयोग करने की अनुमति देता है। इसके अलावा हम मृत पत्र के आदान-प्रदान के साथ एक्सचेंजों के बारे में बात करेंगे, बिना डेटा (अल्पकालिक आदान-प्रदान और कतार) के एक्सचेंजों और कतारों के बारे में, और RabbitMQ अपनी पूरी क्षमता तक विस्तार करेगा।

अपरिवर्तित विनिमय

अनुवादक का नोट: जब कतार से संदेश एक कारण या किसी अन्य के लिए प्राप्त नहीं किया जा सकता (उपभोक्ता शक्ति पर्याप्त नहीं है, नेटवर्क की समस्याएं, आदि), तो उन्हें देरी से और अलग से संसाधित किया जा सकता है।

हम कतारों को कॉन्फ़िगर कर सकते हैं ताकि संदेशों को निम्नलिखित शर्तों के तहत आदान-प्रदान करने के लिए भेजा जाए:

• कतार संदेशों की निर्दिष्ट संख्या से अधिक है।
• कतार बाइट्स की निर्दिष्ट संख्या से अधिक है।
• संदेश प्रसारण समय (TTL) की समय सीमा समाप्त हो गई है। प्रकाशक संदेश को आजीवन सेट कर सकता है, और कतार में संदेश के लिए निर्दिष्ट टीटीएल भी हो सकता है। इस स्थिति में, दो का छोटा TTL उपयोग किया जाएगा।

हम एक पंक्ति बनाते हैं, जो कि अपरिवर्तित संदेशों के आदान-प्रदान के लिए बाध्य है, और कुछ कार्रवाई होने तक ये संदेश वहां संग्रहीत किए जाते हैं।

RabbitMQ के कई कार्यों की तरह, अपरिवर्तनीय संदेशों के आदान-प्रदान से उन टेम्प्लेट का उपयोग करना संभव हो जाता है जो मूल रूप से प्रदान नहीं किए गए थे। टीटीएल संदेशों और एक्सचेंजों का उपयोग हम उदासीन संदेशों के साथ आस्थगित कतारों और पुनर्प्रयास कतारों को लागू करने के लिए कर सकते हैं।

डेटा के बिना एक्सचेंजर्स और कतारें

एक्सचेंजों और कतारों को गतिशील रूप से बनाया जा सकता है, और आप उनके स्वत: हटाने के लिए मानदंड निर्धारित कर सकते हैं। यह संदेश-आधारित RPC जैसे पैटर्न के उपयोग की अनुमति देता है।

अतिरिक्त मॉड्यूल

पहला प्लग-इन जिसे आप शायद इंस्टॉल करना चाहते हैं, वह प्रबंधन प्लगइन है, जो वेब इंटरफ़ेस और REST API के साथ एक HTTP सर्वर प्रदान करता है। यह स्थापित करना बहुत आसान है और इंटरफ़ेस का उपयोग करना आसान है। REST API के माध्यम से लिपियों की तैनाती भी बहुत सरल है।

इसके अलावा:

• लगातार हैशिंग एक्सचेंज, शेयरिंग एक्सचेंज, और अधिक
• STOMP और MQTT जैसे प्रोटोकॉल
• वेब हुक
• एक्सचेंजर्स के अतिरिक्त प्रकार
• SMTP एकीकरण

कई अन्य चीजें हैं जिन्हें RabbitMQ के बारे में कहा जा सकता है, लेकिन यह एक अच्छा उदाहरण है जो आपको यह बताने की अनुमति देता है कि RabbitMQ क्या कर सकता है। अब हम काफ्का को देखते हैं, जो मैसेजिंग के लिए एक पूरी तरह से अलग दृष्टिकोण का उपयोग करता है और एक ही समय में, विशिष्ट, दिलचस्प विशेषताओं का अपना सेट भी है।

अपाचे काफ्का

Kafka एक वितरित प्रतिकृति प्रतिबद्ध लॉग है। काफ्का के पास कतारों की कोई अवधारणा नहीं है, जो पहली बार में अजीब लग सकती है, यह देखते हुए कि यह एक संदेश प्रणाली के रूप में उपयोग किया जाता है। कतारें लंबे समय से संदेश प्रणालियों का पर्याय रही हैं। सबसे पहले, आइए देखें कि "वितरित, प्रतिकृति परिवर्तन प्रतिबद्ध लॉग" का क्या अर्थ है:

• वितरित क्योंकि काफ़्का को नोड्स के एक समूह के रूप में तैनात किया जाता है, दोनों त्रुटि सहिष्णुता और स्केलिंग के लिए
• संदेश, आमतौर पर कई नोड्स (सर्वर) पर दोहराया जाता है।
• एक कमिट लॉग क्योंकि संदेशों को खंडों में संग्रहीत किया जाता है, एपेंड-केवल लॉग नामक विषय। यह लॉगिंग अवधारणा काफ्का का प्राथमिक अनूठा लाभ है।

पत्रिका (और विषय) और विभाजन को समझना कफ़्का को समझने की कुंजी है। तो एक विभाजित लॉग कतारों के सेट से कैसे भिन्न होता है? आइए कल्पना करें कि यह कैसा दिखता है।

अंजीर। 6 एक निर्माता, एक खंड, एक प्राप्तकर्ता

FIFO कतार में संदेश डालने और कतार में इस संदेश की स्थिति की निगरानी करने के बजाय, जैसा कि RabbitMQ करता है, काफ्का बस इसे लॉग में जोड़ता है, और वह सब।

संदेश रहता है, चाहे वह एक या अधिक बार प्राप्त हो। इसे रिटेंशन पॉलिसी के अनुसार हटा दिया जाता है, जिसे विंडो टाइम पीरियड भी कहा जाता है। विषय से जानकारी कैसे ली जाती है?

प्रत्येक प्राप्तकर्ता ट्रैक रखता है कि वह लॉग में कहां स्थित है: प्राप्त अंतिम संदेश के लिए एक सूचक है और इस सूचक को ऑफसेट पता कहा जाता है। प्राप्तकर्ता ग्राहक पुस्तकालयों के माध्यम से इस पते का समर्थन करते हैं, और काफ्का के संस्करण के आधार पर, पता चिड़ियाघरकीपर या काफ्का में ही संग्रहीत किया जाता है।

जर्नलिंग मॉडल की एक विशिष्ट विशेषता यह है कि यह संदेश वितरण की स्थिति के बारे में कई कठिनाइयों को तुरंत समाप्त कर देता है और, अधिक महत्वपूर्ण रूप से प्राप्तकर्ताओं के लिए, उन्हें पिछले रिश्तेदार पते पर संदेश वापस लाने, वापस करने और प्राप्त करने की अनुमति देता है। उदाहरण के लिए, कल्पना करें कि आप एक ऐसी सेवा को तैनात कर रहे हैं जो ग्राहकों द्वारा रखे गए आदेशों को ध्यान में रखते हुए चालान जारी करती है। सेवा में एक त्रुटि है, और यह 24 घंटों में सभी बिलों की सही गणना नहीं करता है। RabbitMQ के साथ सर्वोत्तम रूप से, आपको किसी तरह इन आदेशों को केवल खाता सेवा पर पुनः प्रकाशित करना होगा। लेकिन काफ्का के साथ, आप बस 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