В अंतिम लेख हमने दोष सहनशीलता और उच्च उपलब्धता के लिए RabbitMQ क्लस्टरिंग को देखा। आइए अब अपाचे काफ्का के बारे में गहराई से जानें।

यहाँ प्रतिकृति की इकाई विभाजन है। प्रत्येक विषय में एक या अधिक अनुभाग होते हैं। प्रत्येक अनुभाग में अनुयायियों के साथ या उनके बिना एक नेता होता है। विषय बनाते समय, आप विभाजनों की संख्या और प्रतिकृति गुणांक निर्दिष्ट करते हैं। सामान्य मान 3 है, जिसका अर्थ है तीन प्रतिकृतियाँ: एक नेता और दो अनुयायी।

चावल। 1. चार अनुभाग तीन दलालों के बीच वितरित किए गए हैं

सभी पढ़ने और लिखने के अनुरोध नेता के पास जाते हैं। अनुयायी समय-समय पर नवीनतम संदेश प्राप्त करने के लिए नेता को अनुरोध भेजते हैं। उपभोक्ता कभी भी अनुयायियों की ओर नहीं मुड़ते; अनुयायी केवल अतिरेक और दोष सहनशीलता के लिए मौजूद होते हैं।

विभाजन विफलता

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

ब्रोकर 3 नेटवर्क छोड़ देता है, और ब्रोकर 2 में अनुभाग 2 के लिए एक नया नेता चुना जाता है।

चावल। 2. दलाल 3 की मृत्यु हो जाती है और दलाल 2 पर उसके अनुयायी को विभाजन 2 के नए नेता के रूप में चुना जाता है

फिर ब्रोकर 1 चला जाता है और सेक्शन 1 भी अपना नेता खो देता है, जिसकी भूमिका ब्रोकर 2 के पास चली जाती है।

चावल। 3. एक दलाल बचा है. सभी नेता शून्य अतिरेक के साथ एक ब्रोकर पर हैं

जब ब्रोकर 1 ऑनलाइन वापस आता है, तो यह चार अनुयायियों को जोड़ता है, प्रत्येक विभाजन को कुछ अतिरेक प्रदान करता है। लेकिन सभी नेता अभी भी ब्रोकर 2 पर ही बने हुए हैं.

चावल। 4. नेता दलाल पर रहते हैं 2

जब ब्रोकर 3 सामने आता है, तो हम प्रति विभाजन तीन प्रतिकृतियों पर वापस आ जाते हैं। लेकिन सभी नेता अभी भी दलाल 2 पर हैं.

चावल। 5. दलाल 1 और 3 की बहाली के बाद नेताओं की असंतुलित नियुक्ति

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

काफ्का के पास नेता की भूमिका के लिए "पसंदीदा प्रतिकृतियां" की अवधारणा है। जब विषय विभाजन बनाए जाते हैं, तो काफ्का नेताओं को नोड्स में समान रूप से वितरित करने का प्रयास करता है और उन पहले नेताओं को पसंदीदा के रूप में चिह्नित करता है। समय के साथ, सर्वर रीबूट, विफलताओं और कनेक्टिविटी ब्रेकडाउन के कारण, नेता अन्य नोड्स पर समाप्त हो सकते हैं, जैसा कि ऊपर वर्णित चरम मामले में है।

इसे ठीक करने के लिए, काफ्का दो विकल्प प्रदान करता है:

• विकल्प ऑटो.लीडर.रीबैलेंस.सक्षम = सत्य नियंत्रक नोड को स्वचालित रूप से नेताओं को पसंदीदा प्रतिकृतियों पर पुन: असाइन करने की अनुमति देता है और इस प्रकार समान वितरण बहाल करता है।
• व्यवस्थापक स्क्रिप्ट चला सकता है काफ्का-वरीयता-प्रतिकृति-चुनाव.श मैन्युअल पुन:असाइनमेंट के लिए.

चावल। 6. पुनर्संतुलन के बाद प्रतिकृतियां

