दोष सहिष्णुता आणि उच्च उपलब्धता हे मोठे विषय आहेत, म्हणून आम्ही RabbitMQ आणि Kafka यांना स्वतंत्र लेख देऊ. हा लेख RabbitMQ बद्दल आहे आणि पुढचा लेख RabbitMQ च्या तुलनेत काफ्का बद्दल आहे. हा एक लांब लेख आहे, म्हणून स्वत: ला आरामदायक बनवा.

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

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

आम्हाला दिसेल की सुसंगतता आणि उपलब्धता स्पेक्ट्रमच्या विरुद्ध टोकांवर आहेत आणि तुम्हाला कोणता मार्ग ऑप्टिमाइझ करायचा हे निवडण्याची आवश्यकता आहे. चांगली बातमी अशी आहे की RabbitMQ सह ही निवड शक्य आहे. तुमच्याकडे अशा प्रकारचे "नर्डी" लीव्हर्स आहेत जे जास्त सुसंगततेकडे किंवा अधिक प्रवेशयोग्यतेकडे शिल्लक वळवतात.

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

सिंगल नोड लवचिकता आदिम

लवचिक रांग/राउटिंग

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

जेव्हा नोड रीस्टार्ट होतो तेव्हा अस्थिर रांग आणि राउटिंग काढले जातात.

सतत संदेश

केवळ रांग टिकाऊ आहे याचा अर्थ असा नाही की त्याचे सर्व संदेश नोड रीस्टार्टमध्ये टिकून राहतील. प्रकाशकाने केवळ असे संदेश सेट केले आहेत टिकाऊ (सतत). पर्सिस्टंट मेसेजमुळे ब्रोकरवर अतिरिक्त भार पडतो, पण जर मेसेजचे नुकसान अस्वीकार्य असेल, तर दुसरा पर्याय नाही.

तांदूळ. 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 वर रांगेत C साठी एक नवीन मिरर तयार केला गेला आहे. RabbitMQ नेहमी तुमच्या पॉलिसीमध्ये निर्दिष्ट प्रतिकृती घटक राखण्याचा प्रयत्न करते.

तांदूळ. 4. ब्रोकर 3 अयशस्वी झाला, ज्यामुळे रांग C अयशस्वी झाली

पुढील ब्रोकर 1 पडतो! आमच्याकडे फक्त एक दलाल शिल्लक आहे. रांग बी मिररला मास्टर म्हणून बढती दिली जाते.

अंजीर 5

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

या प्रकरणात, ब्रोकर 1 चे नुकसान पूर्ण झाले, जसे डेटा होता, त्यामुळे मिरर नसलेली रांग B पूर्णपणे गमावली.

तांदूळ. 6. ब्रोकर 1 सेवेत परत येतो

ब्रोकर 3 पुन्हा ऑनलाइन आहे, त्यामुळे रांग A आणि B त्यांच्या HA धोरणांचे समाधान करण्यासाठी त्यावर तयार केलेले आरसे परत मिळवतात. पण आता सर्व मुख्य रांगा एका नोडवर आहेत! हे आदर्श नाही, नोड्स दरम्यान समान वितरण चांगले आहे. दुर्दैवाने, मास्टर्सचे पुनर्संतुलन करण्यासाठी येथे फारसे पर्याय नाहीत. आम्ही नंतर या समस्येवर परत येऊ कारण आम्हाला प्रथम रांग सिंक्रोनाइझेशन पाहण्याची आवश्यकता आहे.

तांदूळ. 7. ब्रोकर 3 सेवेत परत येतो. एका नोडवर सर्व मुख्य रांगा!

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

समक्रमित करा

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

हे सिंक्रोनाइझेशन स्वयंचलितपणे किंवा व्यक्तिचलितपणे केले जाते आणि रांग धोरण वापरून व्यवस्थापित केले जाते. एक उदाहरण पाहू.

आमच्याकडे दोन मिरर केलेल्या रांगा आहेत. रांग A आपोआप सिंक्रोनाइझ केली जाते, आणि रांग B व्यक्तिचलितपणे सिंक्रोनाइझ केली जाते. दोन्ही रांगेत दहा संदेश आहेत.

तांदूळ. 8. वेगवेगळ्या सिंक्रोनाइझेशन मोडसह दोन रांगा

