नमस्ते! मैं जियोन हूँ।

आज मैं आपको कैश सेटिंग के मानदंडों के बारे में बताने जा रहा हूँ। व्यक्तिगत रूप से, यह पोस्ट मेरे द्वारा वास्तविक कार्य अनुभव से लिखी गई है, इसलिए इसे केवल एक संदर्भ के रूप में देखें, ㅎㅎ

कैश क्या है?

कैश का मतलब है भविष्य के अनुरोधों के लिए परिणाम पहले से संग्रहीत करना ताकि उन्हें जल्दी से सेवा दी जा सके। दूसरे शब्दों में, यह परिणामों को पहले से संग्रहीत करना और बाद में अनुरोध प्राप्त होने पर, डेटाबेस या एपीआई को संदर्भित किए बिना, अनुरोध को संसाधित करने के लिए कैश तक पहुंचना है। कैश का उदय पारेतो नियम से हुआ।

पारेतो नियम का अर्थ है कि 80% परिणाम 20% कारणों के कारण होते हैं, आप नीचे दी गई छवि को देख सकते हैं!

अर्थात्, कैश को सभी परिणामों को कैश करने की आवश्यकता नहीं है, और हम केवल 20% को कैश करके, जो सेवा के लिए सबसे अधिक बार उपयोग किया जाता है, समग्र दक्षता में सुधार कर सकते हैं।

कौन से डेटा को कैश करना चाहिए?

पारेतो नियम के कारण, हमें हर डेटा को कैश नहीं करना चाहिए, बल्कि केवल आवश्यक डेटा को कैश करना चाहिए। तो, कौन सा डेटा कैश किया जाना चाहिए?

जिस डेटा को अक्सर पढ़ा जाता है लेकिन शायद ही कभी लिखा जाता है

सिद्धांत रूप में, "कैशिंग जिस डेटा को अक्सर पढ़ा जाता है लेकिन शायद ही कभी लिखा जाता है," एक बयान है जो अक्सर सुना जाता है, लेकिन "अक्सर पढ़ा जाता है" और "शायद ही कभी लिखा जाता है" के मानदंड काफी अस्पष्ट थे।

इसलिए, मैं कैश किए जाने वाले डेटा की जांच करने के लिए निम्नलिखित चरणों का पालन करता हूं।

• एपीएम जैसे डेटा डॉग का उपयोग करके आरडीबी में क्वेरी कॉल इतिहास के शीर्ष 5 की जांच करें।
• उनमें से, रीड क्वेरी ढूंढें और जांच करें कि वे किस तालिका से रीड किए जा रहे हैं।
• जांच करें कि संबंधित तालिका के लिए अपडेट क्वेरी कितनी बार निष्पादित की जाती है।

ऊपर बताए गए प्रक्रिया के माध्यम से, हम देख सकते हैं कि क्या क्वेरी बहुत अधिक हैं लेकिन अपडेट क्वेरी कम हैं। मेरी वास्तविक कार्य अनुभव से, एक तालिका में एक दिन में 1.74 मिलियन रीड क्वेरी थीं, लेकिन अपडेट क्वेरी केवल 500 बार हुई थीं। मुझे लगता है कि यह कैशिंग के लिए एक योग्य स्थिति है ㅎㅎ

डेटा जो अपडेट के प्रति संवेदनशील है

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

मुझे भुगतान से संबंधित तालिकाओं के लिए उपरोक्त दो विशेषताओं को पूरा करना था, जिनके लिए कैशिंग की आवश्यकता थी। इसलिए, मैंने भुगतान से संबंधित तालिकाओं का उपयोग करने वाले सभी तर्कों में कैशिंग लागू नहीं की, बल्कि, केवल उन तर्कों में आंशिक रूप से कैशिंग करने का निर्णय लिया जो वास्तव में भुगतान नहीं कर रहे थे और अपेक्षाकृत सुरक्षित थे।

स्थानीय कैशिंग बनाम वैश्विक कैशिंग

