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

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

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

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

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

एक नोड की स्थिरता के आदिम

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

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

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

लगातार संदेश

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


अंजीर। 1. स्थिरता मैट्रिक्स

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

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

कतार मिररिंग:

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

अंजीर। 2. कतार का दर्पण

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

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

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

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

फेलओवर कतार

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


अंजीर। 3. कई प्रतिबिम्बित कतारें और उनकी नीतियां

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


अंजीर। 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 भी सेट कर सकते हैं when-synced । इस मामले में, दर्पण को वापस रोल करने के बजाय, कतार ब्रोकर 1 तक इंतजार करेगी जब तक कि उसका डेटा ऑनलाइन मोड में वापस नहीं आएगा। उनकी वापसी के बाद, मुख्य कतार फिर से ब्रोकर 1 पर डेटा हानि के बिना दिखाई देती है। डेटा सुरक्षा के लिए पहुँच की बलि दी जाती है। लेकिन यह एक जोखिम भरा तरीका है, जिससे डेटा का पूर्ण नुकसान भी हो सकता है, जिसे हम निकट भविष्य में विचार करेंगे।


अंजीर। 13. ब्रोकर 1 को खोने के बाद लाइन बी अनुपलब्ध है

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

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

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

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

अब ब्रोकर 3 क्रैश।


अंजीर। 15. ब्रोकर 3 गिरता है, प्रत्येक कतार में एक मास्टर और एक दर्पण को छोड़कर

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

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


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

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

अद्यतन करने

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

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

एक रास्ता या दूसरा, बड़ी कतारों के साथ, आपको डेटा हानि और दुर्गमता के बीच चयन करना होगा।

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

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

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

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

यदि प्रकाशक केवल संदेश छोड़ने में सक्षम है, तो, वास्तव में, एक्सेसिबिलिटी में सुधार करने से डेटा सुरक्षा भी बढ़ जाती है।

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

हा-प्रमोशन-ऑन-विफलता के साथ समस्याएं = जब-सिंक किया गया हो

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

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

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

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

रिबैलेंसिंग मास्टर्स

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

असंतुलित स्वामी दो कारणों से समस्याग्रस्त हो सकते हैं:

• कोई अच्छा रीबैलेंसिंग टूल नहीं
• कतार सिंक

पुनर्संतुलन के लिए, एक तृतीय - पक्ष प्लगइन है जो आधिकारिक रूप से समर्थित नहीं है। थर्ड-पार्टी प्लग-इन के बारे में, RabbitMQ मैनुअल कहता है : “प्लग-इन कुछ अतिरिक्त कॉन्फ़िगरेशन और रिपोर्टिंग टूल प्रदान करता है, लेकिन यह 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. TTL.

निष्कर्ष

RabbitMQ . , :

• ;
  
• .

. RabbitMQ , . , . RabbitMQ . RabbitMQ :

• .
  
• .
  
• .

, :

• ha-promote-on-failure=always
  
• ha-sync-mode=manual
  
• cluster_partition_handling=ignore ( autoheal )
  
• 
  
• , , -

( ) :

• Publisher Confirms Manual Acknowledgements
  
• ha-promote-on-failure=when-synced , ! =always .
  
• ha-sync-mode=automatic ( ; , , )
  
• Pause Minority
  

; , (, ). Shovel.

- , , .

. , RabbitMQ Docker Blockade, , .

:
№1 — habr.com/ru/company/itsumma/blog/416629
№2 — habr.com/ru/company/itsumma/blog/418389
№3 — habr.com/ru/company/itsumma/blog/437446