В शेवटचा लेख दोष सहिष्णुता आणि उच्च उपलब्धतेसाठी आम्ही RabbitMQ क्लस्टरिंगकडे पाहिले. आता अपाचे काफ्कामध्ये खोलवर जाऊया.

येथे प्रतिकृतीचे एकक विभाजन आहे. प्रत्येक विषयामध्ये एक किंवा अधिक विभाग असतात. प्रत्येक विभागात अनुयायांसह किंवा नसलेला नेता असतो. विषय तयार करताना, तुम्ही विभाजनांची संख्या आणि प्रतिकृती गुणांक निर्दिष्ट करता. नेहमीचे मूल्य 3 आहे, म्हणजे तीन प्रतिकृती: एक नेता आणि दोन अनुयायी.

तांदूळ. 1. तीन दलालांमध्ये चार विभाग वितरीत केले जातात

सर्व वाचा आणि लिहा विनंत्या नेत्याकडे जातात. अनुयायी वेळोवेळी नेत्याला नवीनतम संदेश प्राप्त करण्यासाठी विनंत्या पाठवतात. ग्राहक कधीही अनुयायांकडे वळत नाहीत; नंतरचे केवळ अनावश्यकता आणि दोष सहिष्णुतेसाठी अस्तित्वात आहेत.

विभाजन अयशस्वी

जेव्हा एखादा दलाल अपयशी ठरतो तेव्हा अनेक विभागांचे नेते अपयशी ठरतात. त्या प्रत्येकामध्ये, दुसर्‍या नोडचा अनुयायी नेता बनतो. खरं तर, हे नेहमीच होत नाही, कारण सिंक्रोनाइझेशन घटक देखील प्रभावित करतो: सिंक्रोनाइझ केलेले अनुयायी आहेत की नाही, आणि नसल्यास, नंतर असंकालिक न केलेल्या प्रतिकृतीवर स्विच करण्याची परवानगी आहे की नाही. पण आत्तासाठी गोष्टी गुंतागुंती करू नका.

ब्रोकर 3 ने नेटवर्क सोडले, आणि ब्रोकर 2 येथे सेक्शन 2 साठी नवीन नेता निवडला जातो.

तांदूळ. 2. ब्रोकर 3 मरण पावला आणि दलाल 2 वर त्याचा अनुयायी विभाजन 2 चा नवीन नेता म्हणून निवडला गेला

मग ब्रोकर 1 सोडतो आणि कलम 1 देखील त्याचा नेता गमावतो, ज्याची भूमिका ब्रोकर 2 कडे जाते.

तांदूळ. 3. एक दलाल शिल्लक आहे. शून्य रिडंडंसीसह सर्व नेते एकाच दलालावर आहेत

जेव्हा ब्रोकर 1 पुन्हा ऑनलाइन येतो, तेव्हा ते चार फॉलोअर्स जोडते, प्रत्येक विभाजनाला काही रिडंडंसी प्रदान करते. पण तरीही सर्व नेते दलाल २ वरच राहिले.

तांदूळ. 4. नेते दलाल 2 वर राहतात

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

तांदूळ. 5. दलाल 1 आणि 3 च्या पुनर्स्थापनेनंतर नेत्यांची असंतुलित नियुक्ती

काफ्काकडे RabbitMQ पेक्षा चांगले नेते पुनर्संतुलनाचे साधन आहे. तेथे, तुम्हाला तृतीय-पक्ष प्लगइन किंवा स्क्रिप्ट वापरावे लागले ज्याने स्थलांतर करताना रिडंडन्सी कमी करून मास्टर नोड स्थलांतरित करण्यासाठी धोरणे बदलली. याव्यतिरिक्त, मोठ्या रांगांसाठी आम्हाला सिंक्रोनाइझेशन दरम्यान अनुपलब्धता स्वीकारावी लागली.

नेत्याच्या भूमिकेसाठी काफ्काची "प्राधान्य प्रतिकृती" ही संकल्पना आहे. जेव्हा विषय विभाजने तयार केली जातात, तेव्हा काफ्का नोड्समध्ये समान रीतीने नेत्यांचे वितरण करण्याचा प्रयत्न करतो आणि त्या पहिल्या नेत्यांना प्राधान्य म्हणून चिन्हांकित करतो. कालांतराने, सर्व्हर रीबूट, अयशस्वी आणि कनेक्टिव्हिटी ब्रेकडाउनमुळे, वर वर्णन केल्याप्रमाणे, नेते इतर नोड्सवर येऊ शकतात.

याचे निराकरण करण्यासाठी, काफ्का दोन पर्याय ऑफर करतो:

• पर्याय auto.leader.rebalance.enable=true कंट्रोलर नोडला आपोआप लीडर्सना पसंतीच्या प्रतिकृतींवर परत नियुक्त करण्याची आणि त्याद्वारे एकसमान वितरण पुनर्संचयित करण्याची अनुमती देते.
• प्रशासक स्क्रिप्ट चालवू शकतो kafka-preferred-replica-election.sh मॅन्युअल पुनर्नियुक्तीसाठी.

तांदूळ. 6. पुनर्संतुलनानंतर प्रतिकृती

ही अपयशाची एक सरलीकृत आवृत्ती होती, परंतु वास्तविकता अधिक जटिल आहे, जरी येथे काहीही क्लिष्ट नाही. हे सर्व सिंक्रोनाइझ केलेल्या प्रतिकृतींवर येते (इन-सिंक प्रतिकृती, ISR).

सिंक्रोनाइझ प्रतिकृती (ISR)

ISR हा विभाजनाच्या प्रतिकृतींचा एक संच आहे ज्याला "सिंक्रोनाइझ" (इन-सिंक) मानले जाते. नेता आहे, पण अनुयायी नसू शकतात. जर अनुयायीने मध्यांतर संपण्यापूर्वी सर्व नेत्याच्या संदेशांच्या अचूक प्रती तयार केल्या असतील तर तो समक्रमित मानला जातो. replica.lag.time.max.ms.

फॉलोअरला ISR सेटमधून काढून टाकले जाते जर ते:

• मध्यांतरासाठी निवड करण्याची विनंती केली नाही replica.lag.time.max.ms (मृत गृहीत)
• मध्यांतर दरम्यान अद्यतनित करण्यात व्यवस्थापित केले नाही replica.lag.time.max.ms (धीमे मानले जाते)

अनुयायी मध्यांतरात नमुना विनंत्या करतात replica.fetch.wait.max.ms, जे डीफॉल्ट 500ms आहे.

ISR चा उद्देश स्पष्टपणे स्पष्ट करण्यासाठी, आम्हाला निर्मात्याकडून पुष्टीकरणे आणि काही अपयशी परिस्थिती पाहणे आवश्यक आहे. ब्रोकर पुष्टीकरण पाठवतो तेव्हा उत्पादक निवडू शकतात:

• acks=0, पुष्टीकरण पाठवले जात नाही
• acks=1, नेत्याने त्याच्या स्थानिक लॉगवर संदेश लिहिल्यानंतर पुष्टीकरण पाठवले जाते
• acks=all, ISR मधील सर्व प्रतिकृतींनी स्थानिक लॉगवर संदेश लिहिल्यानंतर पुष्टीकरण पाठवले जाते

काफ्का शब्दावलीत, जर ISR ने संदेश जतन केला असेल तर तो "किटेड" आहे. Acks=all हा सर्वात सुरक्षित पर्याय आहे, परंतु अतिरिक्त विलंब देखील जोडतो. दोन अयशस्वी उदाहरणे पाहू आणि विविध 'अॅक्स' पर्याय ISR संकल्पनेशी कसा संवाद साधतात.

Acks=1 आणि ISR

या उदाहरणात, आपण पाहणार आहोत की जर नेत्याने सर्व अनुयायांकडून येणारा प्रत्येक संदेश जतन होण्याची प्रतीक्षा केली नाही, तर नेता अयशस्वी झाल्यास डेटा गमावणे शक्य आहे. सिंक न केलेल्या अनुयायाकडे नेव्हिगेट करणे सेटिंगद्वारे सक्षम किंवा अक्षम केले जाऊ शकते unclean.leader.election.enable.

या उदाहरणात, निर्मात्याकडे acks=1 मूल्य आहे. विभाग सर्व तीन दलालांमध्ये वितरीत केला जातो. ब्रोकर 3 मागे आहे, तो आठ सेकंदांपूर्वी लीडरशी सिंक्रोनाइझ झाला आहे आणि आता 7456 संदेश मागे आहे. ब्रोकर 1 फक्त एक सेकंद मागे होता. आमचा निर्माता संदेश पाठवतो आणि त्वरीत एक ack प्राप्त करतो, ज्याची नेता वाट पाहत नाही अशा मंद किंवा मृत अनुयायांच्या ओव्हरहेडशिवाय.

तांदूळ. 7. तीन प्रतिकृती असलेले ISR

ब्रोकर 2 अयशस्वी झाला आणि निर्मात्याला कनेक्शन त्रुटी प्राप्त झाली. नेतृत्व ब्रोकर 1 कडे गेल्यानंतर, आम्ही 123 संदेश गमावतो. ब्रोकर 1 वरील फॉलोअर हा ISR चा भाग होता, परंतु तो पडला तेव्हा लीडरशी पूर्णपणे सिंक्रोनाइझ झाला नव्हता.

तांदूळ. 8. तो क्रॅश झाल्यावर संदेश गमावले जातात

कॉन्फिगरेशनमध्ये bootstrap.servers निर्मात्याकडे अनेक ब्रोकर सूचीबद्ध आहेत आणि ते नवीन विभाग प्रमुख असलेल्या दुसर्‍या ब्रोकरला विचारू शकतात. ते नंतर ब्रोकर 1 शी कनेक्शन स्थापित करते आणि संदेश पाठवणे सुरू ठेवते.

तांदूळ. 9. थोड्या विश्रांतीनंतर संदेश पाठवणे पुन्हा सुरू होते

ब्रोकर 3 आणखी मागे आहे. ते विनंत्या आणते परंतु समक्रमित करू शकत नाही. ब्रोकर्समधील संथ नेटवर्क कनेक्शन, स्टोरेज समस्या इत्यादीमुळे हे असू शकते. ते ISR मधून काढून टाकले आहे. आता ISR मध्ये एक प्रतिकृती आहे - नेता! निर्माता संदेश पाठवणे आणि पुष्टीकरणे प्राप्त करणे सुरू ठेवतो.

तांदूळ. 10. ब्रोकर 3 वरील फॉलोअर ISR मधून काढून टाकला जातो

ब्रोकर 1 खाली जातो आणि 3 मेसेजेस गमावून लीडरशिप रोल ब्रोकर 15286 कडे जातो! निर्मात्यास कनेक्शन त्रुटी संदेश प्राप्त होतो. ISR बाहेरील नेत्याचे संक्रमण केवळ सेटिंगमुळेच शक्य झाले unclean.leader.election.enable=true. मध्ये स्थापित केले असल्यास खोटे, नंतर संक्रमण होणार नाही आणि सर्व वाचन आणि लेखन विनंत्या नाकारल्या जातील. या प्रकरणात, आम्ही ब्रोकर 1 च्या प्रतिकृतीमध्ये त्याच्या अखंड डेटासह परत येण्याची वाट पाहतो, जो पुन्हा नेतृत्व घेईल.

तांदूळ. 11. ब्रोकर 1 पडतो. जेव्हा अपयश येते तेव्हा मोठ्या संख्येने संदेश गमावले जातात

निर्माता शेवटच्या ब्रोकरशी संबंध स्थापित करतो आणि पाहतो की तो आता विभागाचा नेता आहे. तो ब्रोकर 3 ला मेसेज पाठवू लागतो.

तांदूळ. 12. थोड्या विश्रांतीनंतर, विभाग 0 वर संदेश पुन्हा पाठवले जातात

आम्ही पाहिले की, नवीन कनेक्शन स्थापित करण्यासाठी आणि नवीन नेता शोधण्यासाठी लहान व्यत्यय व्यतिरिक्त, निर्माता सतत संदेश पाठवत होता. हे कॉन्फिगरेशन सातत्य (डेटा सुरक्षा) च्या खर्चावर उपलब्धता सुनिश्चित करते. काफ्काने हजारो संदेश गमावले पण नवीन लेखन स्वीकारणे सुरूच ठेवले.

Acks = सर्व आणि ISR

चला या परिस्थितीची पुनरावृत्ती करूया, परंतु सह acks = सर्व. ब्रोकर 3 ची सरासरी विलंबता चार सेकंद आहे. निर्माता यासह एक संदेश पाठवतो acks = सर्व, आणि आता द्रुत प्रतिसाद मिळत नाही. ISR मधील सर्व प्रतिकृतींद्वारे संदेश जतन होण्याची नेता वाट पाहतो.

तांदूळ. 13. तीन प्रतिकृती असलेले ISR. एक मंद आहे, परिणामी रेकॉर्डिंग विलंब होतो

चार सेकंदांच्या अतिरिक्त विलंबानंतर, ब्रोकर 2 एक ack पाठवतो. सर्व प्रतिकृती आता पूर्णपणे अद्यतनित केल्या आहेत.

तांदूळ. 14. सर्व प्रतिकृती संदेश जतन करतात आणि ack पाठवतात

ब्रोकर 3 आता आणखी मागे पडला आहे आणि ISR मधून काढून टाकला आहे. ISR मध्ये कोणतीही धीमी प्रतिकृती शिल्लक नसल्यामुळे विलंब लक्षणीयरीत्या कमी झाला आहे. ब्रोकर 2 आता फक्त ब्रोकर 1 ची वाट पाहत आहे आणि त्याला सरासरी 500 ms अंतर आहे.

तांदूळ. 15. ब्रोकर 3 वरील प्रतिकृती ISR मधून काढली आहे

