यहाँ श्रृंखला में तीसरा लेख "AtContent.com सेवा की आंतरिक संरचना और वास्तुकला" है। इससे, आप सीखेंगे कि Windows Azure प्लेटफ़ॉर्म का उपयोग करते समय आप कैसे और क्यों, आप Azure Table Storage और Azure Blob Storage पर कॉल की संख्या कम कर सकते हैं। हमारी सेवा में, लेखक अपने प्रकाशनों को पोस्ट करते हैं, जो तब विभिन्न साइटों में एम्बेडेड होते हैं। इस प्रकार, एक बार प्रकाशित सामग्री को बड़ी संख्या में संसाधनों पर प्रदर्शित किया जाता है, इसे हमारी सेवा के माध्यम से इन साइटों तक पहुंचाया जाता है। इसलिए, एज़्योर स्टोरेज तक पहुंच को कम करने के लिए, हम इंस्टेंस स्टोरेज में पब्लिशिंग कैशिंग का उपयोग करते हैं, क्योंकि इसके लिए कोई अतिरिक्त शुल्क नहीं है।
इसके अलावा, लेख इस बात पर सवाल उठाएगा कि कैशिंग का प्रबंधन कैसे करें यदि एक से अधिक उदाहरण हैं और इंस्टेंसेस के बीच कैशे स्थिति को कैसे सिंक्रनाइज़ किया जाए।
शुरू करने के लिए, विंडोज एज़्योर में सभी एप्लिकेशन डेटा को एप्लिकेशन या सर्विस इंस्टेंस के बाहर संग्रहीत किया जाना चाहिए, क्योंकि जब भूमिका को फिर से लोड किया जाता है, तो इंस्टेंस स्टोरेज में मौजूद सभी डेटा खो जाता है। हमारे साथ, यह हर 1-2 दिनों में एक बार औसतन होता है, क्योंकि सेवा अब बहुत सक्रिय विकास के चरण में है और तैनाती अक्सर करनी पड़ती है। इसलिए, सबसे प्रभावी समाधान इस डेटा को एज़्योर स्टोरेज में रखना है, जैसे कि एज़्योर टेबल स्टोरेज या एज़्योर ब्लॉब स्टोरेज। लेकिन इस भंडारण के साथ प्रत्येक ऑपरेशन के लिए हमसे शुल्क लिया जाता है। हालाँकि यह इतना बड़ा नहीं है, फिर भी मैं एज़्योर स्टोरेज तक पहुँचने की लागत को कम करना चाहता हूँ।
कैशिंग की शुरुआत के साथ, हम एज़्योर स्टोरेज के साथ संचालन की लागत को काफी कम करने में सक्षम थे। इसलिए, जब कोई प्रकाशन देखते हैं, तो यह केवल पहली बार Azure संग्रहण से चुना जाता है, और बाद के सभी कैश से। चूंकि लेखक शायद ही कभी अपने प्रकाशनों को संपादित करते हैं, इस स्तर पर कैश को अपडेट करने का मुख्य आरंभकर्ता एक नई तैनाती है। यहां तक कि अगर हम इस बात को ध्यान में रखते हैं कि तैनाती दिन में एक बार होती है, तो एक प्रकाशन को देखा जाता है, उदाहरण के लिए, दिन में 100 बार, एज़्योर स्टोरेज के लिए बचत 99% होगी। और यह सबसे लोकप्रिय प्रकाशन नहीं है।
कैशिंग समस्या को हल करने के लिए, हम इंस्टेंस स्टोरेज का उपयोग करेंगे। इसके साथ काम करने में सक्षम होने के लिए, आपको उपयुक्त नामस्थान कनेक्ट करने की आवश्यकता होगी:
using Microsoft.WindowsAzure; using Microsoft.WindowsAzure.ServiceRuntime;
उसके बाद, आपको स्थानीय भंडारण निर्धारित करने की आवश्यकता है। आप भूमिका सेटिंग्स में यह कर सकते हैं:
डिफ़ॉल्ट रूप से, भंडारण आकार 1000 एमबी पर सेट किया गया है, न्यूनतम आकार 1 एमबी हो सकता है, और अधिकतम भूमिका आकार पर निर्भर करता है। छोटे इंस्टेंस के लिए, यह आकार 165 जीबी होगा। आप इसके बारे में MSDN (
http://msdn.microsoft.com/en-us/library/ee758708.aspx ) पर अधिक पढ़ सकते हैं।
भंडारण की स्थापना के बाद, आप इसे केवल कुछ सुविधाओं के साथ एक नियमित फ़ाइल सिस्टम के साथ काम कर सकते हैं। फ़ाइल का स्थान निर्धारित करने के लिए, आपको स्टोर के पथ और स्टोर के रूट से फ़ाइल के सापेक्ष पथ को संयोजित करने की आवश्यकता है:
var Storage = RoleEnvironment.GetLocalResource(LocalResourceName); var FinalPath = Path.Combine(Storage.RootPath, RelativePath);
फ़ाइल सिस्टम में .NET ऑब्जेक्ट्स को स्टोर करने में सक्षम होने के लिए, उन्हें क्रमबद्ध करने की आवश्यकता है। इसके लिए हम JSON.Net लाइब्रेरी (
http://json.codeplex.com/ ) का उपयोग करते हैं।
इसके अलावा, यदि आप अपने आवेदन में एक से अधिक उदाहरणों का उपयोग करते हैं, तो कैश तात्कालिकता समस्या उत्पन्न होती है। यहां तक कि अगर आप कैश को एज़्योर स्टोरेज में डेटा बदलने से जुड़े इंस्टेंस पर अपडेट करते हैं, तो बाकी इंस्टेंस को इसके बारे में कुछ भी पता नहीं होगा। इससे निपटने के लिए, हमने पिछले लेख (
http://habrahabr.ru/post/140461/ ) में वर्णित उदाहरणों और भूमिकाओं के बीच संदेशों के आदान-प्रदान के लिए एक तंत्र विकसित किया है।
यहां इसका उपयोग कैश के उस हिस्से को हटाने की आवश्यकता के बारे में उदाहरण को सूचित करने के लिए किया जाता है जो अभी अप्रासंगिक हो गया है।
जैसा कि पहले उल्लेख किया गया है, AtContent.com पर हम प्रकाशन कैशिंग का उपयोग करते हैं। उसी समय, प्रकाशन को उदाहरण द्वारा कैश किया जाता है जब इसे एज़्योर स्टोरेज से चुना जाता है। इस प्रकार, उदाहरण कैशे पॉपुलेटेड है जब आप प्रकाशनों का उपयोग करते हैं। जब प्रकाशन लेखक द्वारा अद्यतन किया जाता है, तो इस प्रकाशन के लिए कैश को साफ़ करने की आवश्यकता के बारे में भूमिका के सभी उदाहरणों के लिए एक संदेश भेजा जाता है, और कैश को संसाधित करने के बाद, यह फिर से प्रासंगिक हो जाता है।
यह तंत्र हमें एज़्योर स्टोरेज की लागत को कम करने और उदाहरण की सभी विशेषताओं का प्रभावी ढंग से उपयोग करने की अनुमति देता है।
विंडोज एज़्योर में कैश के रूप में, आप न केवल हार्ड ड्राइव, बल्कि रैम या विंडोज एज़्योर कैश का उपयोग कर सकते हैं। यदि किसी डेटा के साथ काम करने की गति को बढ़ाने की आवश्यकता है तो उनका उपयोग उचित है। इसके अलावा, इस डेटा की मात्रा बड़ी नहीं हो सकती। एक उदाहरण पर रैम की मात्रा हार्ड ड्राइव की मात्रा से काफी कम है। विंडोज एज़्योर कैश भी बड़ी मात्रा में डेटा प्रदान नहीं करता है - जो अधिकतम राशि प्राप्त की जा सकती है वह 4 जीबी है, और आपको इसके लिए प्रति माह $ 325 का भुगतान करना होगा (
http://www.windowsazure.com/ru-ru/home/tour/caching/ ) ।
इसलिए, यदि आपको वास्तव में डेटा के लिए एज़्योर स्टोरेज एक्सेस की संख्या को कम करने की आवश्यकता है जो शायद ही कभी बदलती है लेकिन अक्सर पढ़ने के लिए आवश्यक होती है, तो लेख में वर्णित तंत्र आपके लिए बहुत उपयोगी हो सकता है। यह CPlase OpenSource लाइब्रेरी के हिस्से के रूप में भी उपलब्ध होगा, जो जल्द ही सार्वजनिक रूप से उपलब्ध होगा।
श्रृंखला में पढ़ें: