उच्च उपलब्धता वाले Redis क्लस्टर में विश्वसनीय PUBSUB और ब्लॉकिंग लिस्ट ऑपरेशन सुनिश्चित करना

मानक रिडंडेंट Redis समाधान मास्टर/स्लेव रेप्लिकेशन चलाना है जिसमें Sentinel फेलओवर का प्रबंधन करता है। इसके बाद या तो a) क्लाइंट सपोर्ट और वर्तमान मास्टर की खोज के लिए Sentinel का उपयोग या b) Redis पॉड के सामने एक TCP प्रॉक्सी जो Sentinel द्वारा मास्टर की ओर इंगित करने के लिए प्रबंधित किया जाता है। पूर्व वह तरीका है जिस तरह से Redis Sentinel डिज़ाइन किया गया है और बाद वाला एक बढ़ती प्रवृत्ति है - और ObjectRocket Redis को कॉन्फ़िगर करने का तरीका।

Redis में कमांड पर फेलओवर के प्रभाव

अधिकांश Redis ऑपरेशंस के लिए यह अपेक्षा के अनुरूप काम करता है। फेलओवर पर क्लाइंट कोड से कनेक्शन विफल होने का पता लगाने और या तो a) वर्तमान मास्टर को देखने और पुनः कनेक्ट करने या b) ऊपर वर्णित परिदृश्यों के आधार पर पुनः कनेक्ट करने का प्रयास करने की अपेक्षा की जाती है। प्रॉक्सी-आधारित परिदृश्य Redis सर्वर रीस्टार्ट के समान है इसलिए यह उस मामले पर भी लागू होता है जहां आपके पास एक सिंगल इंस्टेंस Redis है जिसे रीस्टार्ट किया जा सकता है।

हालांकि Redis कमांड का एक छोटा सा मुट्ठी भर लॉन्ग-टर्म ब्लॉकिंग या नॉन-एटॉमिक हैं। PUBSUB सब्सक्राइब और psubscribe कमांड नॉन-एटॉमिक हैं जिसमें कमांड दिए गए चैनल(ल) पर प्रकाशित किसी भी संदेश को इसे भी भेजे जाने के लिए अनुरोध दर्ज करेगा, लेकिन वास्तविक डेटा बहुत बाद में आ सकता है - यानी इसे प्रकाशित करने के बाद। BL* कमांड लॉन्ग-टर्म और टू-फेज कमांड हैं जिसमें सब्सक्राइब कमांड की तरह वे ब्लॉक करेंगे और तब तक वापस नहीं लौटेंगे जब तक लिस्ट में हटाने के लिए कोई आइटम उपलब्ध न हो।

इन कमांड्स के बीच एक प्रमुख समानता यह है कि वे जारी किए जाते हैं और सर्वर पर पंजीकरण का एक रूप किया जाता है, लेकिन डेटा बाद में आ सकता है। कमांड जारी होने और सर्वर के पास जवाब देने के लिए डेटा होने के बीच फेलओवर और रीस्टार्ट हो सकते हैं। रीस्टार्ट या फेलओवर के मामले में "पंजीकरण" अब सर्वर पर नहीं है। यह हमें इन परिदृश्यों में इन कमांड्स के संबंध में क्या होता है, इस सवाल पर लाता है।

उन विवरणों में जाने से पहले एक और पहलू उठाना है क्योंकि यह टेस्टिंग के दौरान खेल में आएगा और परिणामों पर नाटकीय प्रभाव डालेगा और विफलता परिदृश्यों के लिए कैसे कोड करना है। वास्तव में दो प्रकार के फेलओवर हैं। वह फेलओवर है जिस पर हममें से अधिकांश विचार करते हैं - मास्टर का नुकसान। इस प्रकार के फेलओवर में मास्टर नॉन-रिस्पॉन्सिव होता है। मैं इसे "ट्रिगर्ड फेलओवर" के रूप में संदर्भित करता हूं। फेलओवर का दूसरा वर्ग जिसे मैं "इनिशिएटेड फेलओवर" के रूप में संदर्भित करता हूं।

