स्केलिंग आसान है। भाग दो - कैशिंग

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

भाग दो कैशिंग

जैसा कि मैंने पिछले भाग में उल्लेख किया है, हम मुख्य रूप से बी 2 सी पोर्टल्स के बारे में बात कर रहे हैं। इन पोर्टलों में एक सामान्य संपत्ति है: लेखन पर अनुरोध पढ़ने की प्रबलता। और अक्सर, 10-गुना या अधिक का प्रचलन। यह स्पष्ट है कि कैशिंग ऐसा आशाजनक उपकरण क्यों लगता है।

कैश एक दिलचस्प और लगभग अंतहीन विषय है। इसलिए, मैं इसे संक्षिप्त रूप से पर्याप्त रूप से रेखांकित करने का प्रयास करूँगा, अनुकूलन के पहले दौर के लिए, स्तर 1 और स्तर 2 कैश, वितरित कैश इत्यादि के बारे में विवरणों के बिना, चूंकि हमें ऑब्जेक्ट के पढ़ने को कैश करना होगा, जबकि हम लिखना कैश छोड़ देते हैं ( कैश लिखो)।

जब हम स्थानीय कैशिंग शुरू करते हैं, तो हमारे पास आमतौर पर एक विकल्प होता है: क्वेरी या ऑब्जेक्ट कैश (कॉल या ऑब्जेक्ट का कैशिंग)। क्वेरी कैश (या विधि कैश) एक कैश है जिसका उपयोग "बाह्य रूप से" किया जा सकता है: यह विधि कॉल (क्वेरी) के परिणामों को रिकॉर्ड करता है, और हम मानते हैं कि समान प्रश्न उसी उत्तरों का कारण बनते हैं। एक ही क्वेरी को कई बार दोहराते समय, आप दूसरी बार, जटिल और लंबी प्रक्रिया को छोड़ सकते हैं, और पिछले परिणाम को वापस कर सकते हैं। इस तरह के कैश का लाभ यह है कि वे वास्तुकला पर या डोमेन पर निर्भर नहीं होते हैं, अर्थात, वे एक उपयोगिता के रूप में एकीकृत होते हैं (उदाहरण के लिए, पहलू) बिना इसे बदल दिए तैयार उत्पाद में। इस लाभ के विपरीत, उनके पास कई नुकसान हैं:

• वे अप्रभावी होते हैं जब हमारे पास समृद्ध इंटरफेस होते हैं जो एक ही वस्तु को पढ़ने के लिए कई तरीके होते हैं। कारण यह है कि वे वस्तु को रास्ता देते हैं, वस्तु को नहीं।
• उनका आकार संभावित वस्तुओं (परिणामों) की संख्या पर निर्भर नहीं करता है, लेकिन संभावित प्रश्नों की संख्या पर, और इसलिए वे आमतौर पर विकल्पों के लिए भारी होते हैं। उनके आकार और आवश्यक स्मृति की मात्रा की योजना बनाना कठिन है।
• वे बदसूरत हैं।

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

कैश जो नहीं है

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

कैश क्या बदलता है

कैश का एक और उपश्रेणी एक्सपायरीचेस है। वे इस पद पर आधारित हैं कि वस्तु या उसके हिस्से एक निश्चित अवधि के लिए अपने राज्य को नहीं बदलेंगे। इस तरह के ऑब्जेक्ट का एक विशिष्ट उदाहरण एक ऑनलाइन डेटिंग साइट पर एक उपयोगकर्ता प्रोफ़ाइल है। यदि उपयोगकर्ता A अपनी प्रोफ़ाइल संपादित कर रहा है, तो उपयोगकर्ता B के लिए, जो उपयोगकर्ता A की प्रोफ़ाइल देख रहा है, इससे कोई फर्क नहीं पड़ता कि वह 5, 30 या 60 सेकंड के बाद इन परिवर्तनों को देखता है (विशेषकर यदि ये उपयोगकर्ता संपर्क नहीं करते हैं)। इस प्रकार, हम किसी व्यक्ति के लिए निरर्थक समय के लिए उपयोगकर्ता A की प्रोफ़ाइल की स्थिति को ठीक कर सकते हैं, लेकिन मशीन के दृष्टिकोण से लंबे समय तक, और निश्चित संस्करण के साथ काम कर सकते हैं। यह एक महत्वपूर्ण संख्या में अनुरोधों के प्रसंस्करण को रोकता है जो संभवतः एक समान परिणाम लौटाएगा (क्योंकि उपयोगकर्ता अपनी प्रोफ़ाइल को बहुत कम बार बदलते हैं, उदाहरण के लिए, संदेशों की खोज या उत्तर दें) और संसाधनों को बचाएं। इस बचत के लिए भुगतान करना आपके प्रोफ़ाइल में एक अपडेट दिखाने का जोखिम है जो हम थोड़ी देर बाद कर सकते हैं। नेटवर्क ट्रैफ़िक (डेटाबेस या सेवा) और, तदनुसार, समय बचाने के लिए क्लाइंट साइड (वेब ​​सर्वर) पर विशेष लोकप्रियता के साथ इस तकनीक का उपयोग किया जाता है। लेकिन यह एकमात्र उदाहरण नहीं है जहां एक्सपायरी कैश का उपयोग उचित है। एक अन्य उपयोग का मामला है, जब एक अनुरोध को संसाधित करने की प्रक्रिया में, हम मानते हैं कि एक ही वस्तु को कई बार अनुरोध किया जाएगा, लेकिन कोड में एक दूसरे से इतनी दूर स्थानों से कि एक चर में अपने मूल्य को स्टोर करना असंभव या अव्यवहारिक है। इस तरह के मध्यवर्ती कैश को लागू करने के लिए एक लोकप्रिय तकनीक थ्रेडलोकल (जावा) है।
ExpiryCache संसाधनों के आदान-प्रदान (व्यापार बंद) से ज्यादा कुछ नहीं है: हम आवेदन प्रदर्शन के लिए परिवर्तनों को प्रदर्शित करने की गति का त्याग करते हैं।

सामान्य तौर पर, स्केलिंग एप्लिकेशन (और विशेष रूप से पोर्टल) संसाधनों का एक आदान-प्रदान है, जो हमारे पास बहुत कुछ है, उन लोगों के लिए जो पर्याप्त नहीं हैं: उदाहरण के लिए, सीपीयू पर रैम, नेटवर्क ट्रैफिक या आईओ।

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