В अन्तिम लेख हामीले दोष सहिष्णुता र उच्च उपलब्धताको लागि RabbitMQ क्लस्टरिङमा हेर्यौं। अब Apache Kafka मा गहिरो खन्ने गरौं।

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

चामल। 1. तीन दलालहरू बीच चार खण्डहरू बाँडिएका छन्

सबै पढ्ने र लेख्ने अनुरोधहरू नेतामा जान्छन्। अनुयायीहरूले आवधिक रूपमा नेतालाई नवीनतम सन्देशहरू प्राप्त गर्न अनुरोधहरू पठाउँछन्। उपभोक्ताहरू कहिल्यै अनुयायीहरूमा फर्कनुहुन्न; पछिल्लो केवल अनावश्यकता र गल्ती सहिष्णुताको लागि अवस्थित छ।

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

जब एक दलाल असफल हुन्छ, धेरै वर्गका नेताहरू अक्सर असफल हुन्छन्। तिनीहरूमध्ये प्रत्येकमा, अर्को नोडबाट अनुयायी नेता बन्छन्। वास्तवमा, यो सँधै त्यस्तो हुँदैन, किनकि सिंक्रोनाइजेसन कारकले पनि प्रभाव पार्छ: सिंक्रोनाइज्ड अनुयायीहरू छन् कि छैनन्, र यदि होइन भने, असङ्ख्यिकरण प्रतिकृतिमा स्विच गर्ने अनुमति छ कि छैन। तर अहिलेका लागि चीजहरू जटिल नगरौं।

ब्रोकर 3 ले नेटवर्क छोड्छ, र ब्रोकर 2 मा खण्ड 2 को लागी एक नयाँ नेता चुनिन्छ।

चामल। 2. दलाल 3 को मृत्यु र दलाल 2 मा उनको अनुयायी विभाजन 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 सबैभन्दा सुरक्षित विकल्प हो, तर थप ढिलाइ पनि थप्छ। असफलताका दुई उदाहरणहरू हेरौं र कसरी विभिन्न 'acks' विकल्पहरूले ISR अवधारणासँग अन्तरक्रिया गर्छ।

Acks = 1 र ISR

यस उदाहरणमा, हामी देख्नेछौं कि यदि नेताले सबै अनुयायीहरूबाट प्रत्येक सन्देश सुरक्षित हुनको लागि पर्खदैन भने, नेता असफल भएमा डाटा हानि सम्भव छ। सिंक नगरिएको अनुयायीमा नेभिगेट गर्ने सेटिङद्वारा सक्षम वा असक्षम गर्न सकिन्छ unclean.leader.election.enable.

यस उदाहरणमा, निर्मातासँग मान acks=1 छ। खण्ड सबै तीन दलालहरूमा वितरित गरिएको छ। ब्रोकर 3 पछाडि छ, यो आठ सेकेन्ड पहिले नेतासँग सिङ्क्रोनाइज गरिएको छ र अहिले 7456 सन्देशहरू पछाडि छ। ब्रोकर १ मात्र एक सेकेन्ड पछाडि थियो। हाम्रो निर्माताले सन्देश पठाउँछ र तुरुन्तै एक ack फिर्ता प्राप्त गर्दछ, ढिलो वा मृत अनुयायीहरूको ओभरहेड बिना जुन नेताले पर्खिरहेको छैन।

चामल। 7. तीन प्रतिकृतिहरू भएको ISR

ब्रोकर 2 असफल हुन्छ र निर्माताले जडान त्रुटि प्राप्त गर्दछ। नेतृत्व ब्रोकर 1 मा पास भएपछि, हामीले 123 सन्देशहरू गुमाउँछौं। ब्रोकर 1 मा अनुयायी ISR को भाग थियो, तर यो पतन हुँदा नेतासँग पूर्ण रूपमा सिंक्रोनाइज गरिएको थिएन।

चामल। 8. यो क्र्यास हुँदा सन्देशहरू हराउँछन्