इनिशिएटेड फेलओवर तब होता है जब एक एडमिनिस्ट्रेटर एक Sentinel को sentinel failover कमांड भेजता है जो तब पॉड को पुनः कॉन्फ़िगर करता है, एक मास्टर को प्रमोट करता है फिर मूल मास्टर को डिमोट करता है। सतह पर ये दो परिदृश्य समान दिखाई देते हैं। अधिकांश Redis कमांड के मामले में उन्हें समान माना जा सकता है। हालांकि, हमारे लॉन्ग-ब्लॉक कमांड के मामले में उन्हें अपने स्वयं के संदर्भ में समझा जाना चाहिए।

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

यहां चर्चा की गई तकनीकों और परिदृश्यों को सामान्य रूप से वर्णित किया जाएगा और Python Redis लाइब्रेरी "redis-py" का उपयोग करके प्रदर्शित किया जाएगा, लेकिन किसी भी क्लाइंट लाइब्रेरी पर लागू होते हैं। पृष्ठभूमि हाथ में होने के साथ, आइए अब देखें कि यह लॉन्ग-ब्लॉक कमांड के उपयोग को कैसे प्रभावित करता है। पहले PUBSUB को देखते हैं।

PUBSUB

Redis PUBSUB में तीन कमांड होते हैं: PUBLISH, SUBSCRIBE, और PSUBSCRIBE। पहली कमांड एक संदेश भेजने के लिए उपयोग की जाती है जबकि बाद वाली दो PUBLISH कमांड के माध्यम से प्रकाशित संदेशों के लिए पंजीकरण और प्राप्त करने के लिए उपयोग की जाती हैं। पहले, आइए जांचें कि PUBLISH कमांड में क्या होता है।

जब आप PUBLISH निष्पादित करते हैं तो यह दिए गए चैनल पर तुरंत संदेश प्रकाशित करेगा और इसे प्राप्त करने वाले क्लाइंट्स की संख्या वापस करेगा। किस तरह से एक विफलता परिदृश्य इसे प्रासंगिकता में लाता है? फेलओवर के मामले पर विचार करें। क्लाइंट को फिर से कनेक्ट करना होगा क्योंकि TCP कनेक्शन दूर चला जाता है। यदि प्रॉक्सी से बात कर रहे हैं तो यह एक डायरेक्ट रीकनेक्ट करेगा और एक अलग सर्वर प्राप्त करेगा। यदि Sentinel डिस्कवरी कर रहे हैं तो इसमें थोड़ा अधिक समय लगेगा और फिर भी एक अलग सर्वर से कनेक्ट होगा। जहां समस्या टाइमिंग में निहित है। यदि प्रकाशक किसी भी सब्सक्राइबर से पहले नए सर्वर से कनेक्ट होता है, तो संदेश चला गया - खो गया। लेकिन क्या ऐसा हो सकता है? इसे समझने के लिए हम SUBSCRIBE कमांड्स को देखते हैं।

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

पहला प्रकाशक इस तथ्य का लाभ उठा सकता है कि PUBLISH इसे प्राप्त करने वाले क्लाइंट्स की संख्या लौटाता है। यदि शून्य क्लाइंट्स ने इसे प्राप्त किया तो प्रकाशक पुनः प्रयास कर सकता है। उन प्रणालियों के लिए जहां यह सब्सक्राइबर्स की एक स्थिर संख्या है या जहां "कम से कम एक सब्सक्राइबर" पर्याप्त है यह संदेश हानि को रोकेगा। उन प्रणालियों के लिए जो इस मानदंड को पूरा नहीं करते हैं, एक और, यदि कम मजबूत, विकल्प है।

दूसरा विकल्प रीकनेक्ट विंडोज को नियंत्रित करना है। यहां अंगूठे का नियम है कि प्रकाशक देरी सब्सक्राइबर देरी से कम से कम तीन गुना लंबी हो। यह सब्सक्राइबर्स के प्रकाशन से पहले पुनः कनेक्ट होने के लिए कम से कम तीन अवसर प्रदान करेगा। जब तक सब्सक्राइबर्स पहले ऑनलाइन हैं, संदेश ईथर में नहीं जाएंगे। हालांकि, इसे नियंत्रित न करने की तुलना में अधिक मजबूत होने पर अभी भी संदेश हानि की संभावना है।