आता आम्ही ब्रोकर 3 गमावत आहोत.

तांदूळ. 9. दलाल 3 पडले

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

तांदूळ. 10. रांगेत A च्या नवीन मिररला सर्व विद्यमान संदेश प्राप्त होतात, परंतु रांगेच्या B च्या नवीन मिररला मिळत नाही.

दोन्ही रांगेत आणखी दहा संदेश येतात. ब्रोकर 2 नंतर क्रॅश होतो आणि Queue A सर्वात जुन्या मिररवर परत येतो, जो ब्रोकर 1 वर आहे. तो अयशस्वी झाल्यावर डेटा गमावत नाही. रांगेत बी, मास्टरमध्ये वीस संदेश आहेत आणि आरशात फक्त दहा आहेत कारण या रांगेने कधीही मूळ दहा संदेशांची प्रतिकृती केली नाही.

तांदूळ. 11. संदेश न गमावता रांग A ब्रोकर 1 वर परत येईल

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

आम्ही प्रवेशयोग्यता ऑप्टिमाइझ करू इच्छित असल्यास, नंतर धोरण ha-promote-on-failure मध्ये स्थापित केले पाहिजे नेहमी. हे डीफॉल्ट मूल्य आहे, त्यामुळे तुम्ही धोरण अजिबात निर्दिष्ट करू शकत नाही. या प्रकरणात, आम्ही अनिवार्यपणे असंक्रमित मिररमध्ये अपयशांना अनुमती देत ​​आहोत. यामुळे संदेश गमावले जातील, परंतु रांग वाचनीय आणि लिहिण्यायोग्य राहील.

तांदूळ. 12. संदेश न गमावता रांग A ब्रोकर 3 वर परत आणली जाते. दहा मेसेज गमावून रांग B ब्रोकर 3 वर परत येते

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

तांदूळ. 13. ब्रोकर 1 गमावल्यानंतर रांग B अनुपलब्ध राहते

तुम्ही विचारू शकता, "स्वयंचलित सिंक्रोनाइझेशन कधीही न वापरणे चांगले आहे का?" उत्तर असे आहे की सिंक्रोनाइझेशन हे ब्लॉकिंग ऑपरेशन आहे. सिंक्रोनाइझेशन दरम्यान, मुख्य रांग कोणतेही वाचन किंवा लेखन ऑपरेशन करू शकत नाही!

एक उदाहरण पाहू. आता खूप लांब रांगा लागल्या आहेत. ते इतक्या आकारात कसे वाढू शकतात? अनेक कारणांमुळे:

• रांगा सक्रियपणे वापरल्या जात नाहीत
• या हाय-स्पीड रांगा आहेत आणि सध्या ग्राहक मंद आहेत
• ही हाय-स्पीड रांग आहे, एक त्रुटी आहे आणि ग्राहक पकडत आहेत

तांदूळ. 14. वेगवेगळ्या सिंक्रोनाइझेशन मोडसह दोन मोठ्या रांगा

आता ब्रोकर 3 पडतो.

तांदूळ. 15. ब्रोकर 3 फॉल्स, प्रत्येक रांगेत एक मास्टर आणि मिरर सोडून

ब्रोकर 3 पुन्हा ऑनलाइन येतो आणि नवीन मिरर तयार केले जातात. मुख्य रांग A नवीन मिररवर विद्यमान संदेशांची प्रतिकृती करण्यास सुरवात करते आणि या काळात रांग अनुपलब्ध असते. डेटाची प्रतिकृती तयार करण्यासाठी दोन तास लागतात, परिणामी या रांगेसाठी दोन तासांचा डाउनटाइम!

तथापि, रांग B संपूर्ण कालावधीत उपलब्ध राहते. तिने प्रवेशयोग्यतेसाठी काही अनावश्यकतेचा त्याग केला.

तांदूळ. 16. सिंक्रोनाइझेशन दरम्यान रांग अनुपलब्ध राहते

दोन तासांनंतर, रांग A देखील उपलब्ध होईल आणि पुन्हा वाचणे आणि लिहिणे स्वीकारणे सुरू करू शकते.

अद्यतने

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

