दोष सहिष्णुता और उच्च उपलब्धता बड़े विषय हैं, इसलिए हम RabbitMQ और Kafka को अलग-अलग लेख समर्पित करेंगे। यह लेख RabbitMQ के बारे में है, और अगला लेख RabbitMQ की तुलना में Kafka के बारे में है। यह एक लम्बा लेख है, इसलिए आराम से पढ़िए।

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

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

हम देखेंगे कि स्थिरता और उपलब्धता स्पेक्ट्रम के अलग-अलग छोर पर हैं, और आपको यह चुनना होगा कि किसके लिए अनुकूलन करना है। अच्छी खबर यह है कि RabbitMQ के साथ यह विकल्प संभव है। आपके पास संतुलन को अधिक सुसंगति या अधिक सुलभता की ओर स्थानांतरित करने के लिए ये छोटे-छोटे लीवर हैं।

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

एकल नोड स्थिरता प्राइमिटिव्स

लगातार कतारें/रूटिंग

RabbitMQ में दो प्रकार की कतारें हैं: टिकाऊ और गैर-टिकाऊ। सभी कतारें Mnesia डेटाबेस में संग्रहीत हैं। जब कोई नोड प्रारंभ होता है, तो टिकाऊ कतारें पुनः घोषित हो जाती हैं, और इस प्रकार वे पुनः आरंभ, सिस्टम क्रैश या सर्वर विफलता (जब तक डेटा बना रहता है) के बावजूद बची रहती हैं। इसका मतलब यह है कि जब तक आप एक्सचेंज और कतार को लचीला घोषित करते हैं, कतार/रूटिंग बुनियादी ढांचा पुनः ऑनलाइन हो जाएगा।

नोड को पुनः प्रारंभ करने पर अस्थिर कतारें और रूटिंग हटा दी जाती हैं।

लगातार संदेश

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

चावल। 1. स्थिरता मैट्रिक्स

कतार मिररिंग के साथ क्लस्टरिंग

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

कतार प्रतिबिम्बन:

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

चावल। 2. कतार प्रतिरूपण

मिररिंग को संबंधित नीति द्वारा निर्धारित किया जाता है। इसमें आप प्रतिकृति कारक और यहां तक ​​कि उन नोड्स का भी चयन कर सकते हैं जिन पर कतार रखी जानी चाहिए। उदाहरण:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (एक मास्टर और एक दर्पण)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

प्रकाशक को पुष्टि

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

दोष-सहिष्णु कतार

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

चावल। 3. एकाधिक प्रतिबिम्बित कतारें और उनकी नीतियाँ

ब्रोकर 3 नीचे है. कृपया ध्यान दें कि ब्रोकर 2 पर कतार C मिरर को मास्टर में पदोन्नत किया गया है। यह भी ध्यान रखें कि ब्रोकर 1 पर कतार C के लिए एक नया दर्पण बनाया गया है। RabbitMQ हमेशा आपकी नीतियों में निर्दिष्ट प्रतिकृति कारक को बनाए रखने की कोशिश करता है।

चावल। 4. ब्रोकर 3 बंद हो जाता है, जिसके कारण कतार C विफल हो जाती है।

अगला ब्रोकर 1 गिर रहा है! हमारे पास केवल एक ही दलाल बचा है। कतार बी दर्पण को मास्टर में पदोन्नत किया गया है।

अंजीर. 5

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

इस मामले में, ब्रोकर 1 का नुकसान पूर्ण था, साथ ही डेटा भी, इसलिए अनमिररड क्यू बी पूरी तरह से नष्ट हो गया।

चावल। 6. ब्रोकर 1 फिर से सक्रिय हो गया है

ब्रोकर 3 पुनः ऑनलाइन हो गया है, इसलिए कतार A और B को उनकी HA नीतियों को संतुष्ट करने के लिए पुनः मिरर्स बना दिए गए हैं। लेकिन अब सभी मुख्य कतारें एक नोड पर हैं! यह आदर्श नहीं है, नोड्स के बीच एक समान वितरण बेहतर है। दुर्भाग्य से, यहां मास्टर्स को पुनर्संतुलित करने के लिए कोई विशेष विकल्प नहीं हैं। हम इस समस्या पर बाद में विचार करेंगे, क्योंकि हमें पहले कतार समन्वयन पर विचार करना होगा।

चावल। 7. ब्रोकर 3 सेवा में वापस आ गया। सभी मुख्य कतारें एक नोड पर!

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

तुल्यकालन

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

