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

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

अंजीर। 1. चार वर्गों को तीन दलालों के बीच वितरित किया जाता है

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

धारा विफल रही

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

ब्रोकर 3 नेटवर्क छोड़ देता है - और धारा 2 के लिए ब्रोकर 2 पर एक नया नेता चुना जाता है।

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

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

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

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

अंजीर। 4. नेता दलाल 2 पर बने रहते हैं

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

अंजीर। 5. दलालों 1 और 3 की बहाली के बाद नेताओं का असंतुलित प्लेसमेंट

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

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

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

Auto.leader.rebalance.enable = true विकल्प नियंत्रक नोड को स्वचालित रूप से नेताओं को पसंदीदा प्रतिकृतियों में वापस करने की अनुमति देता है और जिससे समान वितरण को पुनर्स्थापित करता है।
कोई व्यवस्थापक मैन्युअल रूप से पुन: असाइन करने के लिए kafka-preferred-replica-election.sh स्क्रिप्ट चला सकता है।

अंजीर। 6. पुन: संतुलन के बाद प्रतिकृतियां

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

समन्वित प्रतिकृतियां (ISR)

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

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

अंतराल प्रतिकृति के लिए नमूने के लिए अनुरोध नहीं किया था। lag.time.max.ms (मृत माना जाता है)
अंतराल प्रतिकृति के लिए अद्यतन करने का समय नहीं था। lag.time.max.ms (धीमा माना जाता है)

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

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

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

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

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

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

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

अंजीर। 7. तीन प्रतिकृतियों के साथ ISR

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

अंजीर। 8. असफल होने पर, संदेश खो जाते हैं

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

अंजीर। 9. संदेश भेजना एक छोटे से ब्रेक के बाद फिर से शुरू होता है

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

अंजीर। 10. ब्रोकर 3 पर फॉलोअर को ISR से हटा दिया जाता है

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

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

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

अंजीर। 12. एक संक्षिप्त विराम के बाद, संदेश फिर से अनुभाग 0 में भेजे जाते हैं

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

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

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

अंजीर। 13. तीन प्रतिकृतियों के साथ ISR। एक धीमी है, जिससे रिकॉर्डिंग में देरी हो रही है

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

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

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

अंजीर। 15. दलाल 3 पर प्रतिकृति ISR से हटा दी जाती है

तब ब्रोकर 2 गिरता है, और लीडर मैसेज खोए बिना ब्रोकर 1 को पास करता है।

अंजीर। 16. ब्रोकर 2 गिर रहा है

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

अंजीर। 17. ब्रोकर 1 पर प्रतिकृति संदेशों को खोए बिना लीड लेता है

तब ब्रोकर 1 गिरता है, और लीडर ब्रोकर 3 को 14,238 संदेशों के नुकसान के साथ पास करता है!

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

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

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

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

अक्स = सभी, min.insync.replicas और ISR

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

तो, ब्रोकर 2 में एक प्रतिकृति नेता है, और ब्रोकर 3 पर अनुयायी को ISR से हटा दिया जाता है।

अंजीर। 19. दो प्रतिकृतियों का ISR

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

अंजीर। 20. ISR की संख्या min.insync.replicas में निर्दिष्ट की तुलना में एक कम है

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

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

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

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

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

ISR का अर्थ

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

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

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

ग्राहक कनेक्टिविटी की गारंटी

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

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

काफ्का सर्वसम्मति वास्तुकला

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

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

Zookeeper स्टोर क्लस्टर स्थिति:

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

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

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

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

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

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

प्रत्येक नेता ISRs की भर्ती के लिए जिम्मेदार है। प्रतिकृति । Lag.time.max.ms सेटिंग निर्धारित करती है कि कौन वहां जाएगा। जब ISR बदलता है, तो नेता Zookeeper को नई जानकारी देता है।

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

अंजीर। 21. काफ्का की सहमति

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

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

नमूना अनुरोध, लॉग ऑफ़ ऑफ़सेट (LEO) और हाईवाच मार्क (HW)

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

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

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

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

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

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

प्रसिद्ध एचजी को स्थानीय लॉग ट्रंकट करता है और इस निशान के बाद नए नेता को एक संदेश भेजता है।
, HW , . , .

, ISR, Zookeeper, . ISR, «», . , . Kafka , . , , HW . , acks=all .
. , . , , , , , .

c

, : HW ( ). , RabbitMQ . . , « ». . .

Kafka — , , RabbitMQ, . . Kafka — , . . Kafka HW ( ) , . , , , LEO.

ISR . , , , ISR. .

Kafka , RabbitMQ, , . Kafka , .

:

1. , Zookeeper.
2. , Zookeeper.
3. , Zookeeper.
4. , Zookeeper.
5. Kafka, Zookeeper.
6. Kafka, Zookeeper.
7. Kafka Kafka.
8. Kafka Zookeeper.

1. , Zookeeper

. 22. 1. ISR

3 1 2, Zookeeper. 3 . replica.lag.time.max.ms ISR . , ISR, . Zookeeper , .

. 23. 1. ISR, replica.lag.time.max.ms

(split-brain) , RabbitMQ. .

2. , Zookeeper

. 24. 2.

, Zookeeper. , ISR , , . , . , . Zookeeper , .

. 25. 2. ISR

3. , Zookeeper

Zookeeper, . ISR. Zookeeper , , .

. 26. 3.

4. , Zookeeper

. 27. 4.

Zookeeper, .

. 28. 4. Zookeeper

Zookeeper . . , acks=1 . , ISR . Zookeeper, , .

acks=all , ISR , . ISR, - .

. , , , HW, , . . , . , , .

. 29. 4. 1

5. Kafka, Zookeeper

Kafka, Zookeeper. ISR, , .

. 30. 5. ISR

6. Kafka, Zookeeper

. 31. 6.

, Zookeeper. acks=1 .

. 32. 6. Kafka Zookeeper

replica.lag.time.max.ms , ISR , , Zookeeper, .

, Zookeeper , .

. 33. 6.

, . 60 . .

. 34. 6.

, . , Zookeeper , . HW .

. 35. 6.

, acks=1 min.insync.replicas 1. , , , , — , . , acks=1 .

, , ISR . - . , , acks=all , ISR . . — min.insync.replicas = 2 .

7. Kafka Kafka

, Kafka . , 6. .

8. Kafka Zookeeper

Zookeeper Kafka. , Zookeeper, . , , , Kafka.

, , , . , , , .

- Zookeeper, acks=1 . Zookeeper . acks=all .

min.insync.replicas , , 6.

, Kafka:

, acks=1
(unclean) , ISR, acks=all
Zookeeper, acks=1
, ISR . , acks=all . , min.insync.replicas=1 .
. , . .

, , . — acks=all min.insync.replicas 1.

RabbitMQ Kafka

. RabbitMQ . , . RabbitMQ. , . . , ( ) .

Kafka . . . , . , , . , - , . , .

RabbitMQ Kafka . , RabbitMQ . :

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

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

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

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

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

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

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

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

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

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

RabbitMQ बनाम काफ्का: विफलता और उच्च उपलब्धता