🌇 🤷🏻 🧚🏼 अत्यधिक उपलब्ध क्लस्टर खरगोश 🧔🏿 🥘 🌓

RabbitMQ को जानें

हेबेरा पर अनुवाद:
RabbitMQ ट्यूटोरियल 1 - हैलो वर्ल्ड
RabbitMQ ट्यूटोरियल 2 - टास्क कतार
RabbitMQ ट्यूटोरियल 3 - प्रकाशित / सदस्यता लें

कुछ कमियों को तुरंत पूरक करें। और मूल शब्दों को संक्षेप में दोहराएं।

आर्किटेक्चर rabbitMq का उपयोग करके कैसे काम करता है

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

राउटिंग कुंजी या संदेश हेडर का उपयोग करके कतार विनिमय बिंदु से जुड़ी होती है।

रूटिंग कुंजी - वह मान जो उस समय निर्दिष्ट किया जाता है जब संदेश को एक्सचेंज बिंदु पर प्रकाशित किया जाता है, उस कतार को निर्धारित करने के लिए कार्य करता है जिससे संदेश गिर जाएगा।

संदेश शीर्षलेख एक संदेश के साथ जुड़े कुंजी-मूल्य तर्क का एक सेट है।

विनिमय बिंदु 4 प्रकार के हो सकते हैं:

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

प्रत्येक कतार में अपने व्यवहार को परिभाषित करने वाले 4 झंडे होते हैं:

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

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

RabbitMQ कॉन्फ़िगरेशन

RabbitMQ सर्वर ऑपरेशन कॉन्फ़िगरेशन तीन स्थानों पर स्थित है, ये पर्यावरण चर (पोर्ट और स्थान और फ़ाइल नाम सेट हैं), कॉन्फ़िगरेशन फ़ाइलें (एक्सेस सेटिंग्स, क्लस्टर, प्लग-इन), और रनटाइम (नीतियों, प्रदर्शन सेटिंग्स) में निर्दिष्ट सेटिंग्स हैं।

Windows पर स्थापित करते समय, कॉन्फ़िगरेशन फ़ाइल नहीं बनाई गई है, इसका केवल एक उदाहरण है जो \ rabbitmq_server-3.2.0 \ etc \ rabbitmq.config.example निर्देशिका में स्थित है। हम अपनी कॉन्फ़िगरेशन फ़ाइल बनाते हैं, इसे rabbitmq.config कहते हैं (एक्सटेंशन .config, और कुछ नहीं!) है, और इसे साधारण सेटिंग्स से भरें:

%% Sample [ {rabbit, [ {tcp_listeners, [5672]}, {log_levels, [{connection, error}]}, {default_vhost, <<"/">>}, {default_user, <<"username">>}, {default_pass, <<"password">>}, {default_permissions, [<<".*">>, <<".*">>, <<".*">>]}, {heartbeat, 60}, {frame_max, 1048576} ]} ].

फ्रेमिंग << >> कोई गलती नहीं है, ऐसा होना चाहिए।
सेटिंग्स में टिप्पणियाँ एक दोहरे प्रतिशत प्रतीक से पहले होती हैं - %%।

अब हम फाइल को एक सुविधाजनक जगह पर रखते हैं, उदाहरण के लिए, रैबिटएमक्यू सर्वर के साथ रूट फ़ोल्डर में, उदाहरण के लिए, एक रास्ता हो।
c: \ rabbitmq \ rabbitmq.config

RabbitMq को कॉन्फ़िगरेशन फ़ाइल देखने के लिए, आपको इसके स्थान के साथ एक पर्यावरण चर बनाना होगा

 RABBITMQ_CONFIG_FILE = c:\rabbitmq\rabbitmq

यह उपयोगकर्ता के वातावरण और सिस्टम के वातावरण में एक चर बनाने के लायक है।
हम फ़ाइल नाम का पथ लिखते हैं, हम एक्सटेंशन को ट्रिम करते हैं। फ़ाइल कॉन्फिगरेशन बनाना और पर्यावरण को स्थापित करना RabbitMQ सर्वर को स्थापित करने से पहले या इसके बाद पुनः स्थापित करने से पहले किया जाता है। (पर्यावरण परिवर्तन के लिए सेवा को फिर से स्थापित करने के लिए प्रभावी होना चाहिए।) एक सरल पुनरारंभ मदद नहीं करता है।

अब आप Erlang और RabbitMQ सर्वर स्थापित कर सकते हैं।

क्लस्टर बनाएँ और कॉन्फ़िगर करें

सावधानी

      ,      RabbitMQ : RabbitMQ\RabbitMQ Server\rabbitmq_server-3.2.1\sbin

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

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

 %WINDOWS%\.erlang.cookie

और जिस तरह से साथ प्रतिस्थापन के साथ इसे कॉपी करें

 C:\Users\%CurrentUser%\.erlang.cookie

, जिसके बाद हम निर्दिष्ट रास्तों में प्रत्येक क्लस्टर नोड के प्रतिस्थापन के साथ कॉपी करते हैं।

क्लस्टर प्रत्येक दास पर निम्न आदेशों को निष्पादित करके बनाया गया है:

 rabbitmqctl stop_app rabbitmqctl join_cluster --ram rabbit@master rabbitmqctl start_app

या कॉन्फ़िगरेशन फ़ाइल में निर्दिष्ट करके:

 {cluster_nodes, {["rabbit@master", "rabbit@host01"], disc}}

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

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

सिंक नीतियां

हम टूल में जाते हैं और रनटाइम में निम्न कमांड निष्पादित करते हैं:

 rabbitmqctl set_policy HA ".*" "{""ha-mode"": ""all""}"

अब उनमें से सभी कतारें और संदेश सिंक्रनाइज़ किए जाएंगे। जब कोई संदेश प्रकाशित होता है, तो यह क्लस्टर के सभी नोड्स में कॉपी करने के बाद ही ग्राहकों के लिए उपलब्ध होता है।

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

क्लाइंट एप्लिकेशन के क्लस्टर से कनेक्ट करें।

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

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

उपयोगिता

हम कमांड लाइन से नोड को पिंग करते हैं:

 rabbitmqctl eval "net_adm:ping(rabbit@hostname)."

यदि नोड उपलब्ध है तो हमें उत्तर पोंग मिलता है

अत्यधिक उपलब्ध क्लस्टर खरगोश