मग ब्रोकर 2 फॉल्स आणि लीडरशिप ब्रोकर 1 ला संदेश न गमावता पास करते.

तांदूळ. 16. ब्रोकर 2 पडतो

निर्माता एक नवीन नेता शोधतो आणि त्याला संदेश पाठवू लागतो. विलंब आणखी कमी झाला आहे कारण ISR मध्ये आता एक प्रतिकृती आहे! त्यामुळे पर्याय acks = सर्व रिडंडंसी जोडत नाही.

तांदूळ. 17. ब्रोकर 1 वरील प्रतिकृती संदेश न गमावता पुढाकार घेते

मग ब्रोकर 1 क्रॅश होतो आणि लीड ब्रोकर 3 कडे जाते आणि 14238 मेसेजचे नुकसान होते!

तांदूळ. 18. ब्रोकर 1 मरण पावला आणि अशुद्ध सेटिंगसह नेतृत्व संक्रमणाचा परिणाम मोठ्या प्रमाणावर डेटा गमावला

आम्ही पर्याय स्थापित करू शकलो नाही unclean.leader.election.enable अर्थ मध्ये खरे. डीफॉल्टनुसार ते समान आहे खोटे. सेटिंग्ज acks = सर्व с unclean.leader.election.enable=true काही अतिरिक्त डेटा सुरक्षिततेसह प्रवेशयोग्यता प्रदान करते. परंतु आपण पाहू शकता की, आम्ही अद्याप संदेश गमावू शकतो.

पण डेटा सुरक्षा वाढवायची असेल तर? तुम्ही लावू शकता unclean.leader.election.enable = खोटे, परंतु हे डेटा गमावण्यापासून आमचे संरक्षण करेल असे नाही. जर नेता कठोर झाला आणि त्याच्यासोबत डेटा घेतला, तर संदेश अद्याप गमावले आहेत, तसेच प्रशासकाने परिस्थिती पुनर्संचयित करेपर्यंत उपलब्धता गमावली आहे.

सर्व संदेश निरर्थक आहेत याची खात्री करणे चांगले आहे आणि अन्यथा रेकॉर्डिंग टाकून द्या. मग, किमान ब्रोकरच्या दृष्टिकोनातून, डेटा गमावणे केवळ दोन किंवा अधिक एकाचवेळी अपयशी झाल्यासच शक्य आहे.

Acks=all, 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 संच तुम्हाला डेटा सुरक्षा आणि लेटन्सी दरम्यान इष्टतम शिल्लक निवडण्याची परवानगी देतो. उदाहरणार्थ, बहुसंख्य प्रतिकृती अयशस्वी झाल्यास उपलब्धता सुनिश्चित करा, विलंबतेच्या बाबतीत मृत किंवा मंद प्रतिकृतींचा प्रभाव कमी करा.

अर्थ आपण स्वतः निवडतो replica.lag.time.max.ms तुमच्या गरजेनुसार. मूलत:, या पॅरामीटरचा अर्थ असा आहे की आम्ही किती विलंब स्वीकारण्यास तयार आहोत acks = सर्व. डीफॉल्ट मूल्य दहा सेकंद आहे. जर हे तुमच्यासाठी खूप लांब असेल तर तुम्ही ते कमी करू शकता. नंतर ISR मधील बदलांची वारंवारता वाढेल, कारण अनुयायी काढले जातील आणि अधिक वेळा जोडले जातील.

RabbitMQ हा फक्त आरशांचा एक संच आहे ज्याची प्रतिकृती तयार करणे आवश्यक आहे. स्लो मिरर अतिरिक्त लेटन्सीचा परिचय देतात आणि प्रत्येक नोड (नेट टिक) ची उपलब्धता तपासणारे पॅकेट प्रतिसाद देईपर्यंत मृत मिरर प्रतीक्षा करू शकतात. या विलंब समस्या टाळण्याचा ISR हा एक मनोरंजक मार्ग आहे. परंतु आम्ही रिडंडंसी गमावण्याचा धोका पत्करतो कारण ISR फक्त नेत्याकडे संकुचित होऊ शकतो. हा धोका टाळण्यासाठी, सेटिंग वापरा min.insync.replicas.

क्लायंट कनेक्शन हमी

सेटिंग्जमध्ये bootstrap.servers उत्पादक आणि ग्राहक ग्राहकांना जोडण्यासाठी एकाधिक ब्रोकर निर्दिष्ट करू शकतात. कल्पना अशी आहे की जेव्हा एक नोड खाली जातो तेव्हा तेथे अनेक सुटे शिल्लक राहतात ज्यासह क्लायंट कनेक्शन उघडू शकतो. हे अपरिहार्यपणे विभाग नेते नाहीत, परंतु प्रारंभिक लोडिंगसाठी फक्त स्प्रिंगबोर्ड आहेत. क्लायंट त्यांना विचारू शकतो की कोणता नोड रिड/राईट विभाजन लीडर होस्ट करतो.

RabbitMQ मध्ये, क्लायंट कोणत्याही नोडशी कनेक्ट होऊ शकतात आणि अंतर्गत राउटिंग विनंती पाठवते जिथे त्याला जाण्याची आवश्यकता आहे. याचा अर्थ असा की तुम्ही RabbitMQ समोर लोड बॅलन्सर स्थापित करू शकता. काफ्काला क्लायंटला नोडशी जोडणे आवश्यक आहे जे संबंधित विभाजन लीडर होस्ट करते. अशा परिस्थितीत, आपण लोड बॅलन्सर स्थापित करू शकत नाही. यादी bootstrap.servers अयशस्वी झाल्यानंतर क्लायंट योग्य नोड्समध्ये प्रवेश करू शकतात आणि शोधू शकतात हे गंभीर आहे.

काफ्का कॉन्सेन्सस आर्किटेक्चर

आत्तापर्यंत, दलालाच्या पतनाबद्दल क्लस्टरला कसे कळते आणि नवीन नेता कसा निवडला जातो याचा विचार केला नाही. काफ्का नेटवर्क विभाजनांसह कसे कार्य करते हे समजून घेण्यासाठी, तुम्हाला प्रथम एकमत आर्किटेक्चर समजून घेणे आवश्यक आहे.

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

झूकीपर क्लस्टरची स्थिती साठवतो:

• विषयांची यादी, विभाग, कॉन्फिगरेशन, वर्तमान लीडर प्रतिकृती, प्राधान्यकृत प्रतिकृती.
• क्लस्टर सदस्य. प्रत्येक ब्रोकर झूकीपर क्लस्टरला पिंग करतो. ठराविक कालावधीत पिंग न मिळाल्यास, झुकीपर ब्रोकरला अनुपलब्ध म्हणून नोंदवतो.
• कंट्रोलरसाठी मुख्य आणि सुटे नोड्स निवडणे.

