Apache Kafka and RabbitMQ: संदेश वितरण की शब्दार्थ और गारंटी

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

RabbitMQ और Kafka दोनों विश्वसनीय संदेश वितरण गारंटी प्रदान करते हैं। दोनों प्लेटफ़ॉर्म "अधिकांश वन-टाइम डिलीवरी" और "कम से कम एक-बार डिलीवरी" के सिद्धांतों पर वारंटी प्रदान करते हैं, लेकिन "कड़ाई से एक-बार वितरण" के सिद्धांत के साथ, काफ्का की वारंटी बहुत सीमित परिदृश्य के अनुसार लागू होती हैं।

सबसे पहले, आइए जानें कि इन गारंटियों का क्या मतलब है:

• सबसे अधिक-एक बार वितरण। इसका मतलब है कि संदेश को एक से अधिक बार डिलीवर नहीं किया जा सकता है। हालाँकि, संदेश खो सकता है।
• कम से कम-एक बार डिलीवरी। इसका मतलब है कि संदेश कभी खो नहीं जाएगा। इस मामले में, संदेश को एक से अधिक बार वितरित किया जा सकता है।
• बिल्कुल सही-एक बार डिलीवरी। मैसेजिंग सिस्टम की पवित्र कब्र। सभी संदेशों को एक बार सख्ती से वितरित किया जाता है।

शब्द "डिलीवरी" यहाँ एक सटीक शब्द नहीं होने की संभावना है। इसे "प्रसंस्करण" कहना अधिक सटीक होगा। किसी भी मामले में, अब हमें क्या दिलचस्पी है कि क्या उपभोक्ता संदेशों को संसाधित कर सकता है और यह किस सिद्धांत से होता है: "एक से अधिक नहीं", "कम से कम एक" या "सख्ती से एक बार"। लेकिन शब्द "प्रसंस्करण" धारणा को जटिल करता है, और इस मामले में "कड़ाई से एक बार 'के सिद्धांत द्वारा" वितरण "एक सटीक परिभाषा नहीं होगी, क्योंकि एक बार इसे ठीक से संसाधित करने के लिए संदेश को दो बार वितरित करना आवश्यक हो सकता है। यदि प्राप्तकर्ता प्रसंस्करण के दौरान डिस्कनेक्ट हो जाता है, तो संदेश को नए प्राप्तकर्ता को फिर से भेजा जाना चाहिए।

दूसरा वाला। संदेश प्रसंस्करण के मुद्दे पर चर्चा करते हुए, हम आंशिक विफलताओं के विषय पर आते हैं, जो डेवलपर्स के लिए सिरदर्द है। संदेश को संसाधित करने की प्रक्रिया में कई चरण होते हैं। इसमें शुरुआत और अंत में एप्लिकेशन और संदेश प्रणाली के बीच संचार सत्र होते हैं और बीच में डेटा के साथ काम करने वाले अनुप्रयोग स्वयं होते हैं। आंशिक अनुप्रयोग विफलता परिदृश्यों को अनुप्रयोग द्वारा ही नियंत्रित किया जाना चाहिए। यदि निष्पादित किए गए ऑपरेशन पूरी तरह से लेन-देन वाले हैं और परिणाम "सभी या कुछ नहीं" के सिद्धांत पर तैयार किए गए हैं, तो आवेदन तर्क में आंशिक विफलताओं से बचा जा सकता है। लेकिन अक्सर, कई चरणों में अन्य प्रणालियों के साथ बातचीत शामिल होती है, जहां लेनदेन असंभव है। यदि हम मैसेजिंग सिस्टम, एप्लिकेशन, कैश और डेटाबेस के बीच संबंधों को शामिल करते हैं, तो क्या हम "केवल-एक बार" आधार पर प्रसंस्करण की गारंटी दे सकते हैं? जवाब है नहीं।

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

लेकिन अगर संदेश प्रसंस्करण हमेशा ही बेरोजगार होता है, तो आप लेनदेन के माध्यम से "सख्ती से एक बार" रणनीति को लागू करने की आवश्यकता से बच सकते हैं। यदि संदेशों का अंतिम प्रसंस्करण बेकार है, तो आप डुप्लिकेट को स्वीकार करने के बारे में चिंता कर सकते हैं। लेकिन सभी कार्यों को आदर्श रूप से लागू नहीं किया जा सकता है।

एंड-टू-एंड अलर्ट

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

जिम्मेदारी की चेन

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

संदेश स्थानांतरण प्रक्रिया

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