यह विफलता का एक सरलीकृत संस्करण था, लेकिन वास्तविकता अधिक जटिल है, हालाँकि यहाँ कुछ भी जटिल नहीं है। यह सब सिंक्रनाइज़ प्रतिकृतियों (इन-सिंक रेप्लिका, आईएसआर) पर आता है।

सिंक्रनाइज़ प्रतिकृतियां (आईएसआर)

ISR एक विभाजन की प्रतिकृतियों का एक सेट है जिसे "सिंक्रोनाइज़्ड" (इन-सिंक) माना जाता है। नेता तो है, पर अनुयायी नहीं हो सकते। एक अनुयायी को सिंक्रनाइज़ माना जाता है यदि उसने अंतराल समाप्त होने से पहले सभी नेता के संदेशों की सटीक प्रतियां बनाई हैं प्रतिकृति.lag.time.max.ms.

एक अनुयायी को ISR सेट से हटा दिया जाता है यदि:

• अंतराल के लिए चयन करने का अनुरोध नहीं किया प्रतिकृति.lag.time.max.ms (परिकल्पित म्रत)
• अंतराल के दौरान अद्यतन करने का प्रबंधन नहीं किया प्रतिकृति.lag.time.max.ms (धीमा माना जाता है)

अनुयायी अंतराल में नमूनाकरण अनुरोध करते हैं प्रतिकृति.fetch.wait.max.ms, जो डिफ़ॉल्ट रूप से 500 एमएस है।

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

• acks=0, पुष्टिकरण नहीं भेजा गया है
• acks=1, नेता द्वारा अपने स्थानीय लॉग में एक संदेश लिखने के बाद पुष्टि भेजी जाती है
• acks=all, ISR में सभी प्रतिकृतियों द्वारा स्थानीय लॉग में संदेश लिखे जाने के बाद पुष्टि भेजी जाती है

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

अक्स=1 और आईएसआर

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

इस उदाहरण में, निर्माता का मान acks=1 है। यह अनुभाग सभी तीन दलालों में वितरित किया गया है। ब्रोकर 3 पीछे है, यह आठ सेकंड पहले लीडर के साथ सिंक्रोनाइज़ हुआ था और अब 7456 संदेश पीछे है। ब्रोकर 1 केवल एक सेकंड पीछे था। हमारा निर्माता एक संदेश भेजता है और तुरंत उसे वापस प्राप्त कर लेता है, बिना धीमे या मृत अनुयायियों के, जिसका नेता इंतजार नहीं कर रहा है।

चावल। 7. तीन प्रतिकृतियों के साथ आईएसआर

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

चावल। 8. क्रैश होने पर संदेश खो जाते हैं

विन्यास में बूटस्ट्रैप.सर्वर निर्माता के पास कई ब्रोकर सूचीबद्ध हैं और वह दूसरे ब्रोकर से पूछ सकता है कि नया सेक्शन लीडर कौन है। इसके बाद यह ब्रोकर 1 से कनेक्शन स्थापित करता है और संदेश भेजना जारी रखता है।

चावल। 9. थोड़े ब्रेक के बाद संदेश भेजना फिर से शुरू हो जाता है

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

चावल। 10. ब्रोकर 3 पर फॉलोअर को आईएसआर से हटा दिया गया है

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

चावल। 11. ब्रोकर 1 गिर जाता है. जब कोई विफलता होती है, तो बड़ी संख्या में संदेश खो जाते हैं

निर्माता अंतिम ब्रोकर के साथ संबंध स्थापित करता है और देखता है कि वह अब अनुभाग का नेता है। वह ब्रोकर 3 को संदेश भेजना शुरू कर देता है।

चावल। 12. एक छोटे से ब्रेक के बाद, संदेश फिर से सेक्शन 0 पर भेजे जाते हैं

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

अक्स = सभी और आईएसआर

आइए इस परिदृश्य को दोबारा दोहराएं, लेकिन साथ में अक्स=सभी. ब्रोकर 3 की औसत विलंबता चार सेकंड है। निर्माता इसके साथ एक संदेश भेजता है अक्स=सभी, और अब त्वरित प्रतिक्रिया नहीं मिलती है। नेता आईएसआर में सभी प्रतिकृतियों द्वारा संदेश के सहेजे जाने की प्रतीक्षा करता है।