कंट्रोलर नोड हा काफ्का दलालांपैकी एक आहे जो प्रतिकृती नेते निवडण्यासाठी जबाबदार आहे. झूकीपर क्लस्टर सदस्यत्व आणि विषयातील बदलांबद्दल नियंत्रकाला सूचना पाठवतो आणि नियंत्रकाने या बदलांवर कार्य करणे आवश्यक आहे.

उदाहरणार्थ, दहा विभाजने आणि 3 च्या प्रतिकृती घटकांसह एक नवीन विषय घेऊ. नियंत्रकाने प्रत्येक विभाजनासाठी नेता निवडणे आवश्यक आहे, ब्रोकर्समध्ये नेत्यांना चांगल्या प्रकारे वितरित करण्याचा प्रयत्न करणे.

प्रत्येक विभाग नियंत्रकासाठी:

• झूकीपरमध्ये ISR आणि लीडरबद्दल माहिती अपडेट करते;
• या विभाजनाची प्रतिकृती होस्ट करणाऱ्या प्रत्येक ब्रोकरला लीडर आणि ISRC कमांड पाठवते, ब्रोकरना ISR आणि लीडरबद्दल माहिती देते.

जेव्हा लीडरसह ब्रोकर पडतो, तेव्हा Zookeeper कंट्रोलरला एक सूचना पाठवतो आणि तो नवीन नेता निवडतो. पुन्हा, नियंत्रक प्रथम Zookeeper अद्यतनित करतो आणि नंतर प्रत्येक ब्रोकरला नेतृत्व बदलाची सूचना देणारा आदेश पाठवतो.

प्रत्येक नेता ISRs भरतीसाठी जबाबदार आहे. सेटिंग्ज replica.lag.time.max.ms तेथे कोण प्रवेश करेल हे ठरवते. जेव्हा ISR बदलतो, तेव्हा नेता नवीन माहिती झुकीपरला पाठवतो.

झूकीपरला नेहमी कोणत्याही बदलांची माहिती दिली जाते जेणेकरुन अयशस्वी झाल्यास, व्यवस्थापन नवीन नेत्याकडे सहजतेने बदलते.

तांदूळ. 21. काफ्का एकमत

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

प्रतिकृतीचे तपशील समजून घेणे तुम्हाला संभाव्य डेटा गमावण्याच्या परिस्थिती चांगल्या प्रकारे समजून घेण्यास मदत करते.

सॅम्पलिंग क्वेरी, लॉग एंड ऑफसेट (LEO) आणि हायवॉटर मार्क (HW)

आम्ही असे मानले की अनुयायी वेळोवेळी नेत्याला विनंत्या आणण्यासाठी पाठवतात. डीफॉल्ट मध्यांतर 500ms आहे. हे RabbitMQ पेक्षा वेगळे आहे कारण RabbitMQ मध्ये प्रतिकृती रांगेतील मिररद्वारे नाही तर मास्टरद्वारे सुरू केली जाते. मास्टर आरशात बदल ढकलतो.

नेता आणि सर्व अनुयायी लॉग एंड ऑफसेट (LEO) आणि Highwater (HW) लेबल जतन करतात. LEO मार्क स्थानिक प्रतिकृतीमध्ये शेवटच्या संदेशाचा ऑफसेट संचयित करतो आणि HW शेवटच्या कमिटचा ऑफसेट ठेवतो. लक्षात ठेवा की कमिट स्थितीसाठी, संदेश सर्व ISR प्रतिकृतींमध्ये कायम असणे आवश्यक आहे. याचा अर्थ असा की LEO सामान्यतः HW पेक्षा थोडा पुढे असतो.

जेव्हा नेत्याला संदेश प्राप्त होतो, तेव्हा तो स्थानिक पातळीवर संग्रहित करतो. अनुयायी त्याच्या LEO प्रसारित करून आणण्याची विनंती करतो. नेता नंतर या LEO पासून सुरू होणारा संदेश पाठवतो आणि वर्तमान HW देखील प्रसारित करतो. जेव्हा लीडरला माहिती मिळते की सर्व प्रतिकृतींनी संदेश दिलेल्या ऑफसेटवर संग्रहित केला आहे, तेव्हा ते HW चिन्ह हलवते. केवळ नेताच HW हलवू शकतो, आणि त्यामुळे सर्व अनुयायांना त्यांच्या विनंतीला दिलेल्या प्रतिसादांमध्ये वर्तमान मूल्य कळेल. याचा अर्थ असा की अनुयायी संदेश आणि HW ज्ञान या दोन्ही बाबतीत नेत्यापेक्षा मागे राहू शकतात. ग्राहकांना फक्त वर्तमान HW पर्यंत संदेश प्राप्त होतात.

लक्षात घ्या की "पर्सिस्टेड" म्हणजे मेमरीमध्ये लिहिलेले आहे, डिस्कवर नाही. कामगिरीसाठी, काफ्का एका विशिष्ट अंतराने डिस्कवर सिंक्रोनाइझ करते. RabbitMQ मध्ये देखील असा मध्यांतर आहे, परंतु मास्टर आणि सर्व मिररने डिस्कवर संदेश लिहिल्यानंतरच ते प्रकाशकाला पोचपावती पाठवेल. काफ्का विकासकांनी, कार्यक्षमतेच्या कारणास्तव, मेमरीमध्ये संदेश लिहिल्याबरोबर एक ack पाठवण्याचा निर्णय घेतला. काफ्का बाजी मारतो की रिडंडंसी केवळ मेमरीमध्ये पोचलेले संदेश थोडक्यात साठवण्याचा धोका कमी करते.

नेत्याचे अपयश

जेव्हा एखादा नेता पडतो, तेव्हा झूकीपर कंट्रोलरला सूचित करतो आणि तो नवीन लीडर प्रतिकृती निवडतो. नवीन नेता त्याच्या LEO नुसार नवीन HW चिन्ह सेट करतो. त्यानंतर अनुयायांना नवीन नेत्याबद्दल माहिती मिळते. काफ्काच्या आवृत्तीवर अवलंबून, अनुयायी दोनपैकी एक परिस्थिती निवडेल:

1. हे ज्ञात HW ला स्थानिक लॉग कापून टाकेल आणि या चिन्हानंतर नवीन नेत्याला संदेशांसाठी विनंती पाठवेल.
2. नेता निवडून आल्याच्या वेळी HW शोधण्यासाठी नेत्याला विनंती पाठवेल आणि नंतर या ऑफसेटसाठी लॉग कापून टाकेल. त्यानंतर या ऑफसेटपासून नियतकालिक फेच विनंत्या करणे सुरू होईल.

फॉलोअरला खालील कारणांसाठी लॉग कापण्याची आवश्यकता असू शकते:

• जेव्हा एखादा नेता अयशस्वी होतो, तेव्हा झूकीपरकडे नोंदणीकृत ISR संचामधील पहिला अनुयायी निवडणूक जिंकतो आणि नेता बनतो. ISR वरील सर्व अनुयायी, जरी "समक्रमित" मानले जात असले तरी, त्यांना माजी नेत्याकडून सर्व संदेशांच्या प्रती प्राप्त झाल्या नसतील. वैशिष्ट्यीकृत फॉलोअरकडे सर्वात अद्ययावत प्रत नसणे पूर्णपणे शक्य आहे. काफ्का हे सुनिश्चित करतो की प्रतिकृतींमध्ये कोणताही फरक नाही. अशाप्रकारे, विसंगती टाळण्यासाठी, प्रत्येक अनुयायाने त्याच्या निवडीच्या वेळी नवीन नेत्याच्या HW मूल्यानुसार त्याचे लॉग कापले पाहिजेत. सेटिंग का हे आणखी एक कारण आहे acks = सर्व सुसंगततेसाठी खूप महत्वाचे.
• संदेश वेळोवेळी डिस्कवर लिहिले जातात. सर्व क्लस्टर नोड्स एकाच वेळी अयशस्वी झाल्यास, डिस्कवर वेगवेगळ्या ऑफसेटसह प्रतिकृती संग्रहित केल्या जातील. हे शक्य आहे की जेव्हा दलाल ऑनलाइन परत येतात, तेव्हा निवडून आलेला नवीन नेता त्याच्या अनुयायांच्या मागे असेल कारण तो इतरांच्या आधी डिस्कवर जतन केला गेला होता.

क्लस्टरसह पुनर्मिलन

क्लस्टरमध्ये पुन्हा सामील होताना, प्रतिकृती नेता अयशस्वी झाल्याप्रमाणेच करतात: ते नेत्याची प्रतिकृती तपासतात आणि त्यांचे लॉग त्याच्या HW (निवडणुकीच्या वेळी) कापतात. त्या तुलनेत, रॅबिटएमक्यू पुन्हा जोडलेल्या नोड्सला पूर्णपणे नवीन मानते. दोन्ही प्रकरणांमध्ये, ब्रोकर कोणतीही विद्यमान स्थिती टाकून देतो. जर स्वयंचलित सिंक्रोनाइझेशन वापरले गेले असेल, तर मास्टरने "संपूर्ण जगाला वाट पाहू द्या" या पद्धतीमध्ये नवीन मिररमध्ये पूर्णपणे सर्व वर्तमान सामग्रीची प्रतिकृती करणे आवश्यक आहे. या ऑपरेशन दरम्यान मास्टर कोणतेही वाचन किंवा लेखन ऑपरेशन स्वीकारत नाही. या दृष्टिकोनामुळे मोठ्या रांगांमध्ये समस्या निर्माण होतात.

काफ्का हा एक वितरित लॉग आहे आणि सर्वसाधारणपणे तो RabbitMQ रांगेपेक्षा अधिक संदेश संग्रहित करतो, जिथे डेटा वाचल्यानंतर रांगेतून काढून टाकला जातो. सक्रिय रांगा तुलनेने लहान असाव्यात. परंतु काफ्का हा त्याच्या स्वतःच्या धारणा धोरणासह एक लॉग आहे, जो दिवस किंवा आठवड्यांचा कालावधी सेट करू शकतो. वितरीत लॉगसाठी रांग अवरोधित करणे आणि संपूर्ण सिंक्रोनाइझेशन दृष्टीकोन पूर्णपणे अस्वीकार्य आहे. त्याऐवजी, काफ्का अनुयायी त्यांची प्रत नेत्याच्या पुढे असल्यास नेत्याच्या HW (त्याच्या निवडीच्या वेळी) त्यांचे लॉग कापतात. अधिक संभाव्य बाबतीत, जेव्हा अनुयायी मागे असतो, तेव्हा तो फक्त त्याच्या वर्तमान LEO पासून प्रारंभ करून विनंत्या आणण्यास प्रारंभ करतो.

नवीन किंवा पुन्हा सामील झालेले अनुयायी ISR बाहेर सुरू करतात आणि कमिटमध्ये सहभागी होत नाहीत. ते नेत्याशी संपर्क साधून ISR मध्ये प्रवेश करेपर्यंत ते शक्य तितक्या लवकर संदेश प्राप्त करून, समूहासोबत काम करतात. कोणतेही लॉक-इन नाही आणि तुमचा सर्व डेटा फेकून देण्याची गरज नाही.

कनेक्टिव्हिटी तोटा

काफ्कामध्ये RabbitMQ पेक्षा अधिक घटक आहेत, म्हणून क्लस्टर डिस्कनेक्ट झाल्यावर त्याच्याकडे वर्तनांचा अधिक जटिल संच असतो. परंतु काफ्का मूळतः क्लस्टर्ससाठी डिझाइन केले गेले होते, त्यामुळे उपाय खूप चांगले विचारात घेतले आहेत.

खाली अनेक कनेक्टिव्हिटी अयशस्वी परिस्थिती आहेत:

• परिस्थिती 1: अनुयायी नेता पाहत नाही, परंतु तरीही प्राणीसंग्रहालय पाहतो.
• परिस्थिती 2: नेत्याला कोणतेही अनुयायी दिसत नाहीत, परंतु तरीही तो Zookeeper पाहतो.
• परिस्थिती 3: अनुयायी नेता पाहतो, परंतु प्राणीसंग्रहालय पाहत नाही.
• परिस्थिती 4: नेता अनुयायांना पाहतो, परंतु प्राणीसंग्रहालय पाहत नाही.
• परिस्थिती 5: अनुयायी इतर काफ्का नोड्स आणि झूकीपर या दोन्हींपासून पूर्णपणे वेगळे आहे.
• परिस्थिती 6: नेता हा इतर काफ्का नोड्स आणि झूकीपर या दोन्हींपासून पूर्णपणे वेगळा आहे.
• परिस्थिती 7: काफ्का कंट्रोलर नोड दुसरा काफ्का नोड पाहू शकत नाही.
• परिस्थिती 8: काफ्का कंट्रोलरला झूकीपर दिसत नाही.

प्रत्येक परिस्थितीचे स्वतःचे वर्तन असते.

परिस्थिती 1: अनुयायी नेता पाहत नाही, परंतु तरीही प्राणीपाल पाहतो

तांदूळ. 22. परिस्थिती 1: तीन प्रतिकृतींचा ISR

कनेक्टिव्हिटी अपयश ब्रोकर 3 ला ब्रोकर 1 आणि 2 पासून वेगळे करते, परंतु Zookeeper पासून नाही. ब्रोकर 3 यापुढे फेच विनंत्या पाठवू शकत नाही. वेळ निघून गेल्यावर replica.lag.time.max.ms ते ISR मधून काढले जाते आणि संदेश कमिटमध्ये सहभागी होत नाही. एकदा कनेक्टिव्हिटी पुनर्संचयित झाल्यानंतर, ते विनंत्या आणणे पुन्हा सुरू करेल आणि जेव्हा लीडरशी संपर्क साधेल तेव्हा ISR मध्ये सामील होईल. झूकीपरला पिंग मिळत राहतील आणि दलाल जिवंत आणि बरा असल्याचे गृहीत धरेल.