संक्षेप में, RabbitMQ और Kafka दोनों ही पहली बार पहली (FIFO) गारंटी प्रदान करते हैं। RabbitMQ इस आदेश को कतार स्तर पर, और काफ्का को विभाजन स्तर पर बनाए रखता है। इस तरह के डिजाइन निर्णयों के निहितार्थ पिछले लेखों में चर्चा की गई थी।

RabbitMQ में डिलीवरी की गारंटी

वितरण की गारंटी प्रदान की जाती हैं:

• संदेश की विश्वसनीयता - वे RabbitMQ पर संग्रहीत करते समय गायब नहीं होंगे;
• संदेश सूचनाएँ - RabbitMQ प्रेषकों और प्राप्तकर्ताओं के साथ संकेतों का आदान-प्रदान करता है।

विश्वसनीयता तत्व

कतार दर्पण

कई नोड्स (सर्वर) पर कतारें मिरर (प्रतिकृति) की जा सकती हैं। प्रत्येक कतार में एक नोड पर एक अग्रणी कतार होती है। उदाहरण के लिए, तीन नोड्स, 10 कतारें और प्रति पंक्ति दो प्रतिकृतियां हैं। 10 नियंत्रण कतारों और 20 प्रतिकृतियों को तीन नोड्स में वितरित किया जाएगा। नोड्स द्वारा नियंत्रण कतारों के वितरण को कॉन्फ़िगर किया जा सकता है। नोड फ्रीज के मामले में:

• त्रिशंकु नोड पर प्रत्येक अग्रणी कतार के बजाय, इस नोड की एक प्रतिकृति दूसरे नोड पर प्रदान की जाती है;
• आउटगोइंग नोड पर खोए हुए प्रतिकृतियों को बदलने के लिए अन्य प्रतिकृतियों पर नए प्रतिकृतियां बनाई जाती हैं, इस प्रकार प्रतिकृति कारक का समर्थन किया जाता है।

दोष सहिष्णुता के मुद्दे पर लेख के अगले भाग में चर्चा की जाएगी।

विश्वसनीय कतार

RabbitMQ पर दो तरह की कतारें हैं: विश्वसनीय और अविश्वसनीय। भरोसेमंद कतारों को डिस्क पर लिखा जाता है और नोड रिबूट के मामले में बचाया जाता है। जब नोड शुरू होता है, तो वे ओवरराइड होते हैं।

लगातार पोस्ट

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

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

संदेश सूचनाएं

संदेश सेवा

संदेश संचरण के दौरान खो या डुप्लिकेट हो सकते हैं। यह प्रेषक के व्यवहार पर निर्भर करता है।

"शॉट और भूल गए"

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

प्रेषक को पुष्टि

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

• basic.ack। सकारात्मक पुष्टि। संदेश प्राप्त होता है, इसके लिए ज़िम्मेदारी अब RabbitMQ के पास है;
• basic.nack। नकारात्मक पुष्टि। कुछ हुआ और संदेश संसाधित नहीं हुआ। इसके लिए जिम्मेदारी स्रोत पर बनी हुई है। यदि वांछित है, तो वह दूसरी बार संदेश भेज सकता है।

सकारात्मक और नकारात्मक वितरण सूचनाओं के अलावा, एक basic.return संदेश प्रदान किया जाता है। कभी-कभी प्रेषक को न केवल यह जानने की जरूरत होती है कि यह संदेश RabbitMQ में आया था, बल्कि यह भी कि यह वास्तव में एक या एक से अधिक कतारों में गिरा था। ऐसा हो सकता है कि स्रोत विषय विनिमय प्रणाली को एक संदेश भेजता है, जिसमें संदेश किसी भी वितरण कतार में नहीं भेजा जाता है। इस स्थिति में, दलाल केवल संदेश को छोड़ देता है। कुछ परिदृश्यों में, यह सामान्य है, दूसरों में, स्रोत को पता होना चाहिए कि क्या संदेश को छोड़ दिया गया है, और इसके अनुसार आगे बढ़ें। आप अलग-अलग संदेशों के लिए "अनिवार्य" ध्वज सेट कर सकते हैं, और यदि संदेश किसी भी वितरण कतार में परिभाषित नहीं किया गया है, तो मूल। प्रेषक को वापस भेज दिया जाएगा।

