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