तांदूळ. 23. परिस्थिती 1: replica.lag.time.max.ms अंतरालमध्ये ब्रोकरकडून कोणतीही फेच विनंती प्राप्त न झाल्यास त्याला ISR मधून काढून टाकले जाते.

RabbitMQ प्रमाणे स्प्लिट-ब्रेन किंवा नोड सस्पेंशन नाही. त्याऐवजी, रिडंडंसी कमी होते.

परिस्थिती 2: नेत्याला कोणतेही अनुयायी दिसत नाहीत, परंतु तरीही तो Zookeeper पाहतो

तांदूळ. 24. परिस्थिती 2. नेता आणि दोन अनुयायी

नेटवर्क कनेक्टिव्हिटीमधील बिघाड लीडरला फॉलोअर्सपासून वेगळे करतो, परंतु ब्रोकर अजूनही Zookeeper पाहू शकतो. पहिल्या प्रसंगाप्रमाणे, ISR संकुचित होत आहे, परंतु यावेळी फक्त नेत्याकडे आहे कारण सर्व अनुयायी विनंत्या आणणे थांबवतात. पुन्हा, कोणतीही तार्किक विभागणी नाही. त्याऐवजी, कनेक्टिव्हिटी पुनर्संचयित होईपर्यंत नवीन संदेशांसाठी रिडंडंसी कमी होते. झूकीपरला पिंग मिळत राहतात आणि ब्रोकर जिवंत आणि बरा असल्याचा विश्वास ठेवतो.

तांदूळ. 25. परिस्थिती 2. ISR फक्त नेत्यापर्यंत संकुचित झाला आहे

परिस्थिती 3. अनुयायी नेता पाहतो, परंतु प्राणीसंग्रहालय पाहत नाही

अनुयायी झुकीपरपासून विभक्त झाला आहे, परंतु नेत्याच्या दलालपासून नाही. परिणामी, अनुयायी विनंत्या आणणे आणि ISR चे सदस्य होणे सुरू ठेवतो. झूकीपरला यापुढे पिंग मिळत नाहीत आणि ब्रोकर क्रॅशची नोंदणी केली जाते, परंतु तो फक्त एक अनुयायी असल्याने, पुनर्प्राप्तीनंतर कोणतेही परिणाम होत नाहीत.

तांदूळ. 26. परिस्थिती 3: अनुयायी नेत्याला फेच रिक्वेस्ट पाठवत राहतो

परिस्थिती 4. नेता अनुयायांना पाहतो, परंतु प्राणीसंग्रहालय पाहत नाही

तांदूळ. 27. परिस्थिती 4. नेता आणि दोन अनुयायी

नेता झूकीपरपासून विभक्त झाला आहे, परंतु अनुयायांसह दलालांपासून नाही.

तांदूळ. 28. परिस्थिती 4: झूकीपरपासून वेगळा नेता

काही काळानंतर, झुकीपर ब्रोकरच्या अपयशाची नोंद करेल आणि नियंत्रकाला त्याबद्दल सूचित करेल. तो त्याच्या अनुयायांमधून नवीन नेता निवडेल. मात्र, मूळ नेता हाच नेता आहे, असे समजून त्यांच्याकडून प्रवेशिका स्वीकारत राहतील acks = 1. अनुयायी यापुढे त्याला विनंत्या आणण्यासाठी पाठवत नाहीत, म्हणून तो त्यांना मृत समजेल आणि ISR स्वतःच कमी करण्याचा प्रयत्न करेल. परंतु त्याचे Zookeeper शी कनेक्शन नसल्यामुळे, ते हे करू शकणार नाही आणि त्या वेळी पुढील कोणत्याही नोंदी स्वीकारण्यास नकार देईल.

संदेश acks = सर्व पोचपावती मिळणार नाही कारण ISR प्रथम सर्व प्रतिकृती चालू करते आणि संदेश त्यांच्यापर्यंत पोहोचत नाहीत. जेव्हा मूळ नेता त्यांना ISR मधून काढून टाकण्याचा प्रयत्न करेल, तेव्हा ते तसे करण्यास अक्षम असेल आणि कोणतेही संदेश स्वीकारणे अजिबात थांबवेल.

क्लायंट लवकरच लीडरमधील बदल लक्षात घेतात आणि नवीन सर्व्हरवर रेकॉर्ड पाठवण्यास सुरवात करतात. नेटवर्क पुनर्संचयित केल्यावर, मूळ नेता पाहतो की तो यापुढे नेता नाही आणि लॉग डायव्हर्जन टाळण्यासाठी नवीन नेत्याच्या अयशस्वी होण्याच्या वेळी असलेल्या HW मूल्यापर्यंत त्याचा लॉग कमी करतो. ते नंतर नवीन नेत्याला विनंत्या आणण्यासाठी पाठवण्यास प्रारंभ करेल. नवीन नेत्याकडे नक्कल न केलेल्या मूळ नेत्याचे सर्व रेकॉर्ड गमावले जातात. म्हणजेच, दोन नेते काम करत असताना त्या काही सेकंदात मूळ नेत्याने मान्य न केलेले संदेश नष्ट होतील.

तांदूळ. 29. परिस्थिती 4. नेटवर्क पुनर्संचयित झाल्यानंतर ब्रोकर 1 वरील नेता अनुयायी बनतो

परिस्थिती 5: अनुयायी इतर काफ्का नोड्स आणि झूकीपर या दोन्हींपासून पूर्णपणे वेगळे आहे

अनुयायी इतर काफ्का नोड्स आणि झूकीपर या दोन्हींपासून पूर्णपणे अलिप्त आहे. नेटवर्क पुनर्संचयित होईपर्यंत तो फक्त स्वतःला ISR मधून काढून टाकतो आणि नंतर इतरांशी संपर्क साधतो.

तांदूळ. 30. परिस्थिती 5: आयसोलेटेड फॉलोअरला ISR मधून काढून टाकले आहे

परिस्थिती 6: नेता हा इतर काफ्का नोड्स आणि झूकीपर या दोन्हींपासून पूर्णपणे वेगळा आहे

तांदूळ. 31. परिस्थिती 6. नेता आणि दोन अनुयायी

नेता त्याच्या अनुयायांपासून, नियंत्रक आणि प्राणीसंग्रहालयापासून पूर्णपणे अलिप्त आहे. थोड्या काळासाठी ते कडून प्रवेश स्वीकारत राहील acks = 1.

तांदूळ. 32. परिस्थिती 6: नेत्याला इतर काफ्का आणि झुकीपर नोड्सपासून वेगळे करणे

मुदत संपल्यानंतर विनंत्या मिळाल्या नाहीत replica.lag.time.max.ms, तो ISR ला स्वतःला कमी करण्याचा प्रयत्न करेल, परंतु Zookeeper शी संवाद नसल्यामुळे ते तसे करू शकणार नाही, नंतर ते लेखन स्वीकारणे थांबवेल.

दरम्यान, झूकीपर वेगळ्या दलालाला मृत म्हणून चिन्हांकित करेल आणि नियंत्रक नवीन नेता निवडेल.

