मानक निरर्थक रेडिस समाधान प्रहरी के साथ मास्टर / स्लेव प्रतिकृति को चलाने के लिए है जो फेलओवर का प्रबंधन करता है। यह उम्मीद की जाती है कि या तो ए) क्लाइंट समर्थन और वर्तमान मास्टर की खोज के लिए सेंटिनल का उपयोग या बी) रेडिस पॉड के सामने एक टीसीपी प्रॉक्सी जिसे सेंटिनल द्वारा मास्टर को इंगित करने के लिए प्रबंधित किया जाता है। पहला तरीका है जिस तरह से Redis Sentinel को डिज़ाइन किया गया है और दूसरा एक बढ़ती हुई प्रवृत्ति है - और जिस तरह से ObjectRocket Redis को कॉन्फ़िगर किया गया है।
Redis में आदेशों पर विफलता का प्रभाव
रेडिस संचालन के विशाल बहुमत के लिए यह अपेक्षा के अनुरूप काम करता है। एक विफलता पर क्लाइंट कोड से यह पता लगाने की अपेक्षा की जाती है कि कनेक्शन विफल हो गया है और या तो ए) वर्तमान मास्टर को देखें और फिर से कनेक्ट करें या बी) ऊपर वर्णित परिदृश्यों के आधार पर पुन:कनेक्ट करने का प्रयास करें। प्रॉक्सी आधारित परिदृश्य भी रेडिस सर्वर पुनरारंभ के समान है, इसलिए यह उस मामले पर भी लागू होता है जहां आपके पास एक एकल उदाहरण रेडिस है जिसे पुनरारंभ किया जा सकता है।
हालाँकि, कुछ मुट्ठी भर रेडिस कमांड लंबे समय तक अवरुद्ध या गैर-परमाणु हैं। PUBSUB सब्सक्राइब और सबस्क्राइब कमांड गैर-परमाणु हैं जिसमें कमांड अपने अनुरोध को पंजीकृत करेगा कि दिए गए चैनल (चैनलों) को भेजे गए किसी भी संदेश को भी भेजा जाए, लेकिन वास्तविक डेटा बहुत बाद में आ सकता है - अर्थात। इसके प्रकाशित होने के बाद। BL* कमांड लंबी अवधि के होते हैं और इसमें दो चरण कमांड होते हैं जैसे कि सब्सक्राइब कमांड वे ब्लॉक कर देंगे और तब तक वापस नहीं आएंगे जब तक कि कोई आइटम हटाए जाने के लिए सूची में उपलब्ध न हो।
इन आदेशों के बीच एक प्रमुख समानता यह है कि उन्हें जारी किया जाता है और पंजीकरण का एक रूप सर्वर पर किया जाता है, लेकिन डेटा बाद में आ सकता है। जारी किए जा रहे आदेश और सर्वर के पास विफलताओं और पुनरारंभ के साथ उत्तर देने के लिए डेटा होने के बीच हो सकता है। पुनरारंभ या विफलता के मामले में "पंजीकरण" अब सर्वर पर नहीं है। यह हमें इस प्रश्न पर लाता है कि इन परिदृश्यों में इन आदेशों के संबंध में क्या होता है।
उन विवरणों में तल्लीन करने से पहले एक और पहलू सामने लाना है क्योंकि यह परीक्षण के दौरान खेल में आएगा और परिणामों पर नाटकीय प्रभाव पड़ता है और विफलता परिदृश्यों के लिए कोड कैसे किया जाता है। वास्तव में दो प्रकार की विफलताएं हैं। हममें से अधिकांश लोग एक विफलता मानते हैं - गुरु की हानि। इस प्रकार की विफलता में मास्टर अनुत्तरदायी होता है। मैं इसे "ट्रिगर फेलओवर" के रूप में संदर्भित करता हूं। विफलताओं का दूसरा वर्ग जिसे मैं "आरंभिक विफलता" के रूप में संदर्भित करता हूं।
आरंभ की गई विफलता तब होती है जब एक व्यवस्थापक प्रहरी को प्रहरी विफलता आदेश भेजता है जो तब पॉड को पुन:कॉन्फ़िगर करता है, एक मास्टर को बढ़ावा देता है और फिर मूल मास्टर को पदावनत करता है। ऊपरी तौर पर ये दोनों स्थितियां एक जैसी ही लगती हैं। रेडिस कमांड के विशाल बहुमत के मामले में उनके साथ समान व्यवहार किया जा सकता है। हालांकि, हमारे लॉन्ग-ब्लॉक कमांड के मामले में उन्हें उनके अपने संदर्भ में समझा जाना चाहिए।
इन दो विफलता वर्गों के बीच प्रमुख कार्यात्मक विभेदक घटनाओं का क्रम है। जब एक ट्रिगर विफलता होती है तो ऐसा इसलिए होता है क्योंकि मास्टर प्रतिक्रिया नहीं दे रहा है। इस मामले में कोई डेटा जोड़ा या संशोधित नहीं किया जा रहा है, और मास्टर पर कोई संदेश प्रकाशित नहीं किया गया है। एक आरंभिक विफलता में एक बहुत ही संक्षिप्त विंडो होती है जहां दो मास्टर होते हैं।
यहां चर्चा की गई तकनीकों और परिदृश्यों को सामान्य रूप से वर्णित किया जाएगा और पायथन रेडिस लाइब्रेरी "रेडिस-पीई" का उपयोग करके प्रदर्शित किया जाएगा, लेकिन किसी भी क्लाइंट लाइब्रेरी पर लागू होता है। हाथ में पृष्ठभूमि के साथ, आइए अब देखें कि यह लॉन्ग-ब्लॉक कमांड के उपयोग को कैसे प्रभावित करता है। सबसे पहले हम PUBSUB को देखें।
PUBSUB
Redis PUBSUB में तीन कमांड होते हैं:PUBLISH, SUBSCRIBE और PSUBSCRIBE। पहले कमांड का उपयोग संदेश भेजने के लिए किया जाता है जबकि बाद के दो का उपयोग PUBLISH कमांड के माध्यम से प्रकाशित संदेशों को पंजीकृत करने और प्राप्त करने के लिए किया जाता है। सबसे पहले, आइए देखें कि PUBLISH कमांड में क्या होता है।
जब आप PUBLISH को निष्पादित करते हैं तो यह संदेश को दिए गए चैनल पर तुरंत प्रकाशित करेगा और इसे प्राप्त करने वाले ग्राहकों की संख्या लौटाएगा। एक विफलता परिदृश्य इसे किस प्रकार प्रासंगिकता में लाता है? विफलता के मामले पर विचार करें। टीसीपी कनेक्शन के चले जाने पर क्लाइंट को फिर से कनेक्ट करना होगा। यदि किसी प्रॉक्सी से बात की जाती है तो यह एक सीधा पुन:कनेक्ट करेगा और एक अलग सर्वर प्राप्त करेगा। यदि प्रहरी खोज कर रहे हैं तो इसमें थोड़ा अधिक समय लगेगा और फिर भी किसी भिन्न सर्वर से कनेक्ट होगा। जहां मुद्दा निहित है वह समय में है। यदि प्रकाशक नए सर्वर से जुड़ता है इससे पहले कि कोई सब्सक्राइबर ऐसा करे, संदेश चला गया - खो गया। लेकिन क्या ऐसा हो सकता है? यह समझने के लिए कि हम SUBSCRIBE कमांड को देखते हैं।
जब आपका कोड सब्सक्राइब कमांड जारी करता है तो सर्वर इन-मेमोरी डेटा स्ट्रक्चर में रजिस्टर करता है कि उस विशिष्ट कनेक्शन को सब्सक्राइब किए गए चैनल पर संदेश मिलना चाहिए। यह जानकारी दासों को प्रचारित नहीं की जाती है। इस प्रकार जब कोई विफलता होती है और क्लाइंट फिर से जुड़ता है तो उसे सदस्यता आदेश फिर से जारी करना होगा। अन्यथा नया सर्वर नहीं जानता कि विशेष कनेक्शन को कुछ संदेश प्राप्त करने की आवश्यकता है। अब हमारे पास एक ग्राहक के लिए प्रकाशक के बाद नए मास्टर से फिर से जुड़ने की स्पष्ट संभावना है। संदेशों के खोने की शर्तें अब मौजूद हैं। तो इसे कैसे कम करें या रोकें? कुछ विकल्प हैं।
सबसे पहले प्रकाशक इस तथ्य का लाभ उठा सकता है कि PUBLISH उसे प्राप्त करने वाले ग्राहकों की संख्या लौटाता है। यदि शून्य ग्राहक इसे प्राप्त करते हैं तो प्रकाशक पुनः प्रयास कर सकता है। उन प्रणालियों के लिए जहां यह ग्राहकों की एक स्थिर संख्या है या जहां "कम से कम एक ग्राहक" पर्याप्त है, यह संदेश हानि को रोकेगा। उन प्रणालियों के लिए जो इस मानदंड को पूरा नहीं करती हैं, यदि कम मजबूत है, तो दूसरा विकल्प है।
दूसरा विकल्प फिर से कनेक्ट विंडो को नियंत्रित करना है। यहां अंगूठे का नियम है कि प्रकाशक की देरी ग्राहक की देरी से कम से कम तीन गुना अधिक हो। यह संदेशों के प्रकाशन से पहले ग्राहकों को फिर से जोड़ने के लिए कम से कम तीन अवसर प्रदान करेगा। जब तक ग्राहक पहले ऑनलाइन होंगे, संदेश ईथर में नहीं जाएंगे। हालांकि, इसे नियंत्रित न करने से कहीं अधिक मजबूत होने पर भी संदेश हानि की संभावना बनी रहती है।
तीसरा विकल्प जो मैं इस दौड़ की स्थिति को कम करने के लिए प्रस्तुत करूंगा, वह है एक लॉक मैकेनिज्म का निर्माण। यह निश्चित रूप से सबसे जटिल मार्ग है क्योंकि इसके लिए एक तंत्र बनाने या नियोजित करने की आवश्यकता होती है जो प्रकाशकों को तब तक प्रकाशित करने से रोकता है जब तक कि ग्राहक जुड़ न जाएं। मूल प्रक्रिया कुछ साझा स्थान (जैसे कि ज़ूकीपर, एक डेटाबेस, कॉन्सल, आदि के माध्यम से) है, जहां ग्राहक पंजीकृत करते हैं कि वे प्राप्त करने के लिए तैयार हैं और ग्राहक संदेश प्रकाशित करने से पहले वैध और तैयार ग्राहकों की जांच करते हैं। विज्ञापन की जटिलता को और बढ़ाने के लिए, सब्सक्राइबर्स को टीसीपी कनेक्शन खोने पर इस तंत्र में खुद को "अनसेट" करना होगा।
यह कहा जाना चाहिए कि यह सब एक ट्रिगर विफलता के लिए है। यह काम करेगा क्योंकि मास्टर गैर-उत्तरदायी है इसलिए इस पर कोई संदेश नहीं जाता है। आरंभ किए गए विफलता परिदृश्य में मास्टर तब तक संदेशों को स्वीकार करना जारी रखेगा जब तक कि वह मास्टर नहीं रह गया है या डिस्कनेक्ट नहीं हो गया है। उपरोक्त विधियों में से कोई भी इस परिदृश्य को ठीक से और पूरी तरह से पकड़ नहीं पाएगा।
शुरू की गई विफलताओं के मामले में (जो उदाहरण के लिए सिस्टम रखरखाव के दौरान हो सकता है) आपका सबसे अच्छा प्रभाव पहले और दूसरे दोनों विकल्पों को नियोजित करना है, और स्वीकार करना है कि संदेश हानि हो सकती है। कितना संदेश हानि पूरी तरह से आपके प्रकाशन कार्यक्रम पर निर्भर है। यदि आप औसतन हर कुछ मिनटों में एक संदेश प्रकाशित करते हैं तो आपके लिए वास्तव में हानि खिड़की का सामना करने की एक छोटी सी संभावना है। प्रकाशन अंतराल जितना बड़ा होगा, जोखिम उतना ही कम होगा। इसके विपरीत यदि आप प्रति सेकंड सैकड़ों या हजारों संदेश प्रकाशित कर रहे हैं तो आप निश्चित रूप से कुछ खो देंगे। प्रबंधित प्रॉक्सी परिदृश्य के लिए यह इस बात पर निर्भर करेगा कि आपके प्रॉक्सी में फ़ेलओवर कितनी जल्दी पूरा होता है। ऑब्जेक्टरॉकेट के रेडिस प्लेटफॉर्म के लिए यह विंडो 1.5 सेकंड तक की है।
इस प्रकार अंतराल पर एक दृष्टिकोण, जो सीमा पर विफल रहता है, यह है कि ग्राहक आपके प्रकाशन अंतराल के 1/3d के अंतराल पर पुन:कनेक्ट करने का प्रयास करें। इस प्रकार यदि आप प्रति मिनट एक बार एक संदेश प्रकाशित करते हैं, तो अपने ग्राहकों को कम से कम हर 20 सेकंड में और अपने प्रकाशक को हर मिनट या दो बार फिर से जोड़ने के लिए कोड/कॉन्फ़िगर करें। जैसे-जैसे प्रकाशन अंतराल 3 सेकंड के निशान के करीब पहुंचता है, इसे हासिल करना कठिन हो जाता है क्योंकि एक फ़ेलओवर रीकनेक्ट प्रक्रिया (लुकअप, टीसीपी हैंडशेक, AUTH, SUBSCRIBE, आदि) आसानी से कुल कुछ सेकंड हो सकती है।
बीएलपीओपी और दोस्त
यह हमें इस सवाल पर लाता है कि इन शर्तों के तहत ब्लॉकिंग लिस्ट कमांड कैसे काम करता है। यहां समाचार प्रकाशित करने से बेहतर है। इस मामले में हम डेटा संरचनाओं को संशोधित कर रहे हैं जिन्हें दोहराया गया है। इसके अलावा, क्योंकि ये डेटा संरचनाओं में संशोधन हैं, हमारे पास पुन:कनेक्ट करने के आदेश के कारण खोए हुए संदेशों के जोखिम के लिए समान स्तर नहीं है। यदि निर्माता ग्राहक से पहले फिर से जुड़ता है तो अपेक्षित व्यवहार में कोई बदलाव नहीं होता है। निर्माता सूची (या पीओपी और पुश) पर आइटम को पुश करेगा और एक बार उपभोक्ता कनेक्ट होने के बाद डेटा होगा। एक अपवाद के साथ।
एक आरंभिक विफलता के मामले में हमें संक्षिप्त बहु-मास्टर समस्या पर विचार करना चाहिए। कुछ क्षणों के लिए, मिलीसेकंड के क्रम में, एक आरंभिक विफलता के दौरान मूल मास्टर अभी भी डेटा संशोधनों को स्वीकार करेगा और एक दास के रूप में पहले से ही मास्टर करने के लिए पदोन्नत किया गया है, ये संशोधन दोहराए नहीं जाएंगे। ध्यान दें कि यह विंडो बहुत छोटी है। परीक्षण में यह एकल अंक मिलीसेकंड का क्रम है, लेकिन यह वहां है। जैसा कि प्रकाशित करने के साथ यह अनिवार्य रूप से एक कोने की स्थिति है, जहां आपकी बाधाएं, उदाहरण के लिए, पुराने मास्टर को पीओपी कमांड जारी करना दुर्लभ है, हालांकि बोधगम्य स्थितियों तक बढ़ जाती है जब आपके उत्पादकों और उपभोक्ताओं की सूची संशोधन आदेश बनाने की दर हजारों प्रति सेकंड तक पहुंच जाती है।
उदाहरण के लिए, BRPOPLPUSH करने वाले एक कार्यकर्ता के मामले में, परिणाम ऐसा होगा कि स्थानांतरित किया जा रहा आइटम फेलओवर के बाद अपनी मूल स्थिति में "वापस" हो जाएगा। बीएलपीओपी के मामले में परिणाम अनिवार्य रूप से वही होगा। फ़ेलओवर पूर्ण होने के बाद आइटम फिर से कतारबद्ध प्रतीत होगा। यदि आपके आइटम बेकार नौकरियां हैं, तो यह कोई समस्या नहीं होगी। गैर-बेवकूफ नौकरियों के मामले में आपको इसके लिए कितना रक्षात्मक कोडिंग करना चाहिए, यह एक नौकरी चलाने या आइटम को दो बार संसाधित करने के प्रभाव को निर्धारित करने का एक परिणाम है कि आप कितनी बार संशोधन कर रहे हैं और इसका सामना करने की संभावना है। परिस्थिति। यह भी ध्यान दिया जाना चाहिए कि चूंकि यह केवल एक आरंभिक विफलता की स्थिति में होता है, यह कुछ परिचालन नियंत्रण में होना चाहिए और मैं सलाह दूंगा कि जब भी संभव हो रखरखाव ऐसे समय में किया जाना चाहिए जब आपके सिस्टम कम से कम या यहां तक कि कम से कम उपयोग कर रहे हों इस संभावना को खत्म करें।
ट्रिगर विफलता के लिए डेटा हानि की कोई अपेक्षा नहीं है। एक ट्रिगर विफलता तब होती है जब मास्टर अनुत्तरदायी होता है, इस प्रकार मास्टर में कोई संशोधन नहीं किया जा रहा है। हालांकि, इनमें से प्रत्येक परिदृश्य के साथ वास्तविक टीसीपी पुन:कनेक्ट को संभालने का मामला है जो किसी भी विफलता परिदृश्य में अनिवार्य है।
क्लाइंट रीकनेक्शन
या तो फेलओवर परिदृश्य के तहत, ट्रिगर या शुरू किया गया, क्लाइंट को पता लगाना और फिर से कनेक्ट करना होगा - या तो सेंटिनल लुकअप या उसी पते पर एक संक्षिप्त विंडो के बाद। ऑब्जेक्टरॉकेट रेडिस के मामले में जो एक प्रबंधित प्रॉक्सी परत का उपयोग करता है, क्लाइंट बस फिर से कनेक्ट हो जाएगा। वास्तविक विफलता प्रक्रिया को पूरा होने में दो सेकंड तक का समय लग सकता है। इस प्रकार क्लाइंट कोड को इसके लिए जिम्मेदार होना चाहिए। आदर्श रूप से नेटवर्क ब्लिप्स को संभालने के लिए एक तत्काल पुनः प्रयास किया जाना चाहिए जहां एक कनेक्शन बस मार्ग के साथ कहीं गिरा दिया गया हो। हालांकि इसके साथ एक बैक एल्गोरिथम के साथ होना चाहिए जिसमें सर्वर रीस्टार्ट जैसे मामलों के लिए रिट्रीट टू अकाउंट होना चाहिए (जैसा कि स्टैंडअलोन रेडिस रीस्टार्ट या प्रॉक्सी रीस्टार्ट में होता है)।
फिर से कनेक्ट होने पर किसी भी सब्सक्राइबर को रि-सब्सक्राइब करने की आवश्यकता होगी क्योंकि अनुरोध चैनलों और नए टीसीपी कनेक्शन के बीच लिंक स्थापित होना चाहिए। चूंकि रेडिस के PUBSUB चैनल तब बनते हैं जब कोई ग्राहक या प्रकाशक उन तक पहुंचने का प्रयास करता है, इसलिए चैनल को "पुन:बनाने" की कोई आवश्यकता नहीं है।
यह हमें लाता है कि यह कैसे करना है। उत्तर उपयोग में क्लाइंट लाइब्रेरी पर अत्यधिक निर्भर है और यह डिस्कनेक्ट को कैसे संभालता है। एक आदर्श परिदृश्य में कनेक्शन स्वचालित रूप से पुनः प्रयास के लिए कॉन्फ़िगर करने योग्य होगा, यदि सीमाएं पूरी हो जाती हैं तो अंतिम विफलता वापस आ जाती है। अब तक मैंने कुछ पुस्तकालयों का परीक्षण किया है कि वे इसे कैसे संभालते हैं और यह नाटकीय रूप से भिन्न होता है। यहाँ मैं एक सामान्य बात पर चर्चा करूँगा: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)यह बात काफी सीधी है। हालांकि, जब सब्सक्राइबर के फॉर-लूप के दौरान तत्काल पुनः प्रयास विफल हो जाता है तो आपको एक redis.ConnectionError अपवाद फेंक दिया जाएगा। मुश्किल बात यह है कि यह p.listen() लाइन में आइटम के लिए "अंदर" होता है। इस प्रकार इसे ठीक से पकड़ने के लिए आपको पूरे कथन के लिए प्रयास/छोड़कर ब्लॉक में लपेटना होगा। यह सबसे अच्छी समस्या है और अनावश्यक कोड जटिलता की ओर ले जाती है।
इसके बजाय निम्नलिखित करने का एक वैकल्पिक मार्ग है।
### 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' ऑब्जेक्ट के कनेक्शन को फिर से स्थापित करने की अनुमति देता है। सोने का समय, यदि बिल्कुल भी, आपके कोड की आवश्यकताओं पर निर्भर है। बेशक यदि आपका ग्राहक एक निश्चित संख्या में संदेशों को संभालने की अपेक्षा करता है और एक फॉर-लूप बेहतर काम करता है, तब भी यह काम करेगा। प्रकाशकों के लिए कोड सरल है क्योंकि यह आमतौर पर एक पुनरावर्तक पर नहीं चलता है।
### Publisher example code
while True:
try:
rcvd = r.publish(channel,message)
if rcvd >0:
break
except redis.ConnectionError:
# handle reconnect attemptsइस पद्धति से आपका नियंत्रण है कि कब, कब और कितनी बार पुनः प्रयास करना है। विफलता की घटना को ठीक से पारदर्शी रूप से संभालने के लिए यह महत्वपूर्ण है। ध्यान दें कि यह वही आवश्यक होगा यदि कोड सीधे सेंटिनल का उपयोग कर रहा है या यहां तक कि यदि प्रश्न में रेडिस सर्वर पुनरारंभ हो गया है। जैसे वास्तव में सभी प्रकाशन कोड को इस बुनियादी तंत्र का पालन करना चाहिए।
BLPOP जैसे ब्लॉकिंग लिस्ट कमांड के लिए, क्लाइंट रीकनेक्शन का क्रम सख्ती से महत्वपूर्ण नहीं है क्योंकि डेटा बना रहता है। ऊपर वर्णित प्रयास/छोड़कर विधि को कनेक्शन को फिर से स्थापित करने की आवश्यकता होगी जब कमांड निष्पादन के परिणामस्वरूप "redis.ConnectionError" अपवाद फेंका जा रहा हो।
रेडिस-पीई के लिए विशेष रूप से ऑब्जेक्टरॉकेट रेडिस प्लेटफॉर्म के खिलाफ इन तकनीकों का उपयोग करके 3 सेकंड की एक रिट्री विंडो के साथ यह सुनिश्चित करेगा कि ट्रिगर विफलताओं के लिए कोई डेटा हानि की उम्मीद नहीं है, और एक आरंभिक विफलता के दौरान नॉन-स्टॉप प्रकाशकों के लिए लगभग 1.5 सेकंड संभावित संदेश हानि। जैसे उदाहरण के लंबवत आकार के दौरान।
जबकि कोड उदाहरण रेडिस-पीई के लिए विशिष्ट थे, बुनियादी तकनीकों का उपयोग किसी भी क्लाइंट कोड के साथ किया जाना चाहिए, जिसे सर्वर रीकनेक्ट को संभालने की आवश्यकता होती है और PUBSUB कमांड या ब्लॉकिंग सूची संचालन का उपयोग करता है। इस ज्ञान के साथ अब आप अत्यधिक उपलब्ध रेडिस पॉड का उपयोग करने के लिए इन तकनीकों को लागू कर सकते हैं और जान सकते हैं कि आपका एप्लिकेशन रात के मध्य में आपकी ऑप्स टीम को जगाए बिना विफलताओं को संभाल सकता है।