विश्वसनीयता के साथ रेडिस पब/सब

Question

मैं रेडिस पब/सब का उपयोग खरगोश एमक्यू के प्रतिस्थापन के रूप में कर रहा हूं।

मेरी समझ से रेडिस के पब/उप में प्रत्येक ग्राहक के लिए लगातार कनेक्शन होता है, और यदि कनेक्शन समाप्त हो जाता है, तो सभी भविष्य के संदेश खो जाएंगे और फर्श पर गिराए जाएंगे।

एक संभावित समाधान एक संदेश (और प्रतीक्षा अवरुद्ध) का उपयोग करना है ताकि सभी संदेश और पब/उप को केवल एक अधिसूचना तंत्र के रूप में स्टोर किया जा सके। मुझे लगता है कि यह मुझे सबसे ज्यादा रास्ते में ले जाता है, लेकिन मुझे अभी भी विफलता के मामलों के बारे में कुछ चिंताएं हैं।

1. क्या होता है जब कोई ग्राहक मर जाता है, और ऑनलाइन वापस आता है, तो यह अपने सभी लंबित संदेशों को कैसे संसाधित करना चाहिए?
2. जब एक विकृत संदेश सिस्टम के बावजूद आता है, तो आप उन अपवादों को कैसे संभालेंगे? DeadLetter कतार?
3. क्या एक पुनः प्रयास नीति लागू करने के लिए एक मानक अभ्यास है?

Answer 1

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

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

पुनः प्रयास नीतियां आपकी आवेदन आवश्यकताओं पर निर्भर करती हैं। अगर आपको 100% आश्वासन की आवश्यकता है कि एक संदेश प्राप्त हुआ है और संसाधित किया गया है, तो आपको उपभोक्ता द्वारा किए गए काम को लपेटने के लिए रेडिस लेनदेन (बहु/EXEC) का उपयोग करने पर विचार करना चाहिए, ताकि आप यह सुनिश्चित कर सकें कि कोई ग्राहक तब तक कोई संदेश नहीं हटाता यह अपना काम पूरा कर लिया है। अगर आपको स्पष्ट स्वीकृति की आवश्यकता है, तो आप निर्माता प्रक्रिया (एसएस) को समर्पित कतार पर एक स्पष्ट एसीके संदेश का उपयोग कर सकते हैं।

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

Answer 2

मैंने जो किया वह टाइमस्टैम्प का उपयोग करके सॉर्ट किए गए सेट का उपयोग स्कोर के रूप में और सदस्य के मूल्य के रूप में डेटा की कुंजी के रूप में किया जाता है। मैं अगले कुछ आइटम को पुनर्प्राप्त करने के लिए अंतिम आइटम से स्कोर का उपयोग करता हूं और फिर चाबियाँ प्राप्त करता हूं। एक बार काम पूरा हो जाने के बाद मैं ज़र्म और डेल दोनों को बहु/EXEC लेनदेन में लपेटता हूं।

अनिवार्य रूप से एडवर्ड ने क्या कहा, लेकिन सॉर्ट किए गए सेट में चाबियाँ संग्रहीत करने के मोड़ के साथ, क्योंकि मेरे संदेश बहुत बड़े हो सकते हैं।

आशा है कि इससे मदद मिलती है!

Answer 3

यदि आप एक पब/सब सिस्टम चाहते हैं जहां ग्राहक मरने पर संदेश खो नहीं पाएंगे, तो रेडिस पब/उप के बजाय Redis Streams का उपयोग करने पर विचार करें।

रेडिस स्ट्रीम के पास अपनी खुद की वास्तुकला और पेशेवर/विपक्ष रेडिस पब/उप के लिए है। रेडिस स्ट्रीम के साथ, एक ग्राहक कमांड जारी कर सकता है:

मुझे प्राप्त अंतिम संदेश एक्स था, अब मुझे अगला संदेश दें; यदि कोई नया संदेश नहीं है, तो किसी के आने के लिए प्रतीक्षा करें।

ऊपर से जुड़े एंटीरेज़ का आलेख अधिक जानकारी के साथ रेडिस स्ट्रीम के लिए एक अच्छा परिचय है।

चेतावनी: यह सुविधा केवल रेडिस के अस्थिर (बीटा) संस्करण में मौजूद है।