चावल। 13. तीन प्रतिकृतियों के साथ आईएसआर। एक धीमा है, जिसके परिणामस्वरूप रिकॉर्डिंग में देरी होती है

चार सेकंड की अतिरिक्त देरी के बाद, ब्रोकर 2 एक रसीद भेजता है। सभी प्रतिकृतियाँ अब पूरी तरह से अद्यतन हैं।

चावल। 14. सभी प्रतिकृतियां संदेशों को सहेजती हैं और एके भेजती हैं

ब्रोकर 3 अब और पीछे हो गया है और आईएसआर से हटा दिया गया है। विलंबता काफ़ी कम हो गई है क्योंकि ISR में कोई धीमी प्रतिकृतियाँ नहीं बची हैं। ब्रोकर 2 अब केवल ब्रोकर 1 की प्रतीक्षा करता है, और उसका औसत अंतराल 500 एमएस है।

चावल। 15. ब्रोकर 3 की प्रतिकृति आईएसआर से हटा दी गई है

फिर ब्रोकर 2 गिर जाता है और नेतृत्व संदेश खोए बिना ब्रोकर 1 के पास चला जाता है।

चावल। 16. ब्रोकर 2 गिरता है

निर्माता एक नया नेता ढूंढता है और उसे संदेश भेजना शुरू कर देता है। विलंबता और भी कम हो गई है क्योंकि ISR में अब एक प्रतिकृति शामिल है! इसलिए विकल्प अक्स=सभी अतिरेक नहीं जोड़ता.

चावल। 17. ब्रोकर 1 पर प्रतिकृति संदेश खोए बिना बढ़त ले लेती है

फिर ब्रोकर 1 क्रैश हो जाता है और 3 संदेशों के नुकसान के साथ लीड ब्रोकर 14238 के पास चली जाती है!

चावल। 18. ब्रोकर 1 की मृत्यु हो जाती है और अशुद्ध सेटिंग के साथ नेतृत्व परिवर्तन के परिणामस्वरूप व्यापक डेटा हानि होती है

हम विकल्प स्थापित नहीं कर सके अशुद्ध.नेता.चुनाव.सक्षम अर्थ में <strong>उद्देश्य</strong>. डिफ़ॉल्ट रूप से यह बराबर है असत्य. समायोजन अक्स=सभी с अशुद्ध.नेता.चुनाव.सक्षम=सच्चा कुछ अतिरिक्त डेटा सुरक्षा के साथ पहुंच प्रदान करता है। लेकिन जैसा कि आप देख सकते हैं, हम अभी भी संदेश खो सकते हैं।

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

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

Acks=सभी, min.insync.replications और ISR

विषय विन्यास के साथ min.insync.प्रतिकृतियां हम डेटा सुरक्षा का स्तर बढ़ा रहे हैं. आइए पिछले परिदृश्य के अंतिम भाग को फिर से देखें, लेकिन इस बार साथ में min.insync.प्रतिकृतियां=2.

इसलिए ब्रोकर 2 में एक प्रतिकृति लीडर होता है और ब्रोकर 3 पर फॉलोअर को आईएसआर से हटा दिया जाता है।

चावल। 19. दो प्रतिकृतियों से ISR

ब्रोकर 2 गिर जाता है और नेतृत्व संदेश खोए बिना ब्रोकर 1 के पास चला जाता है। लेकिन अब ISR में केवल एक प्रतिकृति शामिल है। यह रिकॉर्ड प्राप्त करने के लिए न्यूनतम संख्या को पूरा नहीं करता है, और इसलिए ब्रोकर एक त्रुटि के साथ लिखने के प्रयास का जवाब देता है पर्याप्त प्रतिकृतियाँ नहीं.

चावल। 20. ISR की संख्या min.insync.replications में निर्दिष्ट संख्या से एक कम है

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

जब डेटा सुरक्षा के लिए पहुंच आवश्यक है

जैसा कि RabbitMQ के साथ मामला, कभी-कभी डेटा सुरक्षा के लिए पहुंच आवश्यक होती है। यहां आपको इस बारे में सोचने की आवश्यकता है:

