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

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

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

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

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

एकल नोड लचीलापन आदिम

लचीली कतारबद्धता/रूटिंग

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

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

लगातार संदेश

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

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

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

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

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

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

चावल। 2. कतार प्रतिबिम्बन

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

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

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

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

विफलता कतार

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

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

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

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

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

अंजीर. 5

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

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

चावल। 6. ब्रोकर 1 सेवा में वापस आता है

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

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

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

तुल्यकालन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अब ब्रोकर 3 गिर गया।

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

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

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

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

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

अपडेट

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

• always= अनसिंक्रनाइज़्ड दर्पणों में संक्रमण सक्षम है
• when-synced= केवल सिंक्रनाइज़ दर्पण में संक्रमण, अन्यथा कतार अपठनीय और अलिखित हो जाती है। ब्रोकर के वापस आते ही कतार सेवा में वापस आ जाती है

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

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

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

यहां आपको निम्नलिखित पर विचार करने की आवश्यकता है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• एक अस्थायी नीति का उपयोग करके सभी दर्पणों को हटा देता है जिसकी प्राथमिकता मौजूदा 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 के प्रदर्शन में काफी सुधार होगा। मुझे निम्नलिखित स्थितियों में क्लस्टरिंग के साथ 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 (लेकिन बड़ी निष्क्रिय कतारों के लिए मैन्युअल मोड की आवश्यकता हो सकती है; यह भी विचार करें कि क्या अनुपलब्धता के कारण संदेश खो जाएंगे)
• अल्पसंख्यक मोड रोकें
• लगातार संदेश

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

अगर मुझसे कुछ और छूट गया हो तो कृपया मुझे बताएं।

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

श्रृंखला में पिछले लेख:
नंबर 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