तीसरा विकल्प जिसे मैं इस रेस कंडीशन को कम करने के लिए प्रस्तुत करूंगा वह एक लॉक मैकेनिज्म में निर्माण करना है। यह निश्चित रूप से सबसे जटिल मार्ग है क्योंकि इसके लिए एक मैकेनिज्म के निर्माण या नियोजित करने की आवश्यकता होती है जो प्रकाशकों को तब तक प्रकाशित करने से रोकता है जब तक क्लाइंट कनेक्ट न हो जाएं। मूल प्रक्रिया कुछ साझा स्थान (जैसे Zookeeper के माध्यम से, एक डेटाबेस, Consul, आदि) में है जहां सब्सक्राइबर्स पंजीकृत करते हैं कि वे प्राप्त करने के लिए तैयार हैं और प्रकाशक संदेश प्रकाशित करने से पहले वैध और तैयार सब्सक्राइबर्स की जांच करते हैं। जटिलता को और बढ़ाने के लिए सब्सक्राइबर्स को इस मैकेनिज्म में खुद को "अनसेट" करना होगा जब वे TCP कनेक्शन खो देते हैं।

यह बताया जाना चाहिए कि यह सब ट्रिगर्ड फेलओवर के लिए है। यह काम करेगा क्योंकि मास्टर नॉन-रिस्पॉन्सिव है इस प्रकार कोई संदेश इस पर नहीं जाता है। इनिशिएटेड फेलओवर परिदृश्य में मास्टर संदेशों को स्वीकार करना जारी रखेगा जब तक कि यह मास्टर नहीं रह जाता या डिस्कनेक्ट नहीं हो जाता। उपरोक्त विधियों में से कोई भी इस परिदृश्य को पूरी तरह से और उचित रूप से पकड़ नहीं पाएगा।

इनिशिएटेड फेलओवर के मामले में (जो सिस्टम रखरखाव के दौरान हो सकते हैं) आपका सबसे अच्छा बचाव पहले और दूसरे दोनों विकल्पों को नियोजित करना है, और स्वीकार करना है कि संदेश हानि हो सकती है। कितनी संदेश हानि पूरी तरह से आपके प्रकाशन शेड्यूल पर निर्भर करती है। यदि आप औसतन हर कुछ मिनट में एक संदेश प्रकाशित करते हैं तो आपके लिए वास्तव में हानि विंडो का सामना करने की बहुत कम संभावना है। प्रकाशन अंतराल जितना बड़ा होगा जोखिम उतना ही छोटा होगा। इसके विपरीत यदि आप प्रति सेकंड सैकड़ों या हजारों संदेश प्रकाशित कर रहे हैं तो आप निश्चित रूप से कुछ खो देंगे। प्रबंधित प्रॉक्सी परिदृश्य के लिए यह इस बात पर निर्भर करेगा कि आपके प्रॉक्सी में फेलओवर कितनी जल्दी पूरा होता है। ObjectRocket के Redis प्लेटफॉर्म के लिए यह विंडो 1.5 सेकंड तक है।

अंतराल पर एक दृष्टिकोण, जो सीमाओं पर विफल होता है, सब्सक्राइबर्स को आपके प्रकाशन अंतराल के 1/3d पर पुनः कनेक्ट करने का प्रयास करने के लिए है। इस प्रकार यदि आप प्रति मिनट एक संदेश प्रकाशित करते हैं, तो अपने सब्सक्राइबर्स को कम से कम हर 20 सेकंड में पुनः कनेक्ट करने के लिए कोड/कॉन्फ़िगर करें और आपके प्रकाशक हर मिनट या दो में। जैसे-जैसे प्रकाशन अंतराल 3 सेकंड के निशान के करीब आता है यह प्राप्त करना कठिन हो जाता है क्योंकि फेलओवर रीकनेक्ट प्रक्रिया (लुकअप्स, TCP हैंडशेक, AUTH, SUBSCRIBE, आदि) आसानी से कुछ सेकंड तक कुल कर सकती है।