• क्या प्रकाशक केवल एक त्रुटि लौटा सकता है और अपस्ट्रीम सेवा या उपयोगकर्ता को बाद में पुनः प्रयास करने को कह सकता है?
• क्या प्रकाशक बाद में पुनः प्रयास करने के लिए संदेश को स्थानीय रूप से या डेटाबेस में सहेज सकता है?

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

आईएसआर का मतलब

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

हम अर्थ स्वयं चुनते हैं प्रतिकृति.lag.time.max.ms आपकी आवश्यकताओं के अनुसार. मूलतः, इस पैरामीटर का मतलब है कि हम कब कितनी देरी स्वीकार करने को तैयार हैं अक्स=सभी. डिफ़ॉल्ट मान दस सेकंड है. यदि यह आपके लिए बहुत लंबा है, तो आप इसे कम कर सकते हैं। तब आईएसआर में परिवर्तन की आवृत्ति बढ़ जाएगी, क्योंकि अनुयायियों को हटा दिया जाएगा और अधिक बार जोड़ा जाएगा।

RabbitMQ केवल दर्पणों का एक सेट है जिसे दोहराने की आवश्यकता है। धीमे दर्पण अतिरिक्त विलंबता का परिचय देते हैं, और मृत दर्पण प्रतिक्रिया देने के लिए प्रत्येक नोड (नेट टिक) की उपलब्धता की जांच करने वाले पैकेट तक इंतजार कर सकते हैं। आईएसआर इन विलंबता मुद्दों से बचने का एक दिलचस्प तरीका है। लेकिन हम अतिरेक खोने का जोखिम उठाते हैं क्योंकि आईएसआर केवल नेता तक सीमित हो सकता है। इस जोखिम से बचने के लिए सेटिंग का उपयोग करें min.insync.प्रतिकृतियां.

ग्राहक कनेक्शन की गारंटी

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

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

काफ्का आम सहमति वास्तुकला

अब तक, हमने इस बात पर विचार नहीं किया है कि क्लस्टर को ब्रोकर के पतन के बारे में कैसे पता चलता है और एक नया नेता कैसे चुना जाता है। यह समझने के लिए कि काफ्का नेटवर्क विभाजन के साथ कैसे काम करता है, आपको सबसे पहले सर्वसम्मति वास्तुकला को समझने की आवश्यकता है।

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

ज़ूकीपर क्लस्टर की स्थिति को संग्रहीत करता है:

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

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

उदाहरण के लिए, आइए दस विभाजनों और 3 के प्रतिकृति कारक के साथ एक नया विषय लें। नियंत्रक को दलालों के बीच नेताओं को इष्टतम ढंग से वितरित करने का प्रयास करते हुए, प्रत्येक विभाजन के लिए एक नेता का चुनाव करना होगा।

प्रत्येक अनुभाग नियंत्रक के लिए:

• आईएसआर और लीडर के बारे में ज़ूकीपर में जानकारी अपडेट करता है;
• प्रत्येक ब्रोकर को एक लीडरएंडआईएसआरकमांड भेजता है जो इस विभाजन की प्रतिकृति को होस्ट करता है, जो ब्रोकरों को आईएसआर और लीडर के बारे में सूचित करता है।

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

प्रत्येक नेता आईएसआर की भर्ती के लिए जिम्मेदार है। समायोजन प्रतिकृति.lag.time.max.ms यह निर्धारित करता है कि वहां कौन प्रवेश करेगा। जब ISR बदलता है, तो लीडर ज़ुकीपर को नई जानकारी भेजता है।

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

चावल। 21. काफ्का सर्वसम्मति

प्रतिकृति प्रोटोकॉल

प्रतिकृति के विवरण को समझने से आपको संभावित डेटा हानि परिदृश्यों को बेहतर ढंग से समझने में मदद मिलती है।

नमूनाकरण क्वेरीज़, लॉग एंड ऑफ़सेट (LEO) और हाईवाटर मार्क (HW)

