दोष सहिष्णुता र उच्च उपलब्धता ठूला विषयहरू हुन्, त्यसैले हामी 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 पतन! हामीसँग एक दलाल मात्र बाँकी छ। क्युउ बी मिरर मास्टरमा पदोन्नति गरिएको छ।

Рис। १

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

यस अवस्थामा, ब्रोकर 1 को हानि पूरा भयो, जस्तै डाटा थियो, त्यसैले अनमिरर गरिएको कतार B पूर्ण रूपमा हराएको थियो।

चामल। 6. ब्रोकर 1 सेवामा फर्कन्छ

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

चामल। 7. ब्रोकर 3 सेवामा फर्कन्छ। एक नोडमा सबै मुख्य लामहरू!

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

सिङ्क

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

यो सिङ्क्रोनाइजेसन स्वतः वा म्यानुअल रूपमा गरिन्छ र लाम नीति प्रयोग गरेर व्यवस्थित गरिन्छ। एउटा उदाहरण हेरौं।

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

चामल। 8. विभिन्न सिंक्रोनाइजेसन मोडहरूसँग दुई लामहरू

अब हामी ब्रोकर 3 गुमाइरहेका छौं।

चामल। 9. ब्रोकर 3 घट्यो

ब्रोकर ३ सेवामा फर्कन्छ। क्लस्टरले नयाँ नोडमा प्रत्येक लामको लागि मिरर सिर्जना गर्दछ र स्वचालित रूपमा मास्टरसँग नयाँ लाम A लाई सिङ्क्रोनाइज गर्दछ। यद्यपि, नयाँ कतार बी को ऐना खाली रहन्छ। यस तरिकाले हामीसँग कतार A मा पूर्ण रिडन्डन्सी छ र अवस्थित कतार B सन्देशहरूको लागि मात्र एउटा ऐना छ।

चामल। 10. लाम A को नयाँ मिररले सबै अवस्थित सन्देशहरू प्राप्त गर्दछ, तर पङ्क्ति B को नयाँ मिररले प्राप्त गर्दैन।

दुबै लाइनमा दस थप सन्देशहरू आइपुग्छन्। ब्रोकर 2 त्यसपछि क्र्यास हुन्छ र लाइन A सबैभन्दा पुरानो मिररमा फिर्ता हुन्छ, जुन ब्रोकर 1 मा छ। यो असफल हुँदा कुनै डेटा हानि हुँदैन। कतार B मा, मास्टरमा बीस सन्देशहरू छन् र ऐनामा दस मात्र छन् किनभने यो लामले मूल दस सन्देशहरू कहिल्यै नक्कल गरेको छैन।

चामल। 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. फरक सिङ्क्रोनाइजेसन मोडहरूसँग दुई ठूला लामहरू

अब ब्रोकर ३ खस्छ ।

चामल। 15. प्रत्येक लाममा एक मास्टर र मिरर छोडेर, ब्रोकर 3 झर्छ

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

यद्यपि, कतार B सम्पूर्ण अवधिभर उपलब्ध रहन्छ। उनले पहुँचको लागि केही अनावश्यकता त्यागिन्।

चामल। 16. सिङ्क्रोनाइजेसनको बेला लाम अनुपलब्ध रहन्छ

दुई घण्टा पछि, लाम A पनि उपलब्ध हुन्छ र पढ्न र लेख्न स्वीकार गर्न सुरु गर्न सक्छ।

अद्यावधिकहरू

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

• always= सिङ्क्रोनाइज्ड मिररहरूमा संक्रमण सक्षम छ
• when-synced= सिङ्क्रोनाइज्ड मिररमा मात्र संक्रमण, अन्यथा लाम पढ्न नसकिने र लेख्न नसकिने हुन्छ। दलाल फर्कने बित्तिकै लाम सेवामा फर्कन्छ

एक तरिका वा अर्को, ठूला लामहरूको साथ तपाईंले डेटा हानि र अनुपलब्धता बीच छनौट गर्नुपर्छ।

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

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

यहाँ तपाईंले निम्न विचार गर्न आवश्यक छ:

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

यदि प्रकाशकले सन्देशलाई मात्र खारेज गर्न सक्छ भने, वास्तवमा, पहुँच सुधार गर्नाले डाटा सुरक्षामा पनि सुधार हुन्छ।

तसर्थ, सन्तुलन खोज्नु पर्छ, र समाधान विशिष्ट परिस्थितिमा निर्भर गर्दछ।

ha-promote-on-failure = जब-समक्रमणको साथ समस्याहरू

आइडिया 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 प्रयोग गरेर असफल/निलम्बित नोडबाट ट्राफिक हटाउनुहोस्। यो सानो TTL प्रयोग गरी गरिन्छ।

निष्कर्ष

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 क्लस्टरमा विनाश गर्छु।

यस श्रृंखलामा अघिल्लो लेखहरू:
नम्बर १ - habr.com/ru/company/itsumma/blog/416629
नम्बर १ - habr.com/ru/company/itsumma/blog/418389
नम्बर १ - habr.com/ru/company/itsumma/blog/437446

स्रोत: www.habr.com