अब, हमने कैश किए जाने वाले डेटा और कैशिंग के दायरे को काफी हद तक निर्धारित कर लिया है। तो, हमें यह तय करना होगा कि कैश डेटा कहां संग्रहीत किया जाए। आम तौर पर, हम इसे स्थानीय मेमोरी में संग्रहीत कर सकते हैं या रिडिस जैसे अलग सर्वर पर संग्रहीत कर सकते हैं।

स्थानीय कैशिंग

स्थानीय कैशिंग में कैश किए जाने वाले डेटा को एप्लिकेशन सर्वर की मेमोरी में संग्रहीत करना शामिल है, और आम तौर पर गुआवा कैश या कैफीन कैश का उपयोग किया जाता है।

लाभ

• चूँकि एप्लिकेशन लॉजिक को निष्पादित करने के दौरान कैश को उसी सर्वर की मेमोरी से एक्सेस किया जाता है, इसलिए यह बहुत तेज़ होता है।
• इसे लागू करना आसान है।

नुकसान

• यदि एकाधिक उदाहरण हैं, तो कई समस्याएँ उत्पन्न हो सकती हैं।
  • एक इंस्टेंस द्वारा किए गए कैश परिवर्तन को दूसरे इंस्टेंस में प्रचारित नहीं किया जा सकता है। हालांकि, स्थानीय कैशिंग लाइब्रेरी हैं जो परिवर्तन को दूसरे इंस्टेंस में प्रचारित करती हैं।
  • चूँकि प्रत्येक इंस्टेंस में कैश संग्रहीत होता है, इसलिए नए इंस्टेंस शुरू होने पर, कैश को फिर से भरा जाना चाहिए। इससे बहुत अधिक कैश मिस हो सकते हैं, जिससे सर्वर ट्रैफ़िक को सहन नहीं कर सकता है और सर्वर क्रैश हो सकता है।

वैश्विक कैशिंग

वैश्विक कैशिंग में कैश डेटा को अलग-अलग सर्वर जैसे रिडिस पर संग्रहीत करना शामिल है।

लाभ

• चूँकि कैश को उदाहरणों के बीच साझा किया जाता है, इसलिए एक इंस्टेंस द्वारा किए गए कैश परिवर्तन को सभी उदाहरणों द्वारा एक्सेस किया जा सकता है।
• नए इंस्टेंस शुरू होने पर, इसे मौजूदा कैश स्टोर तक पहुंचने की आवश्यकता होती है, और कैश को भरने की कोई आवश्यकता नहीं होती है।

नुकसान

• चूँकि इसे नेटवर्क ट्रैफ़िक से गुजरना पड़ता है, इसलिए स्थानीय कैशिंग की तुलना में यह धीमा है।
• अलग कैश सर्वर की आवश्यकता होती है, जिससे बुनियादी ढाँचे के प्रबंधन की लागत बढ़ जाती है।
  • बुनियादी ढाँचे के प्रबंधन की लागत? → सर्वर शुल्क, बुनियादी ढाँचे को स्थापित करने और बनाए रखने में लगने वाला समय, आपदा प्रतिक्रिया योजना आदि।

मैंने क्या चुना?

वर्तमान में, कंपनी के एप्लिकेशन सर्वर कई उदाहरणों का उपयोग करके बनाए गए हैं, लेकिन मैंने स्थानीय कैशिंग का चयन किया।

इसके मुख्य रूप से तीन कारण हैं।

• आरडीबी में संग्रहीत कैश किए जाने वाले डेटा की मात्रा लगभग 40,000 है, और मेमोरी में संग्रहीत होने पर भी यह 4MB से कम है।
• भुगतान से संबंधित डेटा के लिए, रीड प्रदर्शन अच्छा होना चाहिए।
• हालांकि रिडिस पहले से मौजूद है, लेकिन रिडिस में नए कैश को संग्रहीत करने से बुनियादी ढाँचे की लागत बढ़ जाएगी।

कैश को कैसे अपडेट किया जाए?