हमने माना कि अनुयायी समय-समय पर नेता को अनुरोध भेजते हैं। डिफ़ॉल्ट अंतराल 500ms है. यह RabbitMQ से भिन्न है क्योंकि RabbitMQ में प्रतिकृति कतार दर्पण द्वारा नहीं बल्कि मास्टर द्वारा शुरू की जाती है। मास्टर दर्पणों में परिवर्तन लाता है।

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

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

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

नेता की विफलता

जब कोई नेता गिरता है, तो ज़ूकीपर नियंत्रक को सूचित करता है, और वह एक नए नेता प्रतिकृति का चयन करता है। नया नेता अपने LEO के अनुसार एक नया HW चिह्न निर्धारित करता है। इसके बाद अनुयायियों को नए नेता के बारे में जानकारी प्राप्त होती है। काफ्का के संस्करण के आधार पर, अनुयायी दो परिदृश्यों में से एक का चयन करेगा:

1. यह स्थानीय लॉग को ज्ञात HW में छोटा कर देगा और इस चिह्न के बाद संदेशों के लिए नए लीडर को अनुरोध भेजेगा।
2. नेता को उस समय एचडब्ल्यू का पता लगाने के लिए एक अनुरोध भेजा जाएगा जब वह नेता चुना गया था, और फिर इस ऑफसेट के लिए लॉग को छोटा कर देगा। इसके बाद यह इस ऑफसेट से शुरू करके आवधिक फ़ेच अनुरोध करना शुरू कर देगा।

किसी अनुयायी को निम्नलिखित कारणों से लॉग को छोटा करने की आवश्यकता हो सकती है:

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

क्लस्टर के साथ पुनर्मिलन

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

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

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

कनेक्टिविटी का नुकसान

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

नीचे कई कनेक्टिविटी विफलता परिदृश्य हैं:

• परिदृश्य 1: अनुयायी नेता को नहीं देखता है, लेकिन फिर भी चिड़ियाघर संचालक को देखता है।
• परिदृश्य 2: नेता को कोई अनुयायी नहीं दिखता, लेकिन फिर भी वह ज़ूकीपर को देखता है।
• परिदृश्य 3: अनुयायी नेता को देखता है, लेकिन चिड़ियाघर संचालक को नहीं देखता है।
• परिदृश्य 4: नेता अनुयायियों को देखता है, लेकिन चिड़ियाघर संचालक को नहीं देखता है।
• परिदृश्य 5: अनुयायी अन्य काफ्का नोड्स और ज़ूकीपर दोनों से पूरी तरह से अलग है।
• परिदृश्य 6: लीडर अन्य काफ्का नोड्स और ज़ूकीपर दोनों से पूरी तरह से अलग है।
• परिदृश्य 7: काफ्का नियंत्रक नोड किसी अन्य काफ्का नोड को नहीं देख सकता।
• परिदृश्य 8: काफ्का नियंत्रक ज़ूकीपर को नहीं देखता है।

प्रत्येक परिदृश्य का अपना व्यवहार होता है।

परिदृश्य 1: अनुयायी नेता को नहीं देखता है, लेकिन फिर भी ज़ूकीपर को देखता है

चावल। 22. परिदृश्य 1: तीन प्रतिकृतियों का आईएसआर

कनेक्टिविटी विफलता ब्रोकर 3 को ब्रोकर 1 और 2 से अलग करती है, लेकिन ज़ूकीपर से नहीं। ब्रोकर 3 अब फ़ेच अनुरोध नहीं भेज सकता। समय बीत जाने के बाद प्रतिकृति.lag.time.max.ms इसे आईएसआर से हटा दिया गया है और यह संदेश प्रतिबद्धताओं में भाग नहीं लेता है। एक बार कनेक्टिविटी बहाल हो जाने पर, यह अनुरोध लाना फिर से शुरू कर देगा और लीडर से संपर्क होने पर आईएसआर में शामिल हो जाएगा। ज़ुकीपर को पिंग प्राप्त होते रहेंगे और यह मान लिया जाएगा कि ब्रोकर जीवित है और ठीक है।