कन्फिगरेसनमा bootstrap.servers निर्मातासँग धेरै दलालहरू सूचीबद्ध छन् र अर्को दलाललाई सोध्न सक्छन् जो नयाँ खण्ड नेता हुन्। त्यसपछि यसले ब्रोकर १ मा जडान स्थापना गर्छ र सन्देशहरू पठाउन जारी राख्छ।

चामल। 9. छोटो ब्रेक पछि सन्देशहरू पठाउन सुरु हुन्छ

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

चामल। 10. ब्रोकर 3 मा अनुयायी ISR बाट हटाइन्छ

ब्रोकर 1 तल जान्छ र 3 सन्देशहरू गुमाउँदा नेतृत्वको भूमिका ब्रोकर 15286 मा जान्छ! निर्माताले जडान त्रुटि सन्देश प्राप्त गर्दछ। ISR बाहिरको नेतामा संक्रमण केवल सेटिङको कारणले सम्भव थियो unclean.leader.election.enable=true। यदि यो मा स्थापित छ झूटा, तब ट्रान्जिसन हुने छैन र सबै पढ्ने र लेख्ने अनुरोधहरू अस्वीकार गरिनेछ। यस अवस्थामा, हामी ब्रोकर 1 को प्रतिकृतिमा उसको अक्षुण्ण डेटाको साथ फिर्ता हुन पर्खन्छौं, जसले फेरि नेतृत्व लिनेछ।

चामल। 11. ब्रोकर 1 पतन। जब एक विफलता हुन्छ, सन्देशहरूको ठूलो संख्या हराएको छ

निर्माताले अन्तिम ब्रोकरसँग जडान स्थापित गर्दछ र देख्छ कि उनी अब खण्डको नेता हुन्। उसले ब्रोकर ३ लाई म्यासेज पठाउन थाल्छ।

चामल। 12. छोटो विश्राम पछि, सन्देशहरू खण्ड 0 मा फेरि पठाइन्छ

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

Acks = सबै र ISR

यो परिदृश्य फेरि दोहोर्याउनुहोस्, तर संग acks = सबै। ब्रोकर 3 सँग चार सेकेन्डको औसत विलम्बता छ। निर्माताले सन्देश पठाउँछ acks = सबै, र अब द्रुत प्रतिक्रिया प्राप्त गर्दैन। नेता सन्देशलाई ISR मा सबै प्रतिकृतिहरू द्वारा सुरक्षित गर्न पर्खिरहेका छन्।

चामल। 13. तीन प्रतिकृतिहरू भएको ISR। एउटा ढिलो छ, जसले गर्दा रेकर्डिङ ढिलाइ हुन्छ

थप ढिलाइको चार सेकेन्ड पछि, ब्रोकर 2 ले एक ack पठाउँछ। सबै प्रतिकृतिहरू अब पूर्ण रूपमा अद्यावधिक गरिएका छन्।

चामल। 14. सबै प्रतिकृतिहरू सन्देशहरू बचत गर्नुहोस् र ack पठाउनुहोस्

ब्रोकर 3 अब अझ पछाडि परेको छ र ISR बाट हटाइयो। ISR मा कुनै ढिलो प्रतिकृतिहरू बाँकी नभएकाले विलम्बता उल्लेखनीय रूपमा कम भएको छ। ब्रोकर 2 अब ब्रोकर 1 को लागि मात्र पर्खन्छ, र उसको औसत 500 ms को ढिलाइ छ।

चामल। १५. ब्रोकर ३ मा रहेको प्रतिकृति 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. यहाँ तीन दलाल एकै समयमा रेकर्ड गुमाउन को लागी खस्नु पर्छ! अवश्य पनि, तपाइँ अतिरिक्त विलम्बता मा यो विश्वसनीयता को लागी तिर्नुहुन्छ।

जब डाटा सुरक्षाको लागि पहुँच आवश्यक हुन्छ

In as RabbitMQ को साथ मामला, कहिलेकाहीँ डाटा सुरक्षाको लागि पहुँच आवश्यक हुन्छ। यहाँ तपाईंले के बारे सोच्न आवश्यक छ:

• के प्रकाशकले मात्र त्रुटि फर्काउन सक्छ र अपस्ट्रीम सेवा वा प्रयोगकर्तालाई पछि फेरि प्रयास गर्न सक्छ?
• के प्रकाशकले सन्देशलाई स्थानीय रूपमा वा डाटाबेसमा सुरक्षित गरेर पछि फेरि प्रयास गर्न सक्छ?

यदि जवाफ होईन भने, उपलब्धतालाई अनुकूलन गर्दा डाटा सुरक्षा सुधार हुन्छ। यदि तपाईंले रेकर्डिङ नगर्नुको सट्टा उपलब्धता छनौट गर्नुभयो भने तपाईंले कम डेटा गुमाउनुहुनेछ। यसैले, यो सबै एक सन्तुलन खोज्न तल आउँछ, र निर्णय विशिष्ट स्थिति मा निर्भर गर्दछ।

ISR को अर्थ

ISR सुइटले तपाईंलाई डाटा सुरक्षा र विलम्बता बीचको इष्टतम सन्तुलन छनोट गर्न अनुमति दिन्छ। उदाहरणका लागि, धेरैजसो प्रतिकृतिहरू असफल भएमा उपलब्धता सुनिश्चित गर्नुहोस्, विलम्बताको सन्दर्भमा मृत वा ढिलो प्रतिकृतिहरूको प्रभावलाई कम गर्दै।

हामी आफैं अर्थ छान्छौं replica.lag.time.max.ms आफ्नो आवश्यकता अनुसार। अनिवार्य रूपमा, यो प्यारामिटरको अर्थ हामी कति ढिलाइ स्वीकार गर्न इच्छुक छौं भन्ने हो acks = सबै। पूर्वनिर्धारित मान दस सेकेन्ड हो। यदि यो तपाईंको लागि धेरै लामो छ भने, तपाईं यसलाई कम गर्न सक्नुहुन्छ। त्यसपछि ISR मा परिवर्तनहरूको आवृत्ति बढ्नेछ, किनकि अनुयायीहरूलाई हटाइनेछ र धेरै पटक थपिनेछ।

RabbitMQ केवल दर्पणहरूको एक सेट हो जुन प्रतिलिपि गर्न आवश्यक छ। ढिलो दर्पणले थप विलम्बता परिचय दिन्छ, र मृत ऐनाले प्रतिक्रिया दिन प्रत्येक नोड (नेट टिक) को उपलब्धता जाँच गर्ने प्याकेटहरू सम्म पर्खन सक्छ। ISR यी विलम्बता समस्याहरूबाट बच्नको लागि एक रोचक तरिका हो। तर हामी रिडन्डन्सी गुमाउने जोखिममा छौं किनकि ISR ले नेतामा मात्र संकुचित हुन सक्छ। यो जोखिमबाट बच्न, सेटिङ प्रयोग गर्नुहोस् min.insync.replicas.

ग्राहक जडान ग्यारेन्टी

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

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

काफ्का कन्सेन्सस वास्तुकला

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

प्रत्येक काफ्का क्लस्टरलाई Zookeeper क्लस्टरको साथमा तैनाथ गरिएको छ, जुन एक वितरित सहमति सेवा हो जसले प्रणालीलाई उपलब्धतामा स्थिरतालाई प्राथमिकता दिँदै केही दिइएको राज्यमा सहमतिमा पुग्न अनुमति दिन्छ। पढ्न र लेख्ने कार्यहरू अनुमोदन गर्न Zookeeper नोडहरूको बहुमतको सहमति आवश्यक छ।

चिडियाखानाले क्लस्टरको अवस्था भण्डार गर्छ:

• विषयहरूको सूची, खण्डहरू, कन्फिगरेसन, वर्तमान नेता प्रतिकृतिहरू, रुचाइएको प्रतिकृतिहरू।
• क्लस्टर सदस्यहरू। प्रत्येक दलालले Zookeeper क्लस्टरलाई पिङ गर्छ। यदि यसले निर्दिष्ट समय भित्र पिंग प्राप्त गर्दैन भने, त्यसपछि Zookeeper ले ब्रोकरलाई अनुपलब्धको रूपमा रेकर्ड गर्दछ।
• नियन्त्रकको लागि मुख्य र अतिरिक्त नोडहरू चयन गर्दै।