BLPOP और दोस्त

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

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

BRPOPLPUSH करने वाले वर्कर के मामले में, परिणाम ऐसा होगा कि फेलओवर के बाद स्थानांतरित किया जा रहा आइटम अपनी मूल स्थिति में "वापस" आ जाएगा। BLPOP के मामले में परिणाम अनिवार्य रूप से समान होगा। फेलओवर पूरा होने के बाद आइटम फिर से कतारबद्ध दिखाई देगा। यदि आपके आइटम आइडेम्पोटेंट जॉब्स हैं, तो यह एक मुद्दा नहीं होगा। नॉन-आइडेम्पोटेंट जॉब्स के मामले में इसके लिए आपको कितना डिफेंसिव कोडिंग करना चाहिए, यह एक जॉब के दो बार चलने या आइटम के दो बार प्रोसेस होने के प्रभाव को निर्धारित करने का परिणाम है, इस बात को ध्यान में रखते हुए कि आप कितनी बार संशोधन कर रहे हैं और इस प्रकार इस स्थिति का सामना करने की संभावना। यह भी ध्यान दिया जाना चाहिए कि चूंकि यह केवल इनिशिएटेड फेलओवर की स्थिति में होता है यह ऑपरेशनल कंट्रोल में कुछ होना चाहिए और मैं सलाह दूंगा कि जब भी संभव हो रखरखाव उस समय किया जाए जब आपके सिस्टम अपने सबसे कम उपयोग पर हों ताकि इस संभावना को कम या खत्म किया जा सके।

ट्रिगर्ड फेलओवर के लिए डेटा हानि की कोई उम्मीद नहीं है। एक ट्रिगर्ड फेलओवर तब होता है जब मास्टर अनुत्तरदायी होता है, इस प्रकार मास्टर पर कोई संशोधन नहीं किया जा रहा है। हालांकि, इनमें से प्रत्येक परिदृश्य के साथ वास्तविक TCP रीकनेक्ट को संभालने का मामला है जो किसी भी फेलओवर परिदृश्य में अनिवार्य है।

क्लाइंट रीकनेक्शन

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

पुनः कनेक्ट पर किसी भी सब्सक्राइबर को फिर से सब्सक्राइब करना होगा क्योंकि अनुरोधित चैनलों और नए TCP कनेक्शन के बीच लिंक स्थापित किया जाना चाहिए। चूंकि Redis के PUBSUB चैनल तब बनाए जाते हैं जब कोई सब्सक्राइबर या प्रकाशक उन तक पहुंचने का प्रयास करता है, चैनल को "पुनः बनाने" की कोई आवश्यकता नहीं है।

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

पहली अच्छी खबर यह है कि redis-py कनेक्शन गिरने पर पुनः प्रयास करता हुआ प्रतीत होता है। दुर्भाग्य से यह तुरंत पुनः प्रयास करता है, और इस प्रकार फेलओवर के दौरान कनेक्शन को विश्वसनीय रूप से पुनर्प्राप्त करने के लिए बहुत तेज है। आगे ऐसा प्रतीत होता है कि इसे कॉन्फ़िगर करने का कोई तरीका नहीं है। परिणामस्वरूप आपका कोड विफल पुनः प्रयास प्रयास को पकड़/पता लगाना चाहिए और पुनः कनेक्ट को स्वयं प्रबंधित करना चाहिए।

पहले आइए कुछ मानक redis-py प्रकाशक और सब्सक्राइबर कोड ब्लॉक्स की जांच करें:

### Publisher example code
r.publish(channel,message)

### Subscriber example code
p = r.pubsub()
p.subscribe(channel)
for item in p.listen():
    # do stuff with message (item)