• always= असंक्रमित मिररमध्ये संक्रमण सक्षम केले आहे
• when-synced= फक्त सिंक्रोनाइझ केलेल्या मिररमध्ये संक्रमण, अन्यथा रांग वाचनीय आणि लिहिण्यायोग्य बनते. दलाल परत येताच रांग पुन्हा सेवेत येते

एक ना एक मार्ग, मोठ्या रांगांसह तुम्हाला डेटा गमावणे आणि अनुपलब्धता यापैकी एक निवडावा लागेल.

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

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

येथे आपण खालील गोष्टींचा विचार करणे आवश्यक आहे:

• प्रकाशक फक्त एरर परत करू शकतो आणि अपस्ट्रीम सेवा किंवा वापरकर्त्याने नंतर पुन्हा प्रयत्न करू शकतो?
• नंतर पुन्हा प्रयत्न करण्यासाठी प्रकाशक संदेश स्थानिकरित्या किंवा डेटाबेसमध्ये सेव्ह करू शकतो का?

जर प्रकाशक फक्त संदेश टाकून देऊ शकत असेल, तर प्रत्यक्षात, प्रवेशयोग्यता सुधारल्याने डेटा सुरक्षितता देखील सुधारते.

अशा प्रकारे, समतोल शोधला पाहिजे आणि उपाय विशिष्ट परिस्थितीवर अवलंबून असतो.

ha-promote-on-failure=when-sync करताना समस्या

आयडिया ha-promote-on-failure= जेव्हा-सिंक केले जाते आम्ही असंक्रमित मिररवर स्विच करणे प्रतिबंधित करतो आणि त्याद्वारे डेटा गमावणे टाळतो. रांग वाचनीय किंवा लिहिण्यायोग्य राहते. त्याऐवजी, आम्ही क्रॅश झालेल्या ब्रोकरला त्याच्या डेटासह पुनर्प्राप्त करण्याचा प्रयत्न करतो जेणेकरून तो डेटा गमावल्याशिवाय मास्टर म्हणून पुन्हा कार्य करू शकेल.

परंतु (आणि हे एक मोठे आहे परंतु) जर ब्रोकरने त्याचा डेटा गमावला असेल, तर आमच्याकडे एक मोठी समस्या आहे: रांग हरवली आहे! सर्व डेटा गेला! तुमच्याकडे आरसे असले तरीही ते मुख्य रांगेला पकडतात, ते आरसे देखील टाकून दिले जातात.

त्याच नावाचा नोड पुन्हा जोडण्यासाठी, आम्ही क्लस्टरला हरवलेला नोड विसरण्यास सांगतो (कमांडसह rabbitmqctl forget_cluster_node) आणि त्याच होस्टनावाने नवीन ब्रोकर सुरू करा. क्लस्टर हरवलेला नोड लक्षात ठेवत असताना, तो जुनी रांग आणि असंक्रमित मिरर लक्षात ठेवतो. जेव्हा एखाद्या क्लस्टरला अनाथ नोड विसरण्यास सांगितले जाते तेव्हा ती रांग देखील विसरली जाते. आता आपल्याला ते पुन्हा घोषित करावे लागेल. आमच्याकडे डेटाच्या आंशिक संचासह मिरर असले तरीही आम्ही सर्व डेटा गमावला. नॉन-सिंक्रोनाइज्ड मिररवर स्विच करणे चांगले होईल!

म्हणून, सह संयोजनात मॅन्युअल सिंक्रोनाइझेशन (आणि सिंक्रोनाइझ करण्यात अयशस्वी). 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 च्या कार्यक्षमतेत दोष-सहिष्णु आणि अत्यंत उपलब्ध संदेश तंत्रज्ञान म्हणून सुधारणा होईल. खालील परिस्थितींमध्ये क्लस्टरिंगसह 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 (परंतु मोठ्या निष्क्रिय रांगांसाठी मॅन्युअल मोड आवश्यक असू शकतो; अनुपलब्धतेमुळे संदेश गमावले जातील की नाही याचा देखील विचार करा)
• अल्पसंख्याक मोडला विराम द्या
• सतत संदेश

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

माझे आणखी काही चुकले असल्यास, कृपया मला कळवा.

माझे देखील पहा पोस्ट, जिथे मी या लेखात वर्णन केलेल्या संदेश गमावण्याच्या परिस्थितीची चाचणी घेण्यासाठी डॉकर आणि ब्लॉकेड वापरून 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