कन्ट्रोलर नोड काफ्का दलालहरू मध्ये एक हो जुन प्रतिकृति नेताहरू चयन गर्न जिम्मेवार छ। Zookeeper ले क्लस्टर सदस्यता र विषय परिवर्तनहरूको बारेमा नियन्त्रकलाई सूचनाहरू पठाउँछ, र नियन्त्रकले यी परिवर्तनहरूमा कार्य गर्नुपर्छ।

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

प्रत्येक खण्ड नियन्त्रकको लागि:

• ISR र नेता बारे Zookeeper मा अद्यावधिक जानकारी;
• यस विभाजनको प्रतिकृति होस्ट गर्ने प्रत्येक ब्रोकरलाई एक नेता र ISRC आदेश पठाउँछ, दलालहरूलाई ISR र नेताको बारेमा जानकारी गराउँछ।

जब एक नेतासँग दलाल खस्छ, Zookeeper ले नियन्त्रकलाई सूचना पठाउँछ, र यसले नयाँ नेता चयन गर्दछ। फेरि, नियन्त्रकले पहिले Zookeeper अपडेट गर्छ र त्यसपछि नेतृत्व परिवर्तनको बारेमा सूचित गर्दै प्रत्येक दलाललाई आदेश पठाउँछ।

प्रत्येक नेता ISRs भर्ती गर्न जिम्मेवार छ। सेटिङहरू replica.lag.time.max.ms त्यहाँ कसले प्रवेश गर्ने भनेर निर्धारण गर्दछ। जब ISR परिवर्तन हुन्छ, नेताले Zookeeper लाई नयाँ जानकारी पठाउँदछ।

Zookeeper लाई कुनै पनि परिवर्तनको बारेमा सधैं सूचित गरिन्छ ताकि असफलताको स्थितिमा, व्यवस्थापन नयाँ नेतामा सजिलै संग संक्रमण हुन्छ।

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

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

प्रतिकृतिको विवरणहरू बुझ्नले तपाईंलाई सम्भावित डेटा हानि परिदृश्यहरू राम्रोसँग बुझ्न मद्दत गर्दछ।

नमूना प्रश्नहरू, लग एन्ड अफसेट (LEO) र हाईवाटर मार्क (HW)

हामीले विचार गर्यौं कि अनुयायीहरूले आवधिक रूपमा नेतालाई अनुरोधहरू पठाउँछन्। पूर्वनिर्धारित अन्तराल 500ms हो। यो RabbitMQ भन्दा फरक छ कि RabbitMQ मा प्रतिकृति लाम दर्पण द्वारा तर मास्टर द्वारा सुरु गरिएको हो। मालिकले ऐनामा परिवर्तनहरू धकेल्छन्।

नेता र सबै अनुयायीहरूले लग एन्ड अफसेट (LEO) र Highwater (HW) लेबल बचत गर्छन्। LEO मार्कले स्थानीय प्रतिकृतिमा अन्तिम सन्देशको अफसेट भण्डारण गर्छ, र HW ले अन्तिम कमिटको अफसेट राख्छ। सम्झनुहोस् कि प्रतिबद्ध स्थितिको लागि, सन्देश सबै ISR प्रतिकृतिहरूमा जारी हुनुपर्छ। यसको मतलब LEO सामान्यतया HW भन्दा अलि अगाडि हुन्छ।

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

ध्यान दिनुहोस् कि "निरन्तर" भनेको मेमोरीमा लेखिएको हो, डिस्कमा होइन। कार्यसम्पादनको लागि, काफ्काले निश्चित अन्तरालमा डिस्कमा सिङ्क्रोनाइज गर्छ। RabbitMQ सँग पनि यस्तो अन्तराल छ, तर यसले मास्टर र सबै मिररहरूले डिस्कमा सन्देश लेखे पछि मात्र प्रकाशकलाई स्वीकृति पठाउनेछ। काफ्का विकासकर्ताहरूले प्रदर्शन कारणहरूको लागि, सन्देश मेमोरीमा लेख्ने बित्तिकै एक ack पठाउने निर्णय गरे। काफ्काले शर्त राख्छन् कि रिडन्डन्सीले मेमोरीमा मात्र स्वीकार गरिएका सन्देशहरू छोटो रूपमा भण्डारण गर्ने जोखिमलाई अफसेट गर्दछ।

