संदेश दलालों को समझना। एक्टिवएमक्यू और काफ्का के साथ मैसेजिंग के यांत्रिकी सीखना। अध्याय 3. काफ्का

एक छोटी सी किताब के अनुवाद की निरंतरता:
संदेश दलालों को समझना
लेखक: जैकब कोरब, प्रकाशक: ओ'रेली मीडिया, इंक।, प्रकाशन की तिथि: जून 2017, आईएसबीएन: 9781492049296।

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

अध्याय 3

काफ्का

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

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

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

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

एकीकृत गंतव्य मॉडल

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

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

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

शब्द "लॉग" और "पॉइंटर" दिखाई नहीं देते हैं काफ्का दस्तावेज़ीकरण. इन सुप्रसिद्ध शब्दों का उपयोग यहां समझने में सहायता के लिए किया जाता है।

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

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

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

संदेश पढ़ना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

विभाजन

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

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

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

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

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

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

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

काफ्का ब्रोकर को बस उपभोक्ता के अनुरोध करने पर उसे क्रमिक रूप से संदेश भेजना होता है।

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

संदेश भेजा जा रहा है

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

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

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

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

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

यह इंटरफ़ेस इस तरह दिखता है:

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

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

अपनी स्वयं की विभाजन रणनीति लिखना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

संदेश पढ़ने के बारे में अधिक जानकारी

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

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

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

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

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

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

1. पढ़ने के लिए एक संदेश पुनः प्राप्त करें.
2. संदेश को संसाधित करें.
3. संदेश की पुष्टि करें.

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

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

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

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

जैसा कि पृष्ठ 21 पर "कतार से संदेश पढ़ना" में चर्चा की गई है, जब विफलता मोड को ध्यान में रखा जाता है तो मैसेजिंग सिस्टम में संदेश की एक बार डिलीवरी जैसी कोई चीज नहीं होती है।

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

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

void commitSync();
void commitAsync();

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

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

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

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

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

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

विधि पाना() तरीके से इस्तेमाल किया जा सकता है
ऑफसेट्सफॉरटाइम्स(मानचित्र खोजने के लिए टाइमस्टैम्प) अतीत में किसी विशिष्ट बिंदु पर किसी स्थिति में वापस आना।

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

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

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

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

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

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

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

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

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

• विभाजनों की संख्या. जैसा कि पहले चर्चा की गई है, यहां उपयोग किया गया सटीक मान समानांतर रीडिंग के वांछित स्तर पर निर्भर करता है।
• प्रतिकृति कारक (कारक) यह निर्धारित करता है कि क्लस्टर में कितने ब्रोकर इंस्टेंस में इस विभाजन के लिए लॉग होने चाहिए।

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

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

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

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

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

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

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

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

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

परिणाम

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

पिछला अनुवादित भाग: संदेश दलालों को समझना। एक्टिवएमक्यू और काफ्का के साथ मैसेजिंग के यांत्रिकी सीखना। अध्याय 1

अनुवाद किया गया: टेली.जीजी/मध्य_जावा

को जारी रखा जाएगा ...

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

क्या आपके संगठन में काफ्का का उपयोग किया जाता है?

• Да

• नहीं

• पहले इस्तेमाल होता था, अब नहीं

• हम प्रयोग करने की योजना बना रहे हैं

38 उपयोगकर्ताओं ने मतदान किया। 8 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com