यह काफी सीधा है। हालांकि, जब सब्सक्राइबर के for-लूप के दौरान तत्काल पुनः प्रयास विफल होता है तो आपको redis.ConnectionError अपवाद फेंका जाएगा। मुश्किल बात यह है कि यह "for item in p.listen()" लाइन के "अंदर" होता है। इस प्रकार इसे ठीक से पकड़ने के लिए आपको पूरे for स्टेटमेंट को try/except ब्लॉक में लपेटना होगा। यह कम से कम समस्याग्रस्त है और अनावश्यक कोड जटिलता की ओर ले जाता है।

एक वैकल्पिक मार्ग निम्नलिखित करना है।

### Publisher example code
p = r.pubsub()
p.subscribe(channel)
while True:
    try:
        message = p.get_message()
    except redis.ConnectionError:
        # Do reconnection attempts here such as sleeping and retrying
        p = r.pubsub()
        p.subscribe(channel)
    if message:
        # do something with the message
    time.sleep(0.001) # be nice to the system :)

इस विधि के साथ हम सीधे get_message() को कॉल करते हैं जो हमें उस बिंदु पर अपवाद को पकड़ने और 'p' ऑब्जेक्ट के कनेक्शन को पुनः स्थापित करने की अनुमति देता है। सोने का समय, यदि कोई हो, आपके कोड की आवश्यकताओं पर निर्भर करता है। बेशक यदि आपका सब्सक्राइबर एक निश्चित संख्या में संदेशों को संभालने की उम्मीद करता है और एक for-लूप बेहतर काम करता है, तो यह अभी भी काम करेगा। प्रकाशकों के लिए कोड सरल है क्योंकि यह आमतौर पर एक इटरेटर पर नहीं चलाया जाता है।

### Publisher example code
while True:
    try:
        rcvd = r.publish(channel,message)
        if rcvd >0:
            break
    except redis.ConnectionError:
        # handle reconnect attempts

इस विधि के साथ आपका नियंत्रण है कि कब, और कितनी बार पुनः प्रयास करना है। यह विफलता घटना को पारदर्शी रूप से सही ढंग से संभालने के लिए महत्वपूर्ण है। ध्यान दें कि यही चीज आवश्यक होगी यदि कोड सीधे Sentinel का उपयोग कर रहा है या यहां तक कि यदि प्रश्न में Redis सर्वर रीस्टार्ट हुआ। इस तरह वास्तव में सभी प्रकाशन कोड को इस मूल तंत्र का पालन करना चाहिए।

ब्लॉकिंग लिस्ट कमांड जैसे BLPOP के लिए, क्लाइंट रीकनेक्शन का क्रम सख्ती से महत्वपूर्ण नहीं है क्योंकि डेटा पर्सिस्टेड है। ऊपर वर्णित try/except विधि की आवश्यकता होगी जब कमांड निष्पादन के परिणामस्वरूप "redis.ConnectionError" अपवाद फेंका जाता है तो कनेक्शन को पुनः स्थापित करने के लिए।

ObjectRocket Redis प्लेटफॉर्म के खिलाफ redis-py के लिए विशेष रूप से इन तकनीकों का उपयोग 3 सेकंड को शामिल करने वाली एक पुनः प्रयास विंडो के साथ यह सुनिश्चित करेगा कि ट्रिगर्ड फेलओवर के लिए कोई डेटा हानि की उम्मीद नहीं है, और इंस्टेंस के वर्टिकल रिसाइज जैसे इनिशिएटेड फेलओवर के दौरान नॉन-स्टॉप प्रकाशकों के लिए लगभग 1.5 सेकंड की संभावित संदेश हानि।

जबकि कोड उदाहरण redis-py के लिए विशिष्ट थे, मूल तकनीकों का उपयोग किसी भी क्लाइंट कोड के साथ किया जाना चाहिए जिसे सर्वर रीकनेक्ट को संभालने की आवश्यकता है और या तो PUBSUB कमांड या ब्लॉकिंग लिस्ट ऑपरेशन का उपयोग करता है। इस ज्ञान से लैस अब आप एक उच्च उपलब्धता वाले Redis पॉड का उपयोग करने के लिए इन तकनीकों को लागू कर सकते हैं और जान सकते हैं कि आपका एप्लिकेशन फेलओवर को अपने ऑप्स टीम को आधी रात में जगाए बिना संभाल सकता है।