नेताको असफलता

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

1. यसले स्थानीय लगलाई ज्ञात HW मा काट्नेछ र यो चिन्ह पछि सन्देशहरूको लागि नयाँ नेतालाई अनुरोध पठाउनेछ।
2. नेता चुनिएको समयमा HW पत्ता लगाउन नेतालाई अनुरोध पठाउनेछ, र त्यसपछि यो अफसेटमा लग काट्नुहोस्। त्यसपछि यो अफसेटबाट सुरु हुँदै आवधिक प्राप्त अनुरोधहरू बनाउन थाल्छ।

अनुयायीले निम्न कारणहरूको लागि लग काट्नु पर्ने हुन सक्छ:

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

क्लस्टर संग पुनर्मिलन

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

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

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

जडानको हानि

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

तल धेरै जडान विफलता परिदृश्यहरू छन्:

• परिदृश्य 1: अनुयायीले नेतालाई देख्दैन, तर अझै पनि चिडियाखाना हेर्छ।
• परिदृश्य 2: नेताले कुनै पनि अनुयायीहरू देख्दैनन्, तर अझै पनि चिडियाखाना हेर्छन्।
• परिदृश्य 3: अनुयायीले नेतालाई देख्छ, तर चिडियाखाना गर्नेलाई देख्दैन।
• परिदृश्य 4: नेताले अनुयायीहरूलाई देख्छन्, तर चिडियाखाना गर्नेलाई देख्दैनन्।
• परिदृश्य 5: अनुयायी अन्य काफ्का नोडहरू र Zookeeper दुवैबाट पूर्ण रूपमा अलग छन्।
• परिदृश्य 6: नेता अन्य काफ्का नोडहरू र चिडियाखाना दुवैबाट पूर्ण रूपमा अलग छन्।
• परिदृश्य 7: काफ्का नियन्त्रक नोडले अर्को काफ्का नोड देख्न सक्दैन।
• परिदृश्य 8: काफ्का नियन्त्रकले चिडियाखाना देख्दैनन्।

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

परिदृश्य 1: अनुयायीले नेतालाई देख्दैन, तर अझै पनि चिडियाखाना हेर्छ

चामल। 22. परिदृश्य 1: तीन प्रतिकृतिहरूको ISR

जडान विफलताले ब्रोकर 3 लाई ब्रोकर 1 र 2 बाट अलग गर्छ, तर Zookeeper बाट होइन। ब्रोकर ३ ले उप्रान्त फेच अनुरोधहरू पठाउन सक्दैन। समय बितेपछि replica.lag.time.max.ms यो ISR बाट हटाइयो र सन्देश कमिटहरूमा भाग लिदैन। एक पटक जडान पुनर्स्थापित भएपछि, यसले अनुरोधहरू ल्याउने र ISR मा सामेल हुने छ जब यो नेतासँग भेट्छ। Zookeeper ले पिंगहरू प्राप्त गर्न जारी राख्नेछ र ब्रोकर जीवित र राम्रो छ भनी मान्नेछ।

चामल। 23. परिदृश्य 1: दलाललाई ISR बाट हटाइन्छ यदि replica.lag.time.max.ms अन्तराल भित्र कुनै पनि प्राप्त अनुरोध प्राप्त भएन।

RabbitMQ मा जस्तो कुनै स्प्लिट-ब्रेन वा नोड निलम्बन छैन। बरु, अनावश्यकता कम हुन्छ।

परिदृश्य 2: नेताले कुनै पनि अनुयायीहरू देख्दैनन्, तर अझै पनि Zookeeper देख्छन्

चामल। 24. परिदृश्य 2. नेता र दुई अनुयायीहरू

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

चामल। 25. परिदृश्य 2. ISR नेतामा मात्र संकुचित भएको छ

परिदृश्य 3. अनुयायीले नेतालाई देख्छ, तर चिडियाखाना गर्नेलाई देख्दैन

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

