कफका कैसे सच हुआ

नमस्कार, हेब्र!

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

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

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

गारंटी वितरण और अधिक

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

निर्माता और उपभोक्ता के लिए Client.id इसके साथ मदद करेगा। पहली नज़र में, आप मूल्य के रूप में एप्लिकेशन के नाम का उपयोग कर सकते हैं, और ज्यादातर मामलों में यह काम करेगा। हालाँकि स्थिति जब कई उपभोक्ता अनुप्रयोग में उपयोग किए जाते हैं और आप उन्हें एक ही क्लाइंट देते हैं। निम्नलिखित चेतावनी की ओर जाता है:

org.apache.kafka.common.utils.AppInfoParser — Error registering AppInfo mbean javax.management.InstanceAlreadyExistsException: kafka.consumer:type=app-info,id=kafka.test-0 

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

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

• 0 - स्वीकार नहीं माना जाएगा।
• 1 - डिफ़ॉल्ट पैरामीटर, स्वीकार केवल 1 प्रतिकृति से आवश्यक है।
• −1 - सभी सिंक्रनाइज़ प्रतिकृति ( min.insync.replicas क्लस्टर कॉन्फ़िगरेशन ) से स्वीकार आवश्यक है।

यह उपरोक्त मूल्यों से देखा जा सकता है कि cks1 के बराबर ऐक्स सबसे मजबूत गारंटी देता है कि संदेश खो नहीं जाएगा।

जैसा कि हम सभी जानते हैं, वितरित सिस्टम अविश्वसनीय हैं। अस्थायी खराबी से बचाने के लिए, काफ्का निर्माता एक रिट्रीज़ पैरामीटर प्रदान करता है जो आपको डिलीवरी के समय रिट्रीट प्रयासों की संख्या निर्धारित करने की अनुमति देता है। चूँकि पैरामीटर पैरामीटर Integer.MAX_VALUE (2147483647) के लिए डिफॉल्ट करता है, इसलिए केवल डिलीवरी.टाइमआउट.ms को बदलकर किसी संदेश के पुनर्प्राप्ति की संख्या को नियंत्रित किया जा सकता है।

बिल्कुल एक बार डिलीवरी की ओर बढ़ना

ये सेटिंग्स हमारे निर्माता को उच्च गारंटी के साथ संदेश देने की अनुमति देती हैं। आइए अब बात करते हैं कि काफ्का विषय में संदेश की केवल एक प्रति की रिकॉर्डिंग की गारंटी कैसे दें? सरलतम मामले में, निर्माता पर ऐसा करने के लिए, enable.idempotence पैरामीटर को सही पर सेट करें। Idempotency एक विषय के एक विशेष विभाजन में केवल एक संदेश की रिकॉर्डिंग की गारंटी देता है। बेरोजगारी को सक्षम करने के लिए एक शर्त है acks = सभी, पुनः प्रयास करें> 0, max.in.flight.requests.per.connection । 5 । यदि ये पैरामीटर डेवलपर द्वारा सेट नहीं किए गए हैं, तो उपरोक्त मान स्वचालित रूप से सेट हो जाएंगे।

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

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

इसके अलावा, पैरामीटर के साथ प्रमुख और idempotent भेजने का उपयोग करते हुए max.in.flight.requests.per.connection = 1 आपको उपभोक्ता पर संदेशों का एक व्यवस्थित प्रसंस्करण देता है। अलग-अलग, यह याद रखने योग्य है कि यदि आपके क्लस्टर पर एक्सेस कंट्रोल कॉन्फ़िगर किया गया है, तो आपको विषय पर लिखने के लिए अधिकारों की आवश्यकता होगी।

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

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

 org.apache.kafka.common.errors.ProducerFencedException: Producer attempted an operation with an old epoch. Either there is a newer producer with the same transactionalId, or the producer's transaction has been expired by the broker. 

इस समस्या को हल करने के लिए, हम होस्ट नाम के रूप में एप्लिकेशन नाम में एक प्रत्यय जोड़ते हैं, जो पर्यावरण चर से प्राप्त होता है।

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

ऐसे संदेशों को उपभोक्ता द्वारा समय से पहले पढ़ने से रोकने के लिए, उसे read_committed के लिए आइसोलेशन.वेल पैरामीटर सेट करना होगा। ऐसा कंज्यूमर पहले की तरह नॉन-ट्रांजेक्शनल मैसेज को पढ़ सकेगा और कमिटमेंट के बाद ही ट्रांजैक्शन कर सकेगा।
यदि आपने ऊपर सूचीबद्ध सभी सेटिंग्स स्थापित की हैं, तो आपने डिलीवरी के ठीक एक बार कॉन्फ़िगर किया है। बधाई!

लेकिन एक और अति सूक्ष्म अंतर है। Transactional.id, जिसे हमने ऊपर कॉन्फ़िगर किया था, वास्तव में एक लेनदेन उपसर्ग है। लेन-देन प्रबंधक पर, एक सीरियल नंबर इसमें जोड़ा जाता है। प्राप्त पहचानकर्ता को transactional.id.expiration.ms पर जारी किया जाता है , जो काफ्का क्लस्टर पर कॉन्फ़िगर किया गया है और "7 दिन" का डिफ़ॉल्ट मान है। यदि इस समय के दौरान एप्लिकेशन को कोई संदेश प्राप्त नहीं हुआ, तो जब आप अगले ट्रांजेक्शनल भेजने की कोशिश करते हैं, तो आपको एक InvalidPidMappingException प्राप्त होगी। उसके बाद, लेन-देन समन्वयक अगले लेनदेन के लिए एक नया अनुक्रम नंबर जारी करेगा। हालाँकि, यदि InvalidPidMappingException ठीक से संसाधित नहीं किया गया है, तो संदेश खो सकता है।

बजाय योग के

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

निर्माता:

1. एके = सभी
2. रिट्रीट> 0
3. enable.idempotence = सत्य
4. max.in.flight.requests.per.connection 1 5 (1 - अर्दली भेजने के लिए)
5. transactional.id = $ {एप्लिकेशन-नाम} - $ {hostname}

उपभोक्ता:

1. आइसोलेशन.लेवल = read_committed

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

और यहाँ स्वतंत्र अध्ययन के लिए कुछ सामग्रियां हैं:

• KIP-98 - बिल्कुल एक बार वितरण और लेनदेन संदेश
• सेटिंग्स का विवरण