तांदूळ. 33. परिस्थिती 6. दोन नेते

मूळ नेता काही सेकंदांसाठी प्रविष्ट्या स्वीकारू शकतो, परंतु नंतर कोणतेही संदेश स्वीकारणे थांबवतो. नवीनतम मेटाडेटासह क्लायंट दर 60 सेकंदांनी अद्यतनित केले जातात. त्यांना नेता बदलाची माहिती दिली जाईल आणि ते नवीन नेत्याला एंट्री पाठवण्यास सुरुवात करतील.

तांदूळ. 34. परिस्थिती 6: उत्पादक नवीन नेत्याकडे स्विच करतात

कनेक्टिव्हिटी गमावल्यामुळे मूळ नेत्याने केलेल्या सर्व पुष्टी केलेल्या नोंदी गमावल्या जातील. नेटवर्क पुनर्संचयित केल्यावर, मूळ नेता Zookeeper द्वारे शोधेल की तो यापुढे नेता नाही. मग तो निवडणुकीच्या वेळी नवीन नेत्याच्या HW वर त्याचा लॉग कापेल आणि अनुयायी म्हणून विनंत्या पाठवण्यास सुरुवात करेल.

तांदूळ. 35. परिस्थिती 6: नेटवर्क कनेक्टिव्हिटी पुनर्संचयित केल्यानंतर मूळ नेता अनुयायी बनतो

या परिस्थितीत, तार्किक पृथक्करण अल्प कालावधीसाठी होऊ शकते, परंतु केवळ जर acks = 1 и min.insync.replicas तसेच 1. तार्किक पृथक्करण एकतर नेटवर्क पुनर्संचयित केल्यावर आपोआप समाप्त होते, जेव्हा मूळ नेत्याला कळते की तो आता नेता नाही, किंवा जेव्हा सर्व क्लायंटला समजते की नेता बदलला आहे आणि नवीन नेत्याला लिहायला सुरुवात करतो - जे आधी होईल ते. कोणत्याही परिस्थितीत, काही संदेश गमावले जातील, परंतु केवळ सह acks = 1.

या परिस्थितीचा आणखी एक प्रकार आहे जेथे, नेटवर्क विभाजित होण्यापूर्वी, अनुयायी मागे पडले आणि नेत्याने फक्त स्वत: ला ISR संकुचित केले. त्यानंतर कनेक्टिव्हिटी तुटल्यामुळे ते वेगळे होते. नवीन नेता निवडला जातो, परंतु मूळ नेता प्रवेश स्वीकारणे सुरू ठेवतो, अगदी acks = सर्व, कारण त्याच्याशिवाय ISR मध्ये दुसरे कोणी नाही. नेटवर्क पुनर्संचयित केल्यावर हे रेकॉर्ड गमावले जातील. हा पर्याय टाळण्याचा एकमेव मार्ग आहे min.insync.replicas = 2.

परिस्थिती 7: काफ्का कंट्रोलर नोड दुसरा काफ्का नोड पाहू शकत नाही

सर्वसाधारणपणे, एकदा काफ्का नोडचे कनेक्शन तुटले की, कंट्रोलर त्यावर कोणतीही लीडर बदल माहिती प्रसारित करू शकणार नाही. सर्वात वाईट परिस्थितीत, यामुळे परिस्थिती 6 प्रमाणे अल्पकालीन तार्किक पृथक्करण होईल. अधिक वेळा, ब्रोकर अयशस्वी झाल्यास नेतृत्वासाठी उमेदवार बनणार नाही.

परिस्थिती 8: काफ्का कंट्रोलरला झूकीपर दिसत नाही

झूकीपरला पडलेल्या कंट्रोलरकडून पिंग मिळणार नाही आणि कंट्रोलर म्हणून नवीन काफ्का नोड निवडेल. मूळ नियंत्रक स्वतःला असेच सादर करणे सुरू ठेवू शकतो, परंतु त्याला Zookeeper कडून सूचना प्राप्त होत नाहीत, त्यामुळे त्याच्याकडे कोणतीही कार्ये नसतील. एकदा नेटवर्क पुनर्संचयित झाल्यानंतर, त्याला हे समजेल की तो आता कंट्रोलर नाही, परंतु नियमित काफ्का नोड बनला आहे.

परिस्थितींवरून निष्कर्ष

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

कनेक्टिव्हिटी तुटल्यामुळे नेता झूकीपरपासून विभक्त झाल्यास, यामुळे संदेश गमावले जाऊ शकतात. acks = 1. Zookeeper सह संप्रेषणाच्या अभावामुळे दोन नेत्यांमध्ये थोडक्यात तार्किक विभाजन होते. ही समस्या पॅरामीटरद्वारे सोडविली जाते acks = सर्व.

पॅरामीटर min.insync.replicas दोन किंवा अधिक प्रतिकृतींमध्ये अतिरिक्त आश्वासन मिळते की अशा अल्प-मुदतीच्या परिस्थितींचा परिणाम 6 प्रमाणे हरवलेला संदेश होणार नाही.

हरवलेल्या संदेशांचा सारांश

आपण काफ्कामधील डेटा गमावू शकता अशा सर्व मार्गांची यादी करूया:

• संदेश वापरून पुष्टी केली असल्यास कोणताही नेता अपयश acks = 1
• नेतृत्वाचे कोणतेही अशुद्ध संक्रमण, म्हणजे, ISR बाहेरील अनुयायी, अगदी सह acks = सर्व
• संदेश वापरून पुष्टी झाल्यास नेत्याला Zookeeper पासून वेगळे करणे acks = 1
• ज्या नेत्याने आधीच ISR गट संकुचित केला आहे त्याचे संपूर्ण अलगाव. सर्व संदेश गमावले जातील, अगदी acks = सर्व. हे तरच खरे आहे min.insync.replicas=1.
• सर्व विभाजन नोड्सचे एकाचवेळी अपयश. मेमरीमधून मेसेज स्वीकारले जात असल्यामुळे, काही डिस्कवर अद्याप लिहीले जाऊ शकत नाहीत. सर्व्हर रीबूट केल्यानंतर, काही संदेश गहाळ असू शकतात.

अशुद्ध नेतृत्व संक्रमणे एकतर त्यांना प्रतिबंधित करून किंवा किमान दोन रिडंडंसी सुनिश्चित करून टाळता येऊ शकतात. सर्वात टिकाऊ कॉन्फिगरेशन एक संयोजन आहे acks = सर्व и min.insync.replicas 1 पेक्षा जास्त.

RabbitMQ आणि Kafka च्या विश्वासार्हतेची थेट तुलना