चामल। 26. परिदृश्य 3: अनुयायीले नेतालाई अनुरोधहरू पठाउन जारी राख्छ

परिदृश्य 4. नेताले अनुयायीहरूलाई देख्छन्, तर चिडियाखानालाई देख्दैनन्

चामल। 27. परिदृश्य 4. नेता र दुई अनुयायीहरू

नेता चिडियाखानाबाट अलग हुन्छ, तर अनुयायीहरूसँग दलालहरूबाट होइन।

चामल। 28. परिदृश्य 4: नेता Zookeeper बाट अलग

केही समय पछि, Zookeeper ले ब्रोकर असफलता दर्ता गर्नेछ र यसको बारेमा नियन्त्रकलाई सूचित गर्नेछ। उनले आफ्ना अनुयायीहरूमध्ये नयाँ नेता चयन गर्नेछन्। तर, मूल नेताले आफू नै नेता हो भनी सोचिरहनेछ र त्यसबाट प्रविष्टिहरू स्वीकार गरिरहनेछ acks = 1। अनुयायीहरूले अब उहाँलाई अनुरोधहरू पठाउँदैनन्, त्यसैले उसले तिनीहरूलाई मृत मान्नेछ र ISR लाई आफैंमा संकुचन गर्ने प्रयास गर्नेछ। तर यससँग Zookeeper सँग जडान नभएकोले, यसले यो गर्न सक्नेछैन, र त्यस समयमा कुनै पनि थप प्रविष्टिहरू स्वीकार गर्न अस्वीकार गर्नेछ।

सन्देशहरू acks = सबै ISR ले सबै प्रतिकृतिहरू सक्रिय गरेको हुनाले र सन्देशहरू तिनीहरूमा पुग्दैन। जब मूल नेताले तिनीहरूलाई ISR बाट हटाउने प्रयास गर्छ, यो त्यसो गर्न असक्षम हुनेछ र कुनै पनि सन्देशहरू स्वीकार गर्न रोक्नेछ।

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

चामल। 29. परिदृश्य 4. ब्रोकर 1 मा नेता नेटवर्क पुनर्स्थापना पछि अनुयायी बन्छ

परिदृश्य 5: अनुयायी अन्य काफ्का नोडहरू र Zookeeper दुवैबाट पूर्ण रूपमा अलग छन्

अनुयायी दुवै अन्य काफ्का नोड्स र Zookeeper बाट पूर्ण रूपमा अलग छ। नेटवर्क पुनर्स्थापित नभएसम्म उसले आफैलाई ISR बाट हटाउँछ, र त्यसपछि अरूसँग समात्छ।

चामल। 30. परिदृश्य 5: पृथक अनुयायी ISR बाट हटाइयो

परिदृश्य 6: नेता अन्य काफ्का नोडहरू र चिडियाखाना दुवैबाट पूर्ण रूपमा अलग छन्

चामल। 31. परिदृश्य 6. नेता र दुई अनुयायीहरू

नेता आफ्ना अनुयायीहरू, नियन्त्रक र चिडियाखानाबाट पूर्ण रूपमा अलग छन्। छोटो अवधिको लागि यसले प्रविष्टिहरू स्वीकार गर्न जारी राख्नेछ acks = 1.

चामल। 32. परिदृश्य 6: अन्य काफ्का र 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 = सबै, किनकि उहाँ बाहेक ISR मा अरू कोही छैन। नेटवर्क पुनर्स्थापित भएपछि यी रेकर्डहरू हराउनेछन्। यो विकल्पबाट बच्ने एक मात्र तरिका हो min.insync.replicas = 2.

परिदृश्य 7: काफ्का नियन्त्रक नोडले अर्को काफ्का नोड देख्न सक्दैन

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

परिदृश्य 8: काफ्का नियन्त्रकले चिडियाखाना देख्दैनन्

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

परिदृश्यहरूबाट निष्कर्षहरू

हामी देख्छौं कि अनुयायी जडानको हानि सन्देश हराउने परिणाम होइन, तर नेटवर्क पुनर्स्थापना नभएसम्म अस्थायी रूपमा रिडन्डन्सी कम गर्दछ। यो, निस्सन्देह, यदि एक वा बढी नोडहरू हराएमा डेटा हानि हुन सक्छ।