यह समन्वयन स्वचालित रूप से या मैन्युअल रूप से किया जाता है और इसे कतार नीति द्वारा नियंत्रित किया जाता है। आइये एक उदाहरण देखें।

हमारे पास दो प्रतिबिम्बित कतारें हैं। कतार A स्वचालित रूप से सिंक्रनाइज़ होती है, जबकि कतार B मैन्युअल रूप से सिंक्रनाइज़ होती है। दोनों कतारों में दस संदेश हैं।

चावल। 8. अलग-अलग सिंक्रोनाइज़ेशन मोड वाली दो कतारें

अब हम ब्रोकर 3 को खो चुके हैं।

चावल। 9. ब्रोकर 3 गिर गया

ब्रोकर 3 वापस एक्शन में है। क्लस्टर नए नोड पर प्रत्येक कतार के लिए एक दर्पण बनाता है और स्वचालित रूप से नई कतार A को मास्टर के साथ सिंक्रनाइज़ करता है। हालाँकि, नई कतार बी का दर्पण खाली रहता है। इस प्रकार, हमारे पास कतार A की पूर्ण अतिरेकता है तथा मौजूदा कतार B संदेशों के लिए केवल एक दर्पण है।

चावल। 10. कतार A का नया दर्पण सभी मौजूदा संदेश प्राप्त करता है, लेकिन कतार B का नया दर्पण ऐसा नहीं करता है।

दोनों कतारों में दस और संदेश आते हैं। इसके बाद ब्रोकर 2 क्रैश हो जाता है और कतार A सबसे पुराने मिरर पर वापस आ जाती है, जो ब्रोकर 1 पर है। क्रैश होने पर कोई डेटा हानि नहीं होती है। कतार B के मास्टर पर बीस संदेश हैं और मिरर पर केवल दस, क्योंकि इस कतार ने कभी भी मूल दस संदेशों की प्रतिकृति नहीं बनाई।

चावल। 11. कतार A संदेशों को खोए बिना ब्रोकर 1 पर वापस लौटती है

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

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

चावल। 12. कतार A संदेशों को खोए बिना ब्रोकर 3 पर वापस लौटती है। कतार बी दस संदेशों की हानि के साथ ब्रोकर 3 पर वापस आ जाती है

हम यह भी स्थापित कर सकते हैं ha-promote-on-failure अर्थ में when-synced. इस मामले में, मिरर पर वापस लौटने के बजाय, कतार तब तक प्रतीक्षा करेगी जब तक ब्रोकर 1 अपने डेटा के साथ परिचालन मोड में वापस नहीं आ जाता। उनके लौटने के बाद, बिना किसी डेटा हानि के मुख्य कतार पुनः ब्रोकर 1 पर आ गई। डेटा सुरक्षा के लिए उपलब्धता का त्याग किया जाता है। लेकिन यह एक जोखिम भरा तरीका है, जिससे सम्पूर्ण डेटा हानि भी हो सकती है, जिसके बारे में हम शीघ्र ही चर्चा करेंगे।

चावल। 13. ब्रोकर 1 को खोने के बाद कतार बी अनुपलब्ध रहती है

आप पूछ सकते हैं, "शायद यह बेहतर होगा कि स्वचालित सिंक का उपयोग कभी न किया जाए?" इसका उत्तर यह है कि तुल्यकालन एक अवरोधन कार्य है। सिंक्रनाइज़ेशन के दौरान, मुख्य कतार कोई भी पढ़ने या लिखने का कार्य नहीं कर सकती है!

आइये एक उदाहरण देखें। अब हमारे पास बहुत लंबी कतारें हैं। वे इतने बड़े आकार तक कैसे बढ़ सकते हैं? कई कारणों से:

• कतारों का सक्रिय रूप से उपयोग नहीं किया जाता
• ये हाई-स्पीड कतारें हैं, और अभी उपभोक्ता धीमी गति से काम कर रहे हैं।
• ये हाई-स्पीड कतारें हैं, कोई गड़बड़ी हुई है, और उपभोक्ता इसमें फंस रहे हैं

चावल। 14. अलग-अलग सिंक्रोनाइज़ेशन मोड वाली दो बड़ी कतारें

अब ब्रोकर 3 गिर रहा है।

चावल। 15. ब्रोकर 3 क्रैश हो जाता है, जिससे प्रत्येक कतार में एक मास्टर और एक मिरर रह जाता है

ब्रोकर 3 वापस ऑनलाइन हो गया है और नए मिरर बनाए जा रहे हैं। मुख्य कतार A, मौजूदा संदेशों को नए दर्पण में प्रतिरूपित करना शुरू कर देती है, और इस दौरान कतार अनुपलब्ध रहती है। डेटा को दोहराने में दो घंटे लगते हैं, जिसके परिणामस्वरूप इस कतार के लिए दो घंटे का डाउनटाइम होता है!

