यदि आप राल्फ वाल्डो इमर्सन पर विश्वास करते हैं, तो एक मूर्खतापूर्ण स्थिरता छोटे दिमागों का हॉबगोब्लिन हो सकती है, लेकिन जब एक स्केलेबल, सफल एंटरप्राइज़-लेवल कैशिंग रणनीति लागू करने की बात आती है, तो स्थिरता के बारे में कुछ भी मूर्खतापूर्ण नहीं है। वास्तव में, एंटरप्राइज़ डेटाबेस के संचालन के प्रबंधन में सबसे बड़ी चुनौतियों में से एक कैश स्थिरता बनाए रखना है।
हम पहली जगह में कैश से क्यों परेशान होते हैं? एंटरप्राइज़ कैश का मुख्य लाभ वह गति और दक्षता है जिससे डेटा तक पहुँचा जा सकता है। जबकि प्राथमिक डेटाबेस पर प्रत्येक कॉल समय और प्रोसेसिंग पावर दोनों के मामले में महंगी हो सकती है, कैश पर कॉल बिजली की तेज़ हो सकती है और प्राथमिक डेटाबेस पर कोई प्रभाव नहीं डालती।
कैश स्थिरता के तीन बाधाएं
बेशक, ये लाभ इस मूल धारणा पर टिके हैं कि कैश में डेटा - या कैशेस - हमेशा सोर्स डेटा के समान मान बनाए रखते हैं। हालांकि यह एक सीधा लक्ष्य लग सकता है, यह सिद्धांत की तुलना में व्यवहार में आसान है। वास्तव में, तीन नुकसान हैं जो इसे पटरी से उतार सकते हैं:
1. जब प्राथमिक डेटाबेस में परिवर्तन कैश में परिलक्षित नहीं होते
चूंकि कैश के माध्यम से डेटा एक्सेस करना, परिभाषा के अनुसार, प्राथमिक डेटाबेस के माध्यम से डेटा एक्सेस करने से तेज़ है, यदि कोई विशिष्ट आइटम अनुरोध किया जाता है, तो पहले कैश से परामर्श किया जाएगा। मान लें कि आइटम कैश में मौजूद है, तो इसे प्राथमिक डेटाबेस की तुलना में कहीं अधिक तेज़ी से वापस किया जाएगा। इस रणनीति को कैश-असाइड पैटर्न के रूप में जाना जाता है। कैश को डिफ़ॉल्ट रूप से पहले चेक किया जाता है। यदि डेटा कैश में नहीं है, तो एप्लिकेशन प्राथमिक डेटाबेस को क्वेरी करता है और परिणाम को उपयोगकर्ता को वापस जाते समय कैश में जमा करता है।
समस्या उस अंतराल के दौरान उत्पन्न होती है जब प्राथमिक डेटाबेस में डेटा बदल जाता है और जब कैश को उस परिवर्तन को प्रतिबिंबित करने के लिए समायोजित किया जाता है। यह इस बात से प्रभावित होता है कि एप्लिकेशन कितनी बार कैश की जांच करता है। हालांकि, प्रत्येक जांच प्रोसेसर संसाधनों की कीमत पर आती है। वही प्रोसेसर एक साथ कई अन्य कार्यों या लेनदेन को संभाल सकता है, जिनमें से कुछ कैश को अपडेट करने की तुलना में अधिक महत्वपूर्ण हैं, यदि उतने नहीं तो।
चुनौती उस स्वीट स्पॉट को खोजने में आती है, एक तरह का गोल्डीलॉक्स क्षेत्र जो बहुत बार अपडेट की जांच करने और पर्याप्त नहीं करने के बीच स्थित है। बेशक, यदि कोई उपयोगकर्ता इस अंतराल के दौरान पुराने डेटा तक पहुँचने का प्रयास करता है, तो वह जुआ हार जाता है।
2. जब कैश्ड परिणामों को अपडेट करने में देरी होती है
यह समस्या पिछली समस्या के साथ थोड़ी ओवरलैप करती है। हर बार जब प्राथमिक डेटाबेस में कोई मान अपडेट होता है, तो कैश को एक संदेश भेजा जाता है, जिसमें उसे बदले हुए मान को या तो अपडेट करने या पूरी तरह से हटाने का निर्देश दिया जाता है। (बाद के मामले में, अगली बार जब मान का अनुरोध किया जाता है, तो इसे प्राथमिक डेटाबेस से एक्सेस किया जाएगा और फिर उसके बाद कैश से।) सामान्य परिस्थितियों में, यह संचार अपेक्षाकृत तेजी से होता है और कैश्ड आइटम को कैश स्थिरता बनाए रखने के लिए या तो अपडेट या हटा दिया जाता है।
एक बार फिर, इस परिवर्तन के लिए प्रोसेसिंग पावर की आवश्यकता होती है, और इसमें समय लगता है। देरी उपलब्ध प्रोसेसिंग गति और नेटवर्क थ्रूपुट दोनों से प्रभावित हो सकती है। यदि कोई उपयोगकर्ता सर्वर द्वारा कैश को अपडेट करने के लिए संदेश भेजे जाने के समय और उस संदेश के कैश द्वारा प्राप्त और उस पर कार्रवाई किए जाने के समय के बीच पुराने डेटा तक पहुँचने का दुर्भाग्य रखता है, तो परिणाम डेटा हो सकता है जो पुराना, गलत या दोनों है।
3. जब कैश्ड नोड्स में असंगति होती है
बेशक, वेबसाइट या एप्लिकेशन जितना बड़ा होगा, कैश के कई नोड्स पर संग्रहीत होने की संभावना उतनी ही अधिक होगी, न कि केवल एक पर। एक प्राथमिक नोड के अलावा, कोई भी संख्या में रेप्लिका नोड्स हो सकते हैं जो आदर्श रूप से समान डेटा संग्रहीत कर रहे हैं। लोड बैलेंसिंग और प्रदर्शन के दृष्टिकोण से, यह अक्सर समझ में आता है।
लेकिन डेटा अखंडता के दृष्टिकोण से, यह कैश असंगति का एक और संभावित स्रोत पेश करता है। हर बार जब प्राथमिक डेटाबेस में डेटा अपडेट होता है, तो इस परिवर्तन को सभी रेप्लिकास में भी परिलक्षित करने की आवश्यकता होती है। यह इस बात पर निर्भर करता है कि ये नोड्स भौगोलिक रूप से कहां स्थित हैं और कितने हैं, अपडेट प्रक्रिया में महत्वपूर्ण समय लग सकता है। हालांकि अपडेट प्रक्रिया चल रही हो सकती है, फिर भी यह काफी संभव है कि कोई उपयोगकर्ता उस नोड तक पहुँचे जहां परिवर्तन अभी तक नहीं किए गए हैं। एक बार फिर, परिणाम, आपने अनुमान लगाया, कैश असंगति हो सकती है।
कैश असंगति की लागत
कैश्ड डेटाबेस के सभी लाभों के लिए, कैश असंगति की संभावना शायद इसकी सबसे स्पष्ट कमी है। लेकिन समस्या कितनी बड़ी है? अंततः, कैश असंगति की लागत संदर्भ पर निर्भर करती है।
कुछ कैश असंगति बिना किसी परिणाम के हो सकती है। उदाहरण के लिए, यदि आपके कैश में कुल "लाइक्स" अस्थायी रूप से आपके प्राथमिक डेटाबेस में वास्तविक कुल से आउट ऑफ सिंक हैं, तो संक्षिप्त विसंगति समस्याओं का कारण बनने या यहां तक कि ध्यान दिए जाने की संभावना नहीं है।
दूसरी ओर, यदि कैश सूचीबद्ध करता है कि किसी विशेष उत्पाद का एक शेष आइटम अभी भी स्टॉक में है, जबकि प्राथमिक डेटाबेस पर वास्तविक इन्वेंट्री कहती है कि कोई नहीं बचा है, तो परिणामस्वरूप संघर्ष आपके ग्राहकों को भ्रमित और अलग-थलग कर सकता है, आपके ब्रांड की विश्वसनीयता के लिए प्रतिष्ठा को नुकसान पहुंचा सकता है, कंपनी के लेनदेन और लेखांकन पर कहर बरपा सकता है, और चरम मामलों में, आपको कानूनी खतरे में भी डाल सकता है।
असंगति का मुकाबला करने के तीन तरीके
सौभाग्य से, ऊपर बताए गए कैश असंगति के प्रत्येक संभावित स्रोत के लिए, समान संख्या में समाधान हैं।
1. कैश इनवैलिडेशन
कैश इनवैलिडेशन के साथ, जब भी प्राथमिक डेटाबेस में कोई मान अपडेट होता है, तो संबंधित कुंजी वाला प्रत्येक कैश्ड आइटम स्वचालित रूप से कैश या कैशेस से हटा दिया जाता है। हालांकि कैश इनवैलिडेशन को शायद "जबरदस्ती दृष्टिकोण" के रूप में देखा जा सकता है, इसका लाभ यह है कि इसके लिए केवल एक महंगा और अक्सर समय लेने वाला राइट - प्राथमिक डेटाबेस पर ही - दो या अधिक के बजाय आवश्यक होता है।
2. राइट-थ्रू कैशिंग
इस मामले में, प्राथमिक डेटाबेस को अपडेट करने और कैश को हटाने के बजाय, राइट-थ्रू रणनीति के साथ, एप्लिकेशन कैश को अपडेट करता है, और फिर कैश प्राथमिक डेटाबेस को सिंक्रोनस रूप से अपडेट करता है। दूसरे शब्दों में, प्राथमिक डेटाबेस पर किसी भी अपडेट को शुरू करने के लिए भरोसा करने के बजाय, कैश अपनी स्थिरता बनाए रखने और उसके द्वारा किए गए किसी भी परिवर्तन की सूचना वापस प्राथमिक डेटाबेस को देने का प्रभारी होता है।
3. राइट-बिहाइंड कैशिंग
दुर्भाग्य से, ऐसे समय होते हैं जब दो राइट वास्तव में एक गलत बना सकते हैं। राइट-थ्रू कैश रणनीति की कमियों में से एक यह है कि कैश और प्राथमिक डेटाबेस दोनों को अपडेट करने के लिए दो समय लेने वाले, प्रोसेसर-कर लगाने वाले परिवर्तनों की आवश्यकता होती है, पहले कैश पर और फिर प्राथमिक डेटाबेस पर।
एक अन्य रणनीति, जिसे राइट-बिहाइंड के नाम से जाना जाता है, प्रारंभ में केवल कैश को अपडेट करके और फिर बाद में प्राथमिक डेटाबेस को अपडेट करके इस समस्या से बचाती है। बेशक, प्राथमिक डेटाबेस को भी अपडेट करने की आवश्यकता होगी, और जितनी जल्दी हो सके उतना अच्छा, लेकिन इस मामले में उपयोगकर्ता को दो राइट्स की "लागत" का भुगतान नहीं करना पड़ता। प्राथमिक डेटाबेस पर दूसरा राइट असिंक्रोनस रूप से और पर्दे के पीछे (इसलिए नाम, राइट-बिहाइंड) ऐसे समय में होता है जब यह प्रदर्शन को बाधित करने की संभावना कम होती है।
रेडिस एंटरप्राइज बचाव के लिए
कैश इनवैलिडेशन के अलावा, राइट-थ्रू और राइट-बिहाइंड कैशिंग उन कई परिदृश्यों को संबोधित कर सकते हैं जो आपको कैश स्थिरता प्राप्त करने में मदद करते हैं। लेकिन किसी समस्या का उत्तर ढूंढना उसे लागू करने के समान नहीं है।
Redis Enterprise का एक्टिव-एक्टिव जियो-डुप्लिकेशन कई प्राइमरी की अनुमति देता है और आपको तेजी से भारी भार को कुशलतापूर्वक संभालने में सक्षम बनाता है। एक्टिव-एक्टिव नाम इस तथ्य को संदर्भित करता है कि आपके डेटाबेस का प्रत्येक इंस्टेंस किसी भी कुंजी पर रीड और राइट दोनों ऑपरेशंस स्वीकार कर सकता है। प्रत्येक डेटाबेस इंस्टेंस, चाहे कितना भी दूर हो, आपके नेटवर्क पर एक पीयर है। इसका मतलब है कि जब किसी भी इंस्टेंस पर राइट होता है, तो वह नोड आपके नेटवर्क पर अन्य सभी इंस्टेंस को एक संदेश स्वचालित रूप से भेजता है, यह दर्शाता है कि कैश में क्या बदला है और यह सुनिश्चित करता है कि सभी इंस्टेंस कैश्ड डेटा का एक सुसंगत सेट बनाए रखें।
Redis Enterprise का अद्वितीय एक्टिव-एक्टिव जियो-डुप्लिकेशन संभावित राइट कॉन्फ्लिक्ट्स से निपटने के लिए डिज़ाइन किए गए परिष्कृत एल्गोरिदम को नियोजित करता है जो कैश असंगति का कारण बन सकते हैं। ये एल्गोरिदम कॉन्फ्लिक्ट-फ्री रेप्लिकेटेड डेटा टाइप्स (CRDTs) पर आधारित हैं, यह सुनिश्चित करते हुए कि कई रेप्लिकास से राइट्स को इस तरह से मर्ज किया जा सकता है जो प्रभावी ढंग से स्थिरता बनाए रखता है।
हॉबगोब्लिन्स के लिए हुर्रे!
क्योंकि कैश स्थिरता बनाए रखने की चुनौती आपके आर्किटेक्चर के बढ़ने के साथ अधिक जटिल और तेजी से परिणामी होती जाती है, आपको एक एंटरप्राइज़-लेवल कैशिंग समाधान की आवश्यकता होती है जो आपके व्यवसाय के लिए आवश्यक स्थिरता को और जो आपके ग्राहक उम्मीद करते हैं, उसे विश्वसनीय रूप से वितरित करे।
स्थिरता इमर्सन के लिए हॉबगोब्लिन रही होगी, लेकिन एंटरप्राइज़-लेवल डेटाबेस कैशिंग की बात आती है तो यह बिल्कुल आवश्यक है। इसलिए Redis Enterprise चुनना बुद्धिमानी है। आप ऐसा न करके मूर्ख होंगे।
कैशिंग की पूरी कहानी प्राप्त करें। ली एचिसन द्वारा Caching at Scale with Redis पढ़ें।
