दृश्यों के पीछे खरगोश एमक्यू क्लस्टरिंग और दर्पण कतार व्यवहार

Question

क्या कोई व्यक्ति कृपया बता सकता है कि एक गुलाम नोड को प्रकाशित करते समय प्रतिबिंबित फैशन में एकाधिक नोड्स और कतारों के साथ एक खरगोश एमक्यू क्लस्टर में दृश्यों के पीछे क्या चल रहा है?

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

लेकिन जब मैं गुलाम नोड को प्रकाशित करता हूं तो क्या होता है? क्या यह नोड मास्टर को संदेश भेजने की एक ही चीज़ करेगा?

ऐसा लगता है कि गुलामों से निपटने के दौरान बहुत सारे अतिरिक्त होप्स हैं, इसलिए ऐसा लगता है कि यदि आप केवल मास्टर को जानते हैं तो बेहतर प्रदर्शन हो सकता है। लेकिन आप मास्टर विफलता को कैसे संभालेंगे? तब दासों में से एक मास्टर को निर्वाचित किया जाएगा, इसलिए आपको पता होना चाहिए कि कहां से कनेक्ट करना है?

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

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

क्या इससे बचने का कोई तरीका है? या मुझे यह तय करना है कि क्या मैं कुछ संदेशों के दोहराव बनाम कुछ संदेश खो सकता हूं?

Answer 1

क्या कोई यह बता सकता है कि एक गुलाम नोड को प्रकाशित करते समय प्रतिबिंबित फैशन में एकाधिक नोड्स और कतारों के साथ एक खरगोश एमक्यू क्लस्टर में दृश्यों के पीछे क्या चल रहा है?

This ब्लॉग बिल्कुल बताता है कि क्या होता है।

लेकिन जब मैं गुलाम नोड को प्रकाशित करता हूं तो क्या होता है? क्या यह नोड मास्टर को संदेश भेजने की एक ही चीज़ करेगा?

संदेश मास्टर कतार में रीडायरेक्ट किया जाएगा - यानी, जिस नोड पर कतार बनाई गई थी।

लेकिन आप मास्टर विफलता को कैसे संभालेंगे? तब दासों में से एक मास्टर को निर्वाचित किया जाएगा, इसलिए आपको पता होना चाहिए कि कहां से कनेक्ट करना है?

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

खरगोश का कनेक्शन स्थायी है, इसलिए यदि यह विफल रहता है, तो आपको इसे फिर से बनाना होगा। साथ ही, आपको इन मामलों में संदेशों को फिर से भेजना होगा, अन्यथा आप उन्हें खो देंगे।

आपको अलग-अलग कनेक्शनों पर प्रतिक्रिया करने के लिए कनेक्शन-बाधित घटनाओं की सदस्यता लेने की आवश्यकता है। यह सुनिश्चित करने के लिए कि संदेश गुम नहीं हैं, आपको क्लाइंट पर कुछ स्तर की रिडंडेंसी बनाने की आवश्यकता होगी। मेरा सुझाव है, जैसा ऊपर है, कि आप विशेष रूप से RabbitMQ से पूछताछ करने के लिए डिज़ाइन की गई एक सेवा पेश करते हैं। आप क्लाइंट अंतिम ज्ञात सक्रिय कनेक्शन पर एक संदेश प्रकाशित करने का प्रयास कर सकते हैं, और यह असफल होना चाहिए, ग्राहक क्लाइंट एमक्यू क्लस्टर की अद्यतित सूची के लिए मॉनीटर सेवा से पूछ सकता है। यह मानते हुए कि कम से कम एक सक्रिय नोड है, क्लाइंट इसके बाद एक कनेक्शन स्थापित कर सकता है और संदेश सफलतापूर्वक प्रकाशित कर सकता है।

यहां तक ​​कि इस सब के साथ

, संदेश अभी भी, खो दिया जा सकता है क्योंकि वे पारगमन में हो सकता है जब मैं एक नोड को मारने

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

इससे पहले उपभोक्ता अनुप्रयोगों को समर्पण करने या आने वाले संदेशों को एक बेवकूफ तरीके से संभालने की आवश्यकता होगी।

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

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