हालाँकि, कतार बी पूरी अवधि के दौरान उपलब्ध रहती है। उन्होंने सुलभता के लिए कुछ अतिरेकता का त्याग किया।

चावल। 16. सिंक्रनाइज़ेशन के दौरान कतार अनुपलब्ध रहती है

दो घंटे के बाद, कतार A भी उपलब्ध हो जाती है और पुनः पढ़ने और लिखने का कार्य स्वीकार करना शुरू कर सकती है।

अपडेट

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

• always= असिंक्रोनाइज़्ड मिरर पर स्विच करना सक्षम है
• when-synced= केवल सिंक्रोनाइज़्ड मिरर पर स्विच करें, अन्यथा कतार पढ़ने और लिखने के लिए अनुपलब्ध हो जाएगी। ब्रोकर के वापस आते ही कतार पुनः व्यवस्थित हो जाएगी।

किसी भी तरह, लंबी कतारों के कारण आपको डेटा हानि और अनुपलब्धता के बीच चयन करना होगा।

जब उपलब्धता से डेटा सुरक्षा बेहतर होती है

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

यहां आपको निम्नलिखित बातों को ध्यान में रखना होगा:

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

यदि प्रकाशक किसी संदेश को केवल खारिज ही कर सकता है, तो वास्तव में, पहुंच में सुधार से डेटा सुरक्षा में भी सुधार होता है।

इसलिए, संतुलन बनाना आवश्यक है और समाधान विशिष्ट स्थिति पर निर्भर करता है।

ha-promote-on-failure=when-synced के साथ समस्याएँ

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

लेकिन (और यह एक बड़ी बात है) यदि ब्रोकर ने अपना डेटा खो दिया है, तो हमारे सामने एक बड़ी समस्या है: कतार खो गई है! सारा डेटा नष्ट हो गया! यहां तक ​​कि यदि आपके पास ऐसे दर्पण हैं जो अधिकतर मुख्य कतार के साथ जुड़ जाते हैं, तो उन दर्पणों को भी त्याग दिया जाता है।

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

इसलिए, मैन्युअल सिंक्रनाइज़ेशन (और सिंक्रनाइज़ करने में विफलता) के साथ संयोजन में ha-promote-on-failure=when-syncedमेरी राय में, यह काफी जोखिम भरा है। दस्तावेज़ों में कहा गया है कि डेटा सुरक्षा के लिए यह विकल्प मौजूद है, लेकिन यह दोधारी तलवार है।

मास्टर्स का पुनर्संतुलन

जैसा कि वादा किया गया था, हम सभी मास्टर्स के एक या कई नोड्स पर एकत्रित होने की समस्या पर लौटते हैं। यह रोलिंग क्लस्टर अपग्रेड के परिणामस्वरूप भी हो सकता है। तीन-नोड क्लस्टर में, सभी मुख्य कतारें एक या दो नोड्स पर केंद्रित होंगी।

मास्टर्स को पुनर्संतुलित करना दो कारणों से समस्याजनक हो सकता है:

• पुनर्संतुलन करने के लिए कोई अच्छे उपकरण नहीं हैं
• कतार तुल्यकालन

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

HA नीतियों के माध्यम से मुख्य कतार को स्थानांतरित करने की एक और तरकीब है। मैनुअल में उल्लेख है लिखी हुई कहानी इसके लिए. यह इस प्रकार काम करता है:

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

इसका नकारात्मक पक्ष यह है कि यदि आपके पास बड़ी कतारें हैं या अतिरेक की सख्त आवश्यकताएं हैं तो यह दृष्टिकोण काम नहीं करेगा।

अब आइए देखें कि RabbitMQ क्लस्टर नेटवर्क विभाजन के साथ कैसे काम करते हैं।

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

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

RabbitMQ के साथ हमारे पास दो मुख्य विकल्प हैं:

• विभाजित मस्तिष्क की अनुमति दें. इससे उपलब्धता सुनिश्चित होती है लेकिन इससे डेटा हानि हो सकती है।
• तार्किक पृथक्करण अक्षम करें. क्लाइंट क्लस्टर से कैसे जुड़ते हैं, इस पर निर्भर करते हुए, इसकी उपलब्धता में अल्पकालिक हानि हो सकती है। इससे दो-नोड क्लस्टर में पूर्ण अनुपलब्धता भी हो सकती है।