चावल। 23. परिदृश्य 1: यदि ब्रोकर को प्रतिकृति.लैग.टाइम.मैक्स.एमएस अंतराल के भीतर कोई फ़ेच अनुरोध प्राप्त नहीं होता है तो उसे आईएसआर से हटा दिया जाता है।

RabbitMQ की तरह इसमें कोई स्प्लिट-ब्रेन या नोड सस्पेंशन नहीं है। इसके बजाय, अतिरेक कम हो जाता है।

परिदृश्य 2: नेता को कोई अनुयायी नहीं दिखता, लेकिन फिर भी वह ज़ूकीपर को देखता है

चावल। 24. परिदृश्य 2. नेता और दो अनुयायी

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

चावल। 25. परिदृश्य 2. आईएसआर केवल नेता तक सिमट कर रह गया है

परिदृश्य 3. अनुयायी नेता को देखता है, लेकिन चिड़ियाघर संचालक को नहीं देखता है

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

चावल। 26. परिदृश्य 3: अनुयायी नेता को लाने के अनुरोध भेजना जारी रखता है

परिदृश्य 4. नेता अनुयायियों को देखता है, लेकिन ज़ूकीपर को नहीं देखता है

चावल। 27. परिदृश्य 4. नेता और दो अनुयायी

नेता ज़ूकीपर से अलग हो गया है, लेकिन अनुयायियों वाले दलालों से नहीं।

चावल। 28. परिदृश्य 4: नेता को चिड़ियाघर संचालक से अलग कर दिया गया

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

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

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

चावल। 29. परिदृश्य 4. नेटवर्क बहाल होने के बाद ब्रोकर 1 पर लीडर अनुयायी बन जाता है

परिदृश्य 5: अनुयायी अन्य काफ्का नोड्स और ज़ूकीपर दोनों से पूरी तरह से अलग है

अनुयायी अन्य काफ्का नोड्स और ज़ुकीपर दोनों से पूरी तरह से अलग है। नेटवर्क बहाल होने तक वह बस खुद को आईएसआर से हटा लेता है, और फिर दूसरों के साथ जुड़ जाता है।

चावल। 30. परिदृश्य 5: पृथक अनुयायी को आईएसआर से हटा दिया गया है

परिदृश्य 6: लीडर अन्य काफ्का नोड्स और ज़ूकीपर दोनों से पूरी तरह से अलग है

चावल। 31. परिदृश्य 6. नेता और दो अनुयायी

नेता अपने अनुयायियों, नियंत्रक और ज़ूकीपर से पूरी तरह अलग-थलग है। अल्प अवधि के लिए यह प्रविष्टियाँ स्वीकार करना जारी रखेगा अक्स=1.

चावल। 32. परिदृश्य 6: नेता को अन्य काफ्का और ज़ूकीपर नोड्स से अलग करना

समाप्ति के बाद अनुरोध प्राप्त नहीं होना प्रतिकृति.lag.time.max.ms, यह ISR को अपने तक सिकोड़ने का प्रयास करेगा, लेकिन ऐसा करने में सक्षम नहीं होगा क्योंकि Zookeeper के साथ कोई संचार नहीं है, फिर यह लिखना स्वीकार करना बंद कर देगा।

इस बीच, ज़ूकीपर अलग-थलग ब्रोकर को मृत घोषित कर देगा और नियंत्रक एक नए नेता का चुनाव करेगा।

चावल। 33. परिदृश्य 6. दो नेता

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

चावल। 34. परिदृश्य 6: निर्माता एक नए नेता पर स्विच करते हैं

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

चावल। 35. परिदृश्य 6: नेटवर्क कनेक्टिविटी बहाल होने के बाद मूल नेता अनुयायी बन जाता है

इस स्थिति में, तार्किक अलगाव थोड़े समय के लिए हो सकता है, लेकिन केवल तभी अक्स=1 и min.insync.प्रतिकृतियां साथ ही 1. तार्किक पृथक्करण या तो नेटवर्क बहाल होने के बाद स्वचालित रूप से समाप्त हो जाता है, जब मूल नेता को पता चलता है कि वह अब नेता नहीं है, या जब सभी ग्राहकों को पता चलता है कि नेता बदल गया है और नए नेता को लिखना शुरू कर देता है - जो भी पहले हो। किसी भी स्थिति में, कुछ संदेश खो जायेंगे, लेकिन केवल साथ अक्स=1.

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