यदि नेता कनेक्टिविटीको हानिको कारण 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 ० भन्दा बढी

RabbitMQ र Kafka को विश्वसनीयता को प्रत्यक्ष तुलना

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

काफ्कालाई यो समस्या छैन। यसले नेता र अनुयायी बीचको भिन्नताको बिन्दुबाट मात्र डाटा खारेज गर्दछ। सबै साझा डाटा बचत गरिएको छ। थप रूपमा, प्रतिकृतिले प्रणालीलाई रोक्दैन। नेताले पोष्टहरू स्वीकार गर्न जारी राख्छ जब नयाँ अनुयायीहरू समात्छन्, त्यसैले डेभपहरूका लागि, क्लस्टरमा सामेल हुनु वा पुन: सामेल हुनु एउटा सानो काम हुन्छ। निस्सन्देह, त्यहाँ अझै पनि समस्याहरू छन् जस्तै प्रतिकृतिको समयमा नेटवर्क ब्यान्डविथ। यदि तपाइँ एकै समयमा धेरै अनुयायीहरू थप्नुहुन्छ भने, तपाइँले ब्यान्डविथ सीमा सामना गर्न सक्नुहुन्छ।

एकै समयमा क्लस्टरमा धेरै सर्भरहरू असफल हुँदा RabbitMQ विश्वसनीयतामा काफ्का भन्दा उच्च हुन्छ। हामीले पहिले नै भनेझैं, RabbitMQ ले मास्टर र सबै मिररहरूद्वारा डिस्कमा सन्देश लेखेपछि मात्र प्रकाशकलाई पुष्टिकरण पठाउँछ। तर यसले दुई कारणका लागि थप विलम्बता थप्छ:

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

काफ्काको शर्त यो हो कि यदि सन्देश धेरै नोडहरूमा भण्डार गरिएको छ भने, यसले मेमोरीमा हिट हुने बित्तिकै सन्देशहरू स्वीकार गर्न सक्छ। यसका कारण, कुनै पनि प्रकारका सन्देशहरू हराउने जोखिम हुन्छ (भी acks = सबै, min.insync.replicas=2) एक साथ विफलता को मामला मा।

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

RabbitMQ क्लस्टरिङ साना लामहरूको लागि राम्रो छ। तर साना लामहरू पनि छिटो बढ्न सक्छ जब त्यहाँ भारी ट्राफिक हुन्छ। एक पटक लामहरू ठूलो भएपछि, तपाईंले उपलब्धता र विश्वसनीयता बीचको कठिन छनौटहरू गर्नुपर्नेछ। RabbitMQ क्लस्टरिङ गैर-विशिष्ट परिस्थितिहरूको लागि सबैभन्दा उपयुक्त छ जहाँ RabbitMQ को लचिलोपनका फाइदाहरू यसको क्लस्टरिङको कुनै पनि बेफाइदाभन्दा बढी हुन्छन्।

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

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

यदि मैले केहि छुटेको छु, गल्ती गरेको छु, वा तपाइँ कुनै पनि बिन्दुहरूसँग असहमत हुनुहुन्छ भने, एक टिप्पणी लेख्न वा मलाई सम्पर्क गर्न नहिचकिचाउनुहोस्।

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

म भन्न चाहन्छु कि दुबै प्रणालीहरू यस क्षेत्रमा नेता हुन्। म थोरै पक्षपाती हुन सक्छु किनभने परियोजनाहरूसँगको मेरो अनुभवबाट म ग्यारेन्टी सन्देश अर्डर र विश्वसनीयता जस्ता कुराहरूलाई मूल्यवान गर्छु।

म अन्य प्रविधिहरू देख्छु जसमा यो विश्वसनीयता र ग्यारेन्टी अर्डरिङको कमी छ, त्यसपछि म RabbitMQ र Kafka लाई हेर्छु र यी दुवै प्रणालीहरूको अविश्वसनीय मूल्य महसुस गर्छु।

स्रोत: www.habr.com