लेकिन तार्किक विभाजन क्या है? यह तब होता है जब नेटवर्क कनेक्शन के नुकसान के कारण क्लस्टर दो भागों में विभाजित हो जाता है। दर्पण के प्रत्येक पक्ष को एक मास्टर के रूप में पदोन्नत किया जाता है, जिससे प्रत्येक कतार में कई मास्टर्स हो जाते हैं।

चावल। 17. मुख्य कतार और दो दर्पण, प्रत्येक एक अलग नोड पर। तभी नेटवर्क विफलता हो जाती है और एक मिरर अलग हो जाता है। अलग हुए नोड को पता चलता है कि अन्य दो गिर गए हैं और वह अपने दर्पणों को मास्टर की ओर बढ़ा देता है। अब हमारे पास दो मुख्य कतारें हैं, जो लिखने योग्य और पढ़ने योग्य दोनों हैं।

यदि प्रकाशक दोनों मास्टर्स को डेटा भेजते हैं, तो हमें कतार की दो अलग-अलग प्रतियां प्राप्त होंगी।

RabbitMQ के विभिन्न मोड या तो उपलब्धता या स्थिरता प्रदान करते हैं।

अनदेखा मोड (डिफ़ॉल्ट)

यह मोड सुगम्यता प्रदान करता है। सुसंगति की हानि के बाद, तार्किक पृथक्करण घटित होता है। एक बार कनेक्टिविटी बहाल हो जाने पर, व्यवस्थापक को यह निर्णय लेना होगा कि किस विभाजन को प्राथमिकता दी जाए। हारने वाले पक्ष को पुनः प्रारंभ किया जाएगा तथा उस पक्ष का समस्त संचित डेटा नष्ट हो जाएगा।

चावल। 18. तीन प्रकाशक तीन दलालों से जुड़े हुए हैं। आंतरिक रूप से, क्लस्टर सभी अनुरोधों को ब्रोकर 2 पर मुख्य कतार में भेजता है।

अब हम ब्रोकर 3 को खो देते हैं। वह देखता है कि अन्य ब्रोकर बाहर हो गए हैं और अपने मिरर को मास्टर में पदोन्नत करता है। तार्किक विभाजन इसी प्रकार होता है।

चावल। 19. तार्किक विभाजन (विभाजित मस्तिष्क)। रिकॉर्ड दो मुख्य कतारों में रखे जाते हैं, तथा दोनों प्रतियां अलग-अलग हो जाती हैं।

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

चावल। 20. व्यवस्थापक ब्रोकर 3 को अक्षम करता है.

चावल। 21. व्यवस्थापक ब्रोकर 3 को प्रारंभ करता है और यह क्लस्टर में शामिल हो जाता है, तथा वहां छोड़े गए सभी संदेश खो देता है।

कनेक्टिविटी के नुकसान के दौरान और इसकी बहाली के बाद, क्लस्टर और यह कतार पढ़ने और लिखने के लिए उपलब्ध थी।

ऑटोहील मोड

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

अल्पसंख्यक मोड रोकें

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

चावल। 22. तीन प्रकाशक तीन दलालों से जुड़े हुए हैं। आंतरिक रूप से, क्लस्टर सभी अनुरोधों को ब्रोकर 2 पर मुख्य कतार में भेजता है।

फिर ब्रोकर 1 और 2 ब्रोकर 3 से अलग हो जाते हैं। अपने मिरर को मास्टर में पदोन्नत करने के बजाय, ब्रोकर 3 रुक जाता है और अनुपलब्ध हो जाता है।

चावल। 23. ब्रोकर 3 परिचालन को रोक देता है, सभी क्लाइंट को डिस्कनेक्ट कर देता है और कनेक्शन अनुरोधों को अस्वीकार कर देता है।

एक बार कनेक्टिविटी बहाल हो जाने पर, यह क्लस्टर में वापस आ जाता है।

आइए एक अन्य उदाहरण देखें जहां मुख्य कतार ब्रोकर 3 पर है।

चावल। 24. ब्रोकर 3 पर मुख्य कतार.

फिर वही सुसंगति नष्ट हो जाती है। ब्रोकर 3 रुक जाता है क्योंकि वह छोटा है। दूसरी ओर, नोड्स देखते हैं कि ब्रोकर 3 गिर गया है, इसलिए ब्रोकर 1 और 2 के पुराने मिरर को मास्टर में पदोन्नत किया गया है।

चावल। 25. ब्रोकर 2 के अनुपलब्ध होने पर ब्रोकर 3 पर स्विच करना।