प्रत्येक संदेश भेजने के बाद स्रोत पुष्टि की प्रतीक्षा कर सकता है, लेकिन इससे उसके प्रदर्शन में बहुत कमी आएगी। इसके बजाय, स्रोत संदेशों की एक स्थिर धारा भेज सकते हैं, अनजाने संदेशों की संख्या पर एक सीमा निर्धारित करते हैं। जब अंतरिम संदेश की सीमा समाप्त हो जाती है, तो सभी पुष्टि प्राप्त होने तक भेजना बंद कर दिया जाएगा।

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

पुष्टि के लिए धन्यवाद, हम निम्नलिखित तरीकों से संदेश हानि से बचते हैं:

• नकारात्मक अधिसूचना की स्थिति में संदेश भेजना;
• एक नकारात्मक सूचना या मूल .return की स्थिति में कहीं न कहीं संदेशों का भंडारण जारी रखा।

लेन-देन।

निम्नलिखित कारणों से लेनदेन का उपयोग शायद ही कभी RabbitMQ में किया जाता है:

• कमजोर वारंट। यदि संदेशों को कई कतारों में भेजा जाता है या उनके पास एक अनिवार्य आइकन है, तो लेनदेन की निरंतरता का समर्थन नहीं किया जाएगा;
• कम उत्पादकता।

ईमानदारी से, मैंने कभी भी उनका उपयोग नहीं किया, वे प्रेषक को पुष्टिकरण के अलावा कोई अतिरिक्त गारंटी नहीं देते हैं, और केवल लेनदेन के पूरा होने से उत्पन्न होने वाले संदेशों की प्राप्ति की व्याख्या कैसे करें, इस सवाल में अनिश्चितता बढ़ाते हैं।

संचार / चैनल त्रुटियों

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

ब्रोकर की विफलता तब हो सकती है जब संदेश ऑपरेटिंग सिस्टम बफर या पूर्व-संसाधित किया गया था, और फिर संदेश खो जाएगा। या, शायद संदेश पंक्तिबद्ध था, लेकिन पुष्टि भेजने से पहले संदेश दलाल की मृत्यु हो गई। इस मामले में, संदेश सफलतापूर्वक वितरित किया जाएगा।

इसी तरह, संचार के साधनों की विफलता स्थिति को प्रभावित करती है। क्या संदेश के प्रसारण के दौरान विफलता हुई? या संदेश के बाद पंक्तिबद्ध किया गया है, लेकिन सकारात्मक अधिसूचना प्राप्त करने से पहले?

प्रेषक इसे निर्धारित नहीं कर सकता है, इसलिए उसे निम्नलिखित विकल्पों में से एक को चुनना होगा:

• संदेश को अग्रेषित न करें, इसके नुकसान का जोखिम पैदा करना;
• संदेश फिर से भेजें और दोहराव का खतरा पैदा करें।

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

प्राप्तकर्ताओं

सूचनाएं प्राप्त करने के लिए प्राप्तकर्ताओं के लिए दो विकल्प उपलब्ध हैं:

• कोई अधिसूचना मोड नहीं;
• मैनुअल अधिसूचना मोड।

कोई अधिसूचना मोड नहीं

वह स्वचालित सूचनाओं का एक तरीका है। और वह खतरनाक है। सबसे पहले, क्योंकि जब कोई संदेश आपके आवेदन में मिलता है, तो उसे कतार से हटा दिया जाता है। इससे संदेश हानि हो सकती है यदि:

• संदेश प्राप्त होने से पहले कनेक्शन बाधित हो गया था;
• संदेश अभी भी आंतरिक बफ़र में है, और एप्लिकेशन अक्षम था;
• संदेश प्रसंस्करण विफल रहा।

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

मैनुअल अधिसूचना मोड

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

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

सूचनाएं निम्नानुसार हो सकती हैं:

• basic.ack। इसके बाद, RabbitMQ कतार से संदेश निकालता है। यहां कई ध्वज लगाए जा सकते हैं।
• basic.nack। संदेश भेजने वाले को फिर से कतार में खड़ा करना है या नहीं, यह जानने के लिए प्राप्तकर्ता को एक संदेश सेट करना होगा। जब संदेश को फिर से सेट करना कतार की शुरुआत में जाता है। वहां से इसे फिर से प्राप्तकर्ता (उसी प्राप्तकर्ता को) को भेजा जाता है। Basic.nack अधिसूचना कई ध्वज का समर्थन करती है।
• basic.reject। Basic.nack के समान है, लेकिन एकाधिक ध्वज का समर्थन नहीं करता है।

इस प्रकार, शब्दार्थ मूल रूप से। बुनियादी और आवश्यक के साथ आधार = गलत समान हैं। दोनों ऑपरेटरों का मतलब कतार से एक संदेश हटाना है।

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

कनेक्शन / संदेश ब्रोकर त्रुटि

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

लंबे समय तक प्राप्तकर्ता के पास संदेश होते हैं, जिसकी प्राप्ति की वह पुष्टि नहीं करता है, अग्रेषण का जोखिम अधिक होता है। जब कोई संदेश नाराज़ होता है, तो फ़ॉरवर्डिंग फ़्लैग के लिए RabbitMQ सही पर सेट हो जाता है। इसके कारण, प्राप्तकर्ता को कम से कम एक संकेत मिलता है कि संदेश पहले से ही संसाधित हो सकता है।

idempotency

यदि idempotency आवश्यक है और गारंटी देता है कि कोई भी संदेश गुम नहीं हुआ है, तो कुछ डुप्लिकेट चेक या अन्य idempotent योजनाओं का निर्माण किया जाना चाहिए। यदि डुप्लिकेट संदेशों की जाँच करना बहुत महंगा है, तो आप एक ऐसी रणनीति लागू कर सकते हैं जिसमें प्रेषक हमेशा संदेशों को पुनः भेजने के लिए एक विशेष शीर्ष लेख जोड़ता है, और प्राप्तकर्ता ऐसे हेडर और फिर से भेजे गए ध्वज की उपस्थिति के लिए प्राप्त संदेशों की जाँच करता है।

निष्कर्ष

RabbitMQ विश्वसनीय, लंबी अवधि की मैसेजिंग गारंटी प्रदान करता है, लेकिन कई परिस्थितियां हैं जहां वे मदद नहीं करेंगे।

यहाँ याद करने के लिए बिंदुओं की एक सूची है:

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

काफ्का में डिलीवरी की गारंटी

वितरण की गारंटी प्रदान की जाती हैं:

• संदेश स्थायित्व - एक खंड में संग्रहीत संदेश खो नहीं जाते हैं;
• संदेश सूचनाएँ - एक ओर कफ़्का (और संभवतः अपाचे ज़ूपर भंडार) के बीच संकेतों का आदान-प्रदान और दूसरी ओर स्रोत / रिसीवर।

संदेश पैकेजिंग के बारे में दो शब्द

RabbitMQ और Kafka के बीच अंतरों में से एक संदेश के लिए संकुल का उपयोग है।

RabbitMQ पैकेजिंग के समान कुछ प्रदान करता है धन्यवाद:

• सभी सूचनाएं प्राप्त होने तक हर X संदेश भेजने को निलंबित करें। RabbitMQ आमतौर पर "एकाधिक" ध्वज का उपयोग करके सूचनाओं को समूहित करता है।
• «prefetch» «multiple».

. “multiple”. TCP.

Kafka . , . RabbitMQ, , , . , .

Kafka , , . , . RabbitMQ API , . RabbitMQ .

,



Kafka - , , . . , , , , , .

Kafka (In Sync Replicas, ISR). . , , ( 10 ). , . - , .. . .



, Kafka , , , Kafka .



, Kafka, , :

• , . Acks=0.
• . Acks=1
• . Acks=All

, RabbitMQ. , , ( , ). , .

Kafka . :

• enable.idempotence “true”,
• max.in.flight.requests.per.connection 5 ,
• retries 1 ,
• acks “all”.

, acks=0/1 , .



, , . ZooKeeper Kafka.

(), , :

• . . . . , .
• , . “ ”. , ; , . , 10 , 4 , , , ;
• , . “ ”. , , , . , 10 , , 4 ;
• . , .

“ ” Kafka Streams, Java. Java . “ ”, , , . , , “ ” . , , () .

, Kafka Streams, , , “ ”. Kafka: . , . , , , ( ), .



Kafka “--”. . , , .

“ ”, , (, , ). “ ”, , . .

: “ ” ? . , , . . (Last Stable Offset, LSO) — ; “ ” .

निष्कर्ष

. , , . , Kafka , .

संक्षेप में देना

• “ ” “ ”.
• .
• , . Kafka , .
• , , .
• .
• Kafka , “--”. .
• Kafka, - , ( ). RabbitMQ .
• कफ़का पैकेट वितरण क्षमताओं के कारण पैकेटीकरण के लाभों को बढ़ा सकता है, और रैबिटएमक्यू में एक निष्क्रिय प्राप्त मॉडल के कारण पैकेटीकरण नहीं होता है जो प्राप्तकर्ता के टकराव को नहीं रोकता है।