परिदृश्य 7: काफ्का नियंत्रक नोड दूसरे काफ्का नोड को नहीं देख सकता

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

परिदृश्य 8: काफ्का नियंत्रक ज़ूकीपर को नहीं देखता है

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

परिदृश्यों से निष्कर्ष

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

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

प्राचल min.insync.प्रतिकृतियां दो या दो से अधिक प्रतिकृतियों में अतिरिक्त आश्वासन मिलता है कि ऐसे अल्पकालिक परिदृश्यों के परिणामस्वरूप संदेश खो नहीं जाएंगे जैसा कि परिदृश्य 6 में है।

खोए हुए संदेशों का सारांश

आइए उन सभी तरीकों की सूची बनाएं जिनसे आप काफ्का में डेटा खो सकते हैं:

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

अशुद्ध नेतृत्व परिवर्तन को या तो प्रतिबंधित करके या कम से कम दो अतिरेक सुनिश्चित करके टाला जा सकता है। सबसे टिकाऊ विन्यास एक संयोजन है अक्स=सभी и min.insync.प्रतिकृतियां 1 से अधिक।

RabbitMQ और Kafka की विश्वसनीयता की सीधी तुलना

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

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

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

• हर कुछ सौ मिलीसेकंड में fsync
• दर्पण की विफलता केवल तभी देखी जा सकती है जब प्रत्येक नोड (नेट टिक) की उपलब्धता की जांच करने वाले पैकेट का जीवनकाल समाप्त हो गया हो। यदि दर्पण धीमा हो जाता है या गिर जाता है, तो इससे देरी हो जाती है।

काफ्का की शर्त यह है कि यदि एक संदेश को कई नोड्स में संग्रहीत किया जाता है, तो यह मेमोरी में प्रवेश करते ही संदेशों को स्वीकार कर सकता है। इसकी वजह से किसी भी प्रकार के संदेश खोने का खतरा रहता है (यहाँ तक कि) अक्स=सभी, min.insync.प्रतिकृतियां=2) एक साथ विफलता के मामले में।

कुल मिलाकर, काफ्का बेहतर सॉफ्टवेयर प्रदर्शन प्रदर्शित करता है और इसे क्लस्टर के लिए जमीनी स्तर से डिज़ाइन किया गया है। विश्वसनीयता के लिए आवश्यकता पड़ने पर फॉलोअर्स की संख्या 11 तक बढ़ाई जा सकती है। प्रतिकृति कारक 5 और सिंक्रनाइज़ेशन में प्रतिकृतियों की न्यूनतम संख्या min.insync.प्रतिकृतियां=3 संदेश हानि को एक बहुत ही दुर्लभ घटना बना देगा। यदि आपका बुनियादी ढांचा इस प्रतिकृति अनुपात और अतिरेक के स्तर का समर्थन कर सकता है, तो आप इस विकल्प को चुन सकते हैं।

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

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

अंत में, RabbitMQ और Kafka दोनों के क्लस्टरिंग और प्रतिकृति तंत्र में कई बग के बारे में मत भूलना। समय के साथ, सिस्टम अधिक परिपक्व और स्थिर हो गए हैं, लेकिन कोई भी संदेश कभी भी हानि से 100% सुरक्षित नहीं होगा! इसके अलावा, डेटा सेंटरों में बड़े पैमाने पर दुर्घटनाएँ होती हैं!

यदि मुझसे कुछ छूट गया है, कोई गलती हुई है, या आप किसी भी बिंदु से असहमत हैं, तो बेझिझक एक टिप्पणी लिखें या मुझसे संपर्क करें।

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

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

मैं अन्य तकनीकों को देखता हूं जिनमें इस विश्वसनीयता और गारंटीकृत ऑर्डर की कमी है, फिर मैं RabbitMQ और Kafka को देखता हूं और इन दोनों प्रणालियों के अविश्वसनीय मूल्य का एहसास करता हूं।

स्रोत: www.habr.com