विश्वासार्हता आणि उच्च उपलब्धता सुनिश्चित करण्यासाठी, दोन्ही प्लॅटफॉर्म प्राथमिक आणि दुय्यम प्रतिकृती प्रणाली लागू करतात. तथापि, RabbitMQ ला अकिलीस टाच आहे. अयशस्वी झाल्यानंतर पुन्हा कनेक्ट करताना, नोड्स त्यांचा डेटा टाकून देतात आणि सिंक्रोनाइझेशन अवरोधित केले जाते. हा दुहेरी त्रास RabbitMQ मधील मोठ्या रांगांच्या दीर्घायुष्यावर प्रश्नचिन्ह निर्माण करतो. तुम्हाला एकतर कमी झालेली रिडंडंसी किंवा लांब ब्लॉकिंग वेळा स्वीकारावी लागतील. रिडंडंसी कमी केल्याने मोठ्या प्रमाणावर डेटा गमावण्याचा धोका वाढतो. परंतु जर रांगा लहान असतील, तर रिडंडंसीच्या कारणास्तव, कनेक्शनच्या वारंवार प्रयत्नांचा वापर करून अनुपलब्धतेचा अल्प कालावधी (काही सेकंद) हाताळला जाऊ शकतो.

काफ्काला ही समस्या नाही. हे केवळ नेता आणि अनुयायी यांच्यातील भिन्नतेच्या बिंदूपासून डेटा टाकून देते. सर्व सामायिक डेटा जतन केला जातो. याव्यतिरिक्त, प्रतिकृती प्रणाली अवरोधित करत नाही. नेता नवीन फॉलोअर पकडत असताना पोस्ट स्वीकारणे सुरू ठेवतो, त्यामुळे डेव्हपसाठी, क्लस्टरमध्ये सामील होणे किंवा पुन्हा सामील होणे हे एक क्षुल्लक काम होते. अर्थात, प्रतिकृती दरम्यान नेटवर्क बँडविड्थ सारख्या समस्या अजूनही आहेत. तुम्ही एकाच वेळी अनेक फॉलोअर्स जोडल्यास, तुम्हाला बँडविड्थ मर्यादा येऊ शकते.

जेव्हा क्लस्टरमधील एकाधिक सर्व्हर एकाच वेळी अयशस्वी होतात तेव्हा विश्वासार्हतेमध्ये RabbitMQ काफ्कापेक्षा श्रेष्ठ आहे. आम्ही आधीच म्हटल्याप्रमाणे, मास्टर आणि सर्व मिररद्वारे डिस्कवर संदेश लिहिल्यानंतरच RabbitMQ प्रकाशकाला पुष्टीकरण पाठवते. परंतु हे दोन कारणांसाठी अतिरिक्त विलंब जोडते:

• fsync दर काही शंभर मिलिसेकंदांनी
• प्रत्येक नोड (नेट टिक) ची उपलब्धता तपासणाऱ्या पॅकेट्सच्या आयुष्यभरानंतरच आरशाचे बिघाड लक्षात येऊ शकते. जर आरसा मंदावला किंवा पडला तर यामुळे विलंब होतो.

काफ्काचा पैज असा आहे की जर एखादा संदेश एकाधिक नोड्समध्ये संग्रहित केला असेल तर ते मेमरीवर आदळल्याबरोबर ते संदेश स्वीकारू शकतात. यामुळे, कोणत्याही प्रकारचे संदेश गमावण्याचा धोका असतो (अगदी acks = सर्व, min.insync.replicas=2) एकाच वेळी अयशस्वी झाल्यास.

एकंदरीत, काफ्का उत्तम सॉफ्टवेअर कार्यप्रदर्शन प्रदर्शित करते आणि क्लस्टर्ससाठी ग्राउंड अप पासून डिझाइन केलेले आहे. विश्वासार्हतेसाठी आवश्यक असल्यास अनुयायांची संख्या 11 पर्यंत वाढविली जाऊ शकते. सिंक्रोनाइझेशनमध्ये प्रतिकृती घटक 5 आणि प्रतिकृतींची किमान संख्या min.insync.replicas=3 संदेश गमावणे ही अत्यंत दुर्मिळ घटना बनवेल. जर तुमची पायाभूत सुविधा या प्रतिकृती प्रमाण आणि रिडंडंसी पातळीला समर्थन देत असेल, तर तुम्ही हा पर्याय निवडू शकता.

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

मोठ्या रांगांसाठी RabbitMQ च्या असुरक्षिततेचा एक उतारा म्हणजे त्यांना अनेक लहान रांगांमध्ये विभागणे. जर तुम्हाला संपूर्ण रांगेची संपूर्ण ऑर्डर आवश्यक नसेल, परंतु केवळ संबंधित संदेश (उदाहरणार्थ, विशिष्ट क्लायंटचे संदेश), किंवा काहीही ऑर्डर न केल्यास, हा पर्याय स्वीकार्य आहे: माझा प्रकल्प पहा. रिबॅलेंसर रांग विभाजित करण्यासाठी (प्रकल्प अद्याप प्रारंभिक टप्प्यावर आहे).

शेवटी, रॅबिटएमक्यू आणि काफ्का या दोन्हींच्या क्लस्टरिंग आणि प्रतिकृती यंत्रणेतील अनेक बगबद्दल विसरू नका. कालांतराने, प्रणाली अधिक परिपक्व आणि स्थिर झाल्या आहेत, परंतु कोणताही संदेश कधीही नुकसानापासून 100% सुरक्षित राहणार नाही! शिवाय, डेटा सेंटरमध्ये मोठ्या प्रमाणात अपघात होतात!

माझे काही चुकले असेल, चूक झाली असेल किंवा तुम्ही कोणत्याही मुद्द्यांशी असहमत असाल तर मोकळ्या मनाने टिप्पणी लिहा किंवा माझ्याशी संपर्क साधा.

मला अनेकदा विचारले जाते: “काफ्का किंवा रॅबिटएमक्यू काय निवडायचे?”, “कोणते प्लॅटफॉर्म चांगले आहे?”. सत्य हे आहे की ते खरोखर तुमची परिस्थिती, वर्तमान अनुभव इत्यादींवर अवलंबून असते. मी माझे मत मांडण्यास संकोच करत आहे कारण सर्व वापर प्रकरणांसाठी आणि संभाव्य मर्यादांसाठी एका व्यासपीठाची शिफारस करणे हे खूप जास्त सोपे आहे. मी लेखांची ही मालिका लिहिली आहे जेणेकरून तुम्ही तुमचे स्वतःचे मत तयार करू शकता.

मला असे म्हणायचे आहे की दोन्ही यंत्रणा या क्षेत्रातील नेते आहेत. मी थोडासा पक्षपाती असू शकतो कारण माझ्या प्रोजेक्ट्सच्या अनुभवावरून मी हमी संदेश ऑर्डरिंग आणि विश्वासार्हता यासारख्या गोष्टींना महत्त्व देतो.

मी इतर तंत्रज्ञान पाहतो ज्यामध्ये ही विश्वासार्हता आणि हमी ऑर्डरिंगची कमतरता आहे, नंतर मी RabbitMQ आणि Kafka कडे पाहतो आणि या दोन्ही प्रणालींचे अविश्वसनीय मूल्य लक्षात घेतो.

स्त्रोत: www.habr.com