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