यदि एप्लिकेशन सर्वर कई हैं और स्थानीय कैशिंग लागू है, तो प्रत्येक एप्लिकेशन सर्वर में संग्रहीत कैश मान भिन्न हो सकते हैं। उदाहरण के लिए, सर्वर A में संग्रहीत कैश डेटा "1" है, जबकि सर्वर B में संग्रहीत कैश डेटा सर्वर B द्वारा "2" में बदल दिया गया है। इस स्थिति में, यदि कोई उपयोगकर्ता लोड बैलेंसर को एक अनुरोध भेजता है, तो सर्वर A और सर्वर B विभिन्न मान प्राप्त करेंगे।

इसलिए, प्रत्येक इंस्टेंस के लिए कैश को स्वचालित रूप से साफ़ करना होगा और आरडीबी से डेटा पुनर्प्राप्त किया जाना चाहिए, और इस समय, टीटीएल का उपयोग किया जाता है।

टीटीएल को कितना सेट किया जाए?

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

तो, टीटीएल को कितना सेट किया जाए?

यदि रीड/राइट एक ही कैश सर्वर पर होती है

यदि रीड/राइट रिडिस जैसे एक वैश्विक कैशिंग सर्वर पर होती है, या स्थानीय कैशिंग वाले एक एप्लिकेशन सर्वर पर होती है, तो टीटीएल का मान घंटों या उससे अधिक समय तक बढ़ाया जा सकता है। अंततः, राइटिंग के समय, मौजूदा कैश को अपडेट किया जाएगा, और कैश से डेटा पुनर्प्राप्त करने वाला सर्वर हमेशा अपडेट किया गया डेटा प्राप्त करेगा।

इस मामले में, टीटीएल को सेट करने की आवश्यकता नहीं है, और कैश सर्वर पूर्ण होने पर, LRU एल्गोरिथम का उपयोग करके स्वचालित रूप से कुछ कैश को धीरे-धीरे साफ़ किया जा सकता है।

यदि रीड/राइट एकाधिक कैश सर्वर पर होती है

यदि रीड/राइट एकाधिक वैश्विक कैशिंग सर्वर पर होती है, या स्थानीय कैशिंग वाले एकाधिक एप्लिकेशन सर्वर पर होती है, तो टीटीएल को सेकंड से मिनट तक रखना उचित है। ऐसा इसलिए है क्योंकि संशोधित डेटा को अभी तक नहीं दर्शाते हुए पुराने कैश डेटा को पढ़ने का एक मौका हो सकता है।

इस मामले में, टीटीएल विभिन्न संदर्भों के आधार पर तय किया जाता है, और अपडेट के प्रति अधिक संवेदनशील डेटा और डेटा बदलने की संभावना अधिक होने पर, टीटीएल को कम सेट करना होगा, और अपडेट के प्रति कम संवेदनशील डेटा और डेटा बदलने की संभावना कम होने पर, टीटीएल को थोड़ा लंबा सेट किया जा सकता है।

मैंने टीटीएल को कैसे सेट किया?

मुझे भुगतान से संबंधित डेटा को कैश करना था, और भले ही मैंने वास्तव में भुगतान करने वाले सख्त तर्कों में कैशिंग लागू नहीं की, लेकिन भुगतान की प्रकृति के कारण, अपडेट के प्रति संवेदनशील होना महत्वपूर्ण है। हालाँकि, अपडेट की संभावना कम है, इसलिए मैंने इसे सुरक्षित रूप से 5 सेकंड के आसपास रखा है।

निष्कर्ष

संक्षेप में, मेरा चुना हुआ कैशिंग तरीका इस प्रकार है।

• भुगतान से संबंधित डेटा
• बहुत बार पहुँचा जाता है, लेकिन शायद ही कभी संशोधित किया जाता है।
• वास्तविक भुगतान नहीं होने वाले तर्कों के लिए, लेकिन जिन तर्कों में रीड हो रही हैं, कैशिंग लागू की गई है।
• स्थानीय कैशिंग लागू की गई है, और टीटीएल को 5 सेकंड पर सेट किया गया है।

अगला कदम वास्तव में लागू किए गए कैशिंग तरीके का प्रदर्शन परीक्षण करना है। मैं अभी भी प्रदर्शन परीक्षण कैसे करूं, इस पर विचार कर रहा हूं, इसलिए मैं इसे बाद की पोस्ट में लिखूंगा!