काफ्का कैसे हकीकत बन गया

हे हबर!

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

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

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

गारंटीशुदा डिलीवरी और भी बहुत कुछ

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

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

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

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

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

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

सूचीबद्ध मूल्यों से यह स्पष्ट है कि -1 के बराबर एसीएस सबसे मजबूत गारंटी देता है कि संदेश खो नहीं जाएगा।

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

हम बिल्कुल एक बार डिलीवरी की ओर बढ़ रहे हैं

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

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

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

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

यदि अचानक आपके पास कुंजी द्वारा भेजने की क्षमताओं की कमी है या निर्माता पक्ष के तर्क को विभिन्न विभाजनों के बीच डेटा स्थिरता बनाए रखने की आवश्यकता है, तो लेनदेन बचाव में आएगा। इसके अलावा, एक श्रृंखला लेनदेन का उपयोग करके, आप काफ्का में एक रिकॉर्ड को सशर्त रूप से सिंक्रनाइज़ कर सकते हैं, उदाहरण के लिए, डेटाबेस में एक रिकॉर्ड के साथ। निर्माता को लेन-देन भेजने में सक्षम बनाने के लिए, इसे निष्क्रिय और अतिरिक्त रूप से सेट किया जाना चाहिए transactional.id. यदि आपके काफ्का क्लस्टर में एक्सेस कंट्रोल कॉन्फ़िगर किया गया है, तो एक ट्रांजेक्शनल रिकॉर्ड, एक आइडेम्पोटेंट रिकॉर्ड की तरह, लिखने की अनुमति की आवश्यकता होगी, जिसे 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 दिन" है। यदि इस दौरान एप्लिकेशन को कोई संदेश प्राप्त नहीं हुआ है, तो जब आप प्रयास करेंगे तो अगला ट्रांजेक्शनल संदेश आपको प्राप्त होगा अमान्यPidMappingException. इसके बाद लेनदेन समन्वयक अगले लेनदेन के लिए एक नया अनुक्रम संख्या जारी करेगा। हालाँकि, यदि InvalidPidMappingException को सही ढंग से प्रबंधित नहीं किया जाता है, तो संदेश खो सकता है।

योग के बजाय

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

निर्माता:

1. अक्स = सभी
2. पुनः प्रयास करें > 0
3. Enable.idempotence = सत्य
4. max.in.flight.requests.per.connection ≤ 5 (व्यवस्थित भेजने के लिए 1)
5. transactional.id = ${एप्लिकेशन-नाम}-${होस्टनाम}

उपभोक्ता:

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

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

यहां स्व-अध्ययन के लिए कुछ सामग्रियां दी गई हैं:

• केआईपी-98 - बिल्कुल एक बार डिलीवरी और लेनदेन संबंधी संदेश
• सेटिंग्स का विवरण

स्रोत: www.habr.com