जब कनेक्टिविटी बहाल हो जाएगी, तो ब्रोकर 3 क्लस्टर में शामिल हो जाएगा।

चावल। 26. क्लस्टर सामान्य परिचालन पर वापस आ गया है।

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

उपलब्धता सुनिश्चित करने के लिए, यह सुनिश्चित करना महत्वपूर्ण है कि क्लाइंट नोड से सफलतापूर्वक कनेक्ट हो सकें। आइये अपने विकल्पों पर विचार करें।

ग्राहक संपर्क सुनिश्चित करना

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

हमारे विकल्प:

• क्लस्टर तक पहुंच एक लोड बैलेंसर के माध्यम से होती है, जो नोड्स के माध्यम से चक्रित होता है और क्लाइंट सफल होने तक पुनः कनेक्ट करने का प्रयास करते हैं। यदि कोई नोड बंद या रुका हुआ है, तो उस नोड से कनेक्ट करने के प्रयास विफल हो जाएंगे, लेकिन बाद के प्रयास अन्य सर्वरों पर जाएंगे (राउंड रॉबिन फैशन में)। यह अल्पकालिक कनेक्टिविटी हानि या बंद पड़े सर्वर के लिए उपयुक्त है, जिसे शीघ्रता से पुनः चालू किया जा सकेगा।
• लोड बैलेंसर के माध्यम से क्लस्टर तक पहुंचें और रुके हुए/विफल नोड्स का पता चलते ही उन्हें सूची से हटा दें। यदि हम यह कार्य शीघ्रता से कर लें, तथा यदि ग्राहक पुनः कनेक्ट होने का प्रयास कर सकें, तो हमारे पास निरन्तर उपलब्धता रहेगी।
• प्रत्येक क्लाइंट को सभी नोड्स की सूची दें, और क्लाइंट कनेक्ट करते समय यादृच्छिक रूप से उनमें से एक का चयन करेगा। यदि कनेक्ट करने का प्रयास करते समय कोई त्रुटि आती है, तो यह सूची में अगले नोड पर तब तक चला जाता है जब तक कि यह कनेक्ट नहीं हो जाता।
• DNS का उपयोग करके बंद/रोके गए नोड से ट्रैफ़िक निकालें। यह छोटे टीटीएल का उपयोग करके किया जाता है।

निष्कर्ष

रैबिटएमक्यू क्लस्टरिंग के अपने फायदे और नुकसान हैं। सबसे गंभीर नुकसान ये हैं:

• क्लस्टर में शामिल होने पर, नोड्स अपना डेटा त्याग देते हैं;
• सिंक्रनाइज़ेशन को अवरुद्ध करने से कतार अनुपलब्ध हो जाती है।

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

• अविश्वसनीय नेटवर्क.
• अविश्वसनीय भंडारण.
• बहुत लम्बी कतारें.

उच्च उपलब्धता सेटिंग्स के लिए, निम्नलिखित पर विचार करें:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (या autoheal)
• लगातार संदेश
• सुनिश्चित करें कि जब कोई नोड डाउन हो जाए तो क्लाइंट सक्रिय नोड से कनेक्ट हो जाए

स्थिरता (डेटा सुरक्षा) के लिए, निम्नलिखित सेटिंग्स पर विचार करें:

• उपभोक्ता पक्ष पर प्रकाशक की पुष्टि और मैन्युअल स्वीकृति
• ha-promote-on-failure=when-synced, यदि प्रकाशक बाद में पुनः प्रयास कर सकते हैं और यदि आपके पास बहुत विश्वसनीय भंडारण है! अन्यथा, इसे डालो =always.
• ha-sync-mode=automatic (लेकिन बड़ी निष्क्रिय कतारों के लिए मैनुअल मोड की आवश्यकता हो सकती है; इस बात पर भी विचार करें कि अनुपलब्धता के परिणामस्वरूप संदेश खो तो नहीं जाएंगे)
• अल्पसंख्यक मोड रोकें
• लगातार संदेश

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

यदि मैं कुछ और भूल गया हूं तो कृपया मुझे बताएं।

मेरा भी देखें पद, जहां मैं इस आलेख में वर्णित कुछ संदेश हानि परिदृश्यों का परीक्षण करने के लिए Docker और Blockade का उपयोग करके RabbitMQ क्लस्टर पर कहर बरपाता हूं।

श्रृंखला के पिछले लेख:
नंबर 1 - habr.com/ru/company/itsumma/blog/416629
नंबर 2 - habr.com/ru/company/itsumma/blog/418389
नंबर 3 - habr.com/ru/company/itsumma/blog/437446

स्रोत: www.habr.com