🛴 👩‍❤️‍👨 👴🏼 संदेश दलालों को समझना। ActiveMQ और Kafka के माध्यम से संदेश भेजने के यांत्रिकी सीखना। अध्याय 3. काफ्का ⚾️ 😃 💪🏿

एक छोटी सी पुस्तक के अनुवाद की निरंतरता:
"मैसेज ब्रोकर्स को समझना",
लेखक: जैकब कोरब, प्रकाशक: ओ'रेली मीडिया, इंक।, प्रकाशन तिथि: जून २०१ab, आईएसबीएन: ९ 4929१४ ९ २०४ ९ २ ९ ६६।

अनुवाद पूरा हुआ: tele.gg/middle_java

पिछला भाग: मैसेज ब्रोकर्स को समझना ActiveMQ और Kafka के माध्यम से संदेश के मैकेनिक्स सीखना। अध्याय 2. ActiveMQ

अध्याय 3

काफ्का

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

इस अंतिम लक्ष्य को देखते हुए, स्वाभाविक रूप से अन्य आवश्यकताएं उत्पन्न हुईं। काफ्का चाहिए:

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

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

यूनिफाइड डेस्टिनेशन मॉडल

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

इस अध्याय के शेष भाग में, जब तक कि हम स्पष्ट रूप से अन्यथा निर्दिष्ट नहीं करते हैं, शब्द विषय काफका विषय को संदर्भित करेगा।

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

"पत्रिका" और "सूचकांक" शब्द कफका दस्तावेज में नहीं पाए जाते हैं। इन प्रसिद्ध शब्दों को समझने में मदद करने के लिए यहां उपयोग किया जाता है।

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

चित्र 3-1। विभाजन कफका

जब निर्माता कफका विषय को संदेश भेजता है, तो वह यह तय करता है कि संदेश भेजने के लिए कौन सा विभाजन है। हम बाद में इस पर अधिक विस्तार से विचार करेंगे।

संदेश पढ़ना

एक ग्राहक जो संदेश पढ़ना चाहता है, एक उपभोक्ता समूह नामक एक नामित सूचक को नियंत्रित करता है, जो एक विभाजन में एक संदेश की भरपाई को इंगित करता है। एक ऑफसेट एक बढ़ती हुई संख्या के साथ एक स्थिति है जो विभाजन की शुरुआत में 0 से शुरू होती है। उपभोक्ताओं का यह समूह, जो उपयोगकर्ता द्वारा परिभाषित पहचानकर्ता group_id के माध्यम से API में संदर्भित है, एकल तार्किक उपभोक्ता या सिस्टम से मेल खाता है ।

अधिकांश मैसेजिंग सिस्टम समानांतर में प्रोसेसिंग संदेशों के लिए कई इंस्टेंस और थ्रेड्स के माध्यम से प्राप्तकर्ता के डेटा को पढ़ते हैं। इस प्रकार, आमतौर पर उपभोक्ताओं के कई उदाहरण होंगे जो उपभोक्ताओं के एक ही समूह को साझा करते हैं।

पढ़ने की समस्या को निम्नानुसार दर्शाया जा सकता है:

विषय के कई विभाजन हैं
उपभोक्ताओं के कई समूह एक ही समय में विषय का उपयोग कर सकते हैं।
उपभोक्ताओं के एक समूह के कई अलग-अलग उदाहरण हो सकते हैं।

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

उपभोक्ता और उपभोक्ता समूह

आइए एकल-विभाजन विषय को प्रारंभिक बिंदु ( चित्र 3-2 ) के रूप में लेते हैं।

चित्र 3-2। उपभोक्ता विभाजन से पढ़ता है

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

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

चित्र 3-3। उपभोक्ताओं के विभिन्न समूहों में दो उपभोक्ता एक ही विभाजन से पढ़ते हैं

उपभोक्ता समूह में उपभोक्ता

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

चित्र 3-4। उपभोक्ताओं के एक ही समूह में दो उपभोक्ता एक ही विभाजन से पढ़ते हैं

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

यह संदेश वितरण व्यवहार, जो ऊपर वर्णित है, की तुलना में आश्चर्यचकित हो सकता है कि एक नियमित जेएमएस कतार कैसे व्यवहार करती है। इस मॉडल में, कतार में भेजे गए संदेश दोनों उपभोक्ताओं के बीच समान रूप से वितरित किए जाएंगे।

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

ऐसा करने का एक तरीका यह है कि सभी संदेशों को पढ़ने और उन्हें थ्रेड पूल में भेजने के लिए उपभोक्ता के एक उदाहरण का उपयोग किया जाए। यद्यपि यह दृष्टिकोण प्रसंस्करण थ्रूपुट को बढ़ाता है, यह उपभोक्ताओं के तर्क की जटिलता को बढ़ाता है और रीडिंग सिस्टम की स्थिरता को बढ़ाने के लिए कुछ भी नहीं करता है। यदि बिजली की विफलता या इसी तरह की घटना के कारण उपभोक्ता का एक उदाहरण बंद हो जाता है, तो प्रूफरीडिंग बंद हो जाती है।

काफ्का में इस समस्या को हल करने के लिए विहित तरीका अधिक विभाजन का उपयोग करना है।

विभाजन

ब्रोकर के एक उदाहरण के बैंडविड्थ से परे विषय के पढ़ने और स्केलिंग को समानांतर करने के लिए विभाजन मुख्य तंत्र हैं। इसे बेहतर ढंग से समझने के लिए, आइए एक ऐसी स्थिति देखें जहां एक विषय है जिसमें दो विभाजन हैं और एक उपभोक्ता इस विषय ( चित्र 3-5 ) की सदस्यता लेता है।

चित्र 3-5। एक उपभोक्ता कई विभाजन से पढ़ता है

इस परिदृश्य में, सलाहकार को दोनों विभाजन में अपने group_id के अनुरूप बिंदुओं पर नियंत्रण दिया जाता है, और दोनों विभाजन से संदेश पढ़ना शुरू होता है।
जब इस समूह के लिए इस विषय में एक अतिरिक्त कंप्यूरेटर जोड़ा जाता है, तो पहले से दूसरे भाग में विभाजन में से एक काफ्का पुन: असाइन करता है। उसके बाद, उपभोक्ता के प्रत्येक उदाहरण को विषय के एक विभाजन से घटाया जाएगा ( चित्र 3-6 )।

यह सुनिश्चित करने के लिए कि संदेशों को 20 थ्रेड्स में समानांतर रूप से संसाधित किया गया है, आपको कम से कम 20 विभाजन की आवश्यकता है। यदि कम विभाजन होंगे, तो आपके पास अभी भी ऐसे उपभोक्ता होंगे जिनके पास काम करने के लिए कुछ भी नहीं है, जैसा कि पहले विशेष मॉनीटर की चर्चा में वर्णित है।

चित्र 3-6। उपभोक्ताओं के एक ही समूह में दो उपभोक्ता अलग-अलग विभाजन से पढ़ते हैं

यह योजना जेएमएस कतार का समर्थन करने के लिए आवश्यक संदेश वितरण की तुलना में काफ्का दलाल की जटिलता को काफी कम करती है। निम्नलिखित बातों का ध्यान रखने की आवश्यकता नहीं है:

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

काफ्का दलाल को जो कुछ भी करना चाहिए वह लगातार सलाहकार को संदेश भेजने के लिए होता है जब बाद वाले उनसे अनुरोध करते हैं।

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

संदेश भेजना

संदेश भेजने के लिए किस विभाजन को तय करने की जिम्मेदारी संदेश के निर्माता की है। उस तंत्र को समझने के लिए जिसके द्वारा यह किया जाता है, आपको सबसे पहले यह विचार करने की आवश्यकता है कि वास्तव में हम वास्तव में क्या भेज रहे हैं।

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

अध्याय 2 में, हमने ऑनलाइन सट्टेबाजी परिदृश्य पर चर्चा की, जब एक उपभोक्ता द्वारा संबंधित घटनाओं को संसाधित किया जाना चाहिए:

उपयोगकर्ता खाता कॉन्फ़िगर किया गया है।
खाते में पैसा जमा किया जाता है।
एक शर्त लगाई जाती है जो खाते से पैसे निकालती है।

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

यह इंटरफ़ेस इस प्रकार है:

interface Partitioner { int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster); }

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

अपनी विभाजन की रणनीति लिखना

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

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

 { "signature": "541661622185851c248b41bf0cea7ad0", "accountId": "10007865234" }

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

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

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

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

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

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

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

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

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

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

निर्माता समझौता

संदेश भेजते समय विभाजन केवल विचार करने की चीज नहीं है। आइए जावा एपीआई में निर्माता वर्ग के भेजें () तरीकों को देखें:

 Future < RecordMetadata > send(ProducerRecord < K, V > record); Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

 RecordMetadata metadata = producer.send(record).get();

एक बार फिर से संदेश पढ़ने के बारे में

संदेशों को पढ़ने में अतिरिक्त कठिनाइयाँ होती हैं जिन पर विचार करने की आवश्यकता होती है। जेएमएस एपीआई के विपरीत, जो एक संदेश के जवाब में एक संदेश श्रोता शुरू कर सकता है, उपभोक्ता काफ्का इंटरफ़ेस केवल मतदान करता है। आइए इस उद्देश्य के लिए इस्तेमाल की जाने वाली पोल () पद्धति पर एक करीब से नज़र डालें:

 ConsumerRecords < K, V > poll(long timeout);

विधि का वापसी मूल्य एक कंटेनर संरचना है जिसमें संभावित रूप से कई विभाजन से कई ConsumerRecord ऑब्जेक्ट होते हैं। एक ConsumerRecord अपने आप में संबंधित मेटाडेटा के साथ एक कुंजी-मूल्य जोड़ी के लिए एक धारक वस्तु है, जैसे कि वह विभाजन जिसमें से इसे प्राप्त किया गया है।

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

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

पहले से चर्चा किए गए रीडिंग मॉडल पर लौटते हुए, संदेश प्रसंस्करण में तीन चरण होते हैं:

पढ़ने के लिए एक संदेश प्राप्त करें।
संदेश को संसाधित करें।
संदेश की पुष्टि करें।

Kafka उपभोक्ता सलाहकार enable.auto.commit कॉन्फ़िगरेशन विकल्प के साथ आता है । यह आमतौर पर उपयोग की जाने वाली डिफ़ॉल्ट सेटिंग है, जैसा कि आमतौर पर "ऑटो" शब्द की सेटिंग के साथ होता है।

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

काफ्का 0.10 में, क्लाइंट कोड को इस तरह से बदल दिया गया था कि सेटिंग समय-समय पर क्लाइंट लाइब्रेरी द्वारा शुरू की गई थी, सेटिंग auto.commit.interval.ms के अनुसार। यह व्यवहार JMS AUTO_ACKNOWLEDGE और DUPS_OK_ACKNOWLEDGE मोड के बीच कहीं है। ऑटो-कमिट का उपयोग करते समय, संदेशों की पुष्टि की जा सकती है, चाहे वे वास्तव में संसाधित किए गए हों - यह धीमे उपभोक्ता के मामले में हो सकता है। यदि कंप्यूरेटर को बाधित किया गया था, तो एक सुरक्षित स्थिति से शुरू होने वाले, अगले कंप्यूरेटर द्वारा संदेशों को पुनर्प्राप्त किया गया था, जिससे संदेश स्किप हो सकता है। इस मामले में, काफ्का ने संदेश नहीं खोए, रीडिंग कोड ने उन्हें संसाधित नहीं किया।

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

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

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

आप काफ्का उपभोक्ता एपीआई में मैन्युअल रूप से ऑफसेट करने की प्रक्रिया को सक्षम करके कर सकते हैं। इसके लिए निम्नलिखित तरीकों में से एक को गलत और स्पष्ट रूप से कॉल करके enable.auto.commit करें:

 void commitSync(); void commitAsync();

यदि आप संदेश को "कम से कम एक बार" संसाधित करना चाहते हैं, तो आपको संदेशों को संसाधित करने के तुरंत बाद इस कमांड को निष्पादित करके मैन्युअल रूप से कम से कम प्रतिबद्धता () का उपयोग करना चाहिए।

ये तरीके संसाधित होने से पहले स्वीकृत संदेशों को संसाधित करने की अनुमति नहीं देते हैं, लेकिन वे संभावित प्रसंस्करण दोहराव को खत्म करने के लिए कुछ भी नहीं करते हैं, जबकि एक ही समय में लेन-देन की उपस्थिति का निर्माण करते हैं। काफ्का का कोई लेन-देन नहीं है। क्लाइंट के पास निम्न कार्य करने का अवसर नहीं है:

स्वचालित रूप से एक रोलबैक संदेश वापस रोल करें। उपभोक्ताओं को स्वयं समस्याग्रस्त पेलोड्स और बैकएंड डिस्कनेक्ट से उत्पन्न अपवादों को संभालना चाहिए, क्योंकि वे संदेशों को फिर से वितरित करने के लिए ब्रोकर पर भरोसा नहीं कर सकते हैं।
एक परमाणु संचालन के भीतर कई विषयों पर संदेश भेजें। जैसा कि हम जल्द ही देखेंगे, विभिन्न विषयों और विभाजनों पर नियंत्रण काफ्का क्लस्टर में विभिन्न मशीनों पर स्थित हो सकता है, जो भेजने पर लेनदेन का समन्वय नहीं करते हैं। इस लेखन के समय, KIP-98 के साथ इसे संभव बनाने के लिए कुछ काम किए गए हैं।
एक विषय से दूसरे संदेश को पढ़ने के साथ दूसरे संदेश को दूसरे विषय पर भेजने के लिए सहयोगी। फिर से, काफ्का की वास्तुकला एक बस के रूप में काम करने वाली कई स्वतंत्र मशीनों पर निर्भर करती है और इसे छिपाने का कोई प्रयास नहीं किया जाता है। उदाहरण के लिए, कोई एपीआई घटक नहीं है जो उपभोक्ता और निर्माता को लेन-देन में जोड़ने की अनुमति देगा। JMS में, यह सत्र ऑब्जेक्ट द्वारा प्रदान किया जाता है जिसमें से MessageProducers और MessageConsumers बनाए जाते हैं।

यदि हम लेन-देन पर भरोसा नहीं कर सकते हैं, तो हम पारंपरिक मैसेजिंग सिस्टम द्वारा प्रदान किए गए शब्दों के करीब कैसे शब्दार्थ प्रदान कर सकते हैं?

यदि इस बात की संभावना है कि ग्राहक की विफलता संदेश के संसाधित होने से पहले बढ़ सकती है, उदाहरण के लिए, ग्राहक की विफलता के दौरान, तो ग्राहक को यह जानने का कोई तरीका नहीं होगा कि क्या ग्राहकों का समूह विभाजन को असाइन किए जाने पर संदेश से चूक गया है। इस प्रकार, एक रणनीति ऑफसेट को पिछली स्थिति में वापस लाना है। काफ्का उपभोक्ता सलाहकार एपीआई इसके लिए निम्नलिखित तरीके प्रदान करता है:

 void seek(TopicPartition partition, long offset); void seekToBeginning(Collection < TopicPartition > partitions);

साधक () विधि का प्रयोग विधि के साथ किया जा सकता है
offsetsForTimes (मानचित्र <TopicPartition, Long> timestampsToSearch) अतीत में किसी विशेष बिंदु पर एक स्थिति में वापस लाने के लिए।

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

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

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

उच्च उपलब्धता

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

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

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

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

आधार मामले में, विषय निम्नलिखित गुणों के साथ काफ्का क्लस्टर में बनाया गया है:

विभाजन की संख्या। जैसा कि पहले चर्चा की गई थी, यहां इस्तेमाल किया गया सटीक मूल्य समवर्ती पढ़ने के वांछित स्तर पर निर्भर करता है।
प्रतिकृति गुणांक (कारक) निर्धारित करता है कि क्लस्टर में कितने ब्रोकर इंस्टेंसेस में इस विभाजन के लिए लॉग होना चाहिए।

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

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

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

निर्माता के कॉन्फ़िगरेशन का एक हिस्सा एक्यूक्स पैरामीटर है, जो निर्धारित करता है कि आवेदन की धारा भेजने से पहले कितने प्रतिकृतियों को संदेश की प्राप्ति को स्वीकार करना चाहिए: 0, 1 या सभी। यदि मान सभी के लिए सेट है, तो जब संदेश प्राप्त होता है, तो नेता जैसे ही min.insync.replicas विषय सेटिंग (डिफ़ॉल्ट रूप से 1) द्वारा परिभाषित कई प्रतिकृतियों (स्वयं सहित) से रिकॉर्ड की पुष्टि प्राप्त करता है, निर्माता को एक पुष्टिकरण भेज देगा। यदि संदेश सफलतापूर्वक दोहराया नहीं जा सकता है, तो निर्माता एप्लिकेशन ( NotEnoughReplicas या NotEnoughReplicasAfterAppend ) के लिए एक अपवाद फेंक देगा।

3 (1 , 2 ) min.insync.replicas 2. , , , , .

. (acknowledgments) . , , , , , ( ).

, Kafka sync () . , , , , 2, . Kafka , , — .
sync () , Kafka , . , (flushing) , . , Kafka 64 . , Kafka , .

Kafka sync () . Kafka , , . Kafka , , , zero-copy (, ). , .

Kafka , Kafka, .

, Kafka , , , . , , , . , , . , , , .

: tele.gg/middle_java

...

संदेश दलालों को समझना। ActiveMQ और Kafka के माध्यम से संदेश भेजने के यांत्रिकी सीखना। अध्याय 3. काफ्का