विंडोज Azure कतार स्केलिंग

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

परिचय

पारंपरिक कतार-आधारित संदेश समाधान एक संदेश पंक्ति नामक एक रिपॉजिटरी का उपयोग करते हैं। यह अतुल्यकालिक विनिमय तंत्र का उपयोग कर प्रतिभागियों द्वारा प्राप्त या प्रसारित डेटा का भंडार है।

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

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

लिपि

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

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

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

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

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

समाधान की वास्तुकला इस प्रकार है:


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

कतारबद्ध मैसेजिंग की मूल बातें

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

उच्च स्तर पर, दो मुख्य प्रेषण तंत्र का उपयोग किया जाता है जो कतार के श्रोता को इसमें संग्रहीत संदेश प्राप्त करने की अनुमति देते हैं:

• पोल (क्वेरी-आधारित मॉडल - मतदान) : श्रोता कतार की निगरानी करता है, नियमित अंतराल पर उसमें नए संदेशों की जाँच करता है। यदि कतार खाली है, तो श्रोता कतार को क्वेरी करना जारी रखता है, समय-समय पर स्लीप अवस्था में बदलता रहता है।
• स्विचिंग (मजबूर डेटा भेजने के आधार पर मॉडल को धक्का देना) : श्रोता उस घटना के लिए सदस्यता लेता है जो ट्रिगर के साथ जुड़ा हुआ है (प्रकाशक या कतार प्रबंधक द्वारा) जब एक संदेश कतार में भेजा जाता है तो ट्रिगर होता है। श्रोता संदेश के प्रसंस्करण की शुरुआत कर सकता है, इसलिए उसे नए डेटा की उपलब्धता का निर्धारण करने के लिए कतार को फिर से क्वेरी नहीं करना होगा।

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

नोट। Windows Azure कतार सेवा API द्वारा समर्थित dequeue कार्रवाई नॉन-ब्लॉकिंग है। इसका अर्थ है कि संदेश कतार खाली होने पर गेटमेसेज या गेटमैसेज एपीआई तरीके तुरंत बाहर हो जाएंगे। इसके विपरीत, Windows Azure एकीकरण बस उपयोग अवरुद्ध संदेश पुनर्प्राप्ति संचालन द्वारा प्रदान किए गए टिकाऊ संदेश बफ़र्स (DMBs), जिसमें कॉलिंग थ्रेड को तब तक अवरुद्ध किया जाता है जब तक कि कोई संदेश DMB कतार में या एक निर्दिष्ट समय समाप्त हो जाता है।

Windows Azure कतार श्रोताओं के सॉफ़्टवेयर कार्यान्वयन के लिए सबसे आम दृष्टिकोण को प्रतिष्ठित किया जा सकता है:

1. श्रोता को एक अनुप्रयोग घटक के रूप में लागू किया जाता है, जिसका एक उदाहरण कार्य भूमिका के भाग के रूप में बनाया और निष्पादित किया जाता है।
2. एक भूमिका श्रोता घटक का जीवन चक्र अक्सर होस्ट की गई भूमिका के निष्पादन के समय से जुड़ा होता है।
3. मुख्य प्रसंस्करण तर्क एक लूप है जिसके माध्यम से संदेशों को कतारों से हटा दिया जाता है और प्रसंस्करण के लिए भेजा जाता है।
4. यदि प्राप्त संदेशों की कतार खाली है, तो श्रोता स्लीप मोड में प्रवेश करता है, जिसकी अवधि सिस्टम को रोकने के लिए एल्गोरिदम द्वारा निर्धारित की जाती है और आवेदन पर निर्भर करती है।
5. संदेश प्राप्त करने के लिए कार्यक्रम चक्र का प्रदर्शन किया जाता है; जब तक श्रोता लूप से बाहर निकलने और अपना काम पूरा करने के लिए एक अधिसूचना प्राप्त नहीं करता तब तक कतार में पूछताछ की जाती है।

निम्न फ़्लोचार्ट एक विंडोज एज़्योर वातावरण में एक अंतर्निहित पोलिंग तंत्र के साथ एक कतार श्रोता को लागू करने के लिए मानक तर्क को दिखाता है।

नोट। उदाहरण के लिए, अधिक जटिल निर्णय पैटर्न की चर्चा, एक केंद्रीय कतार प्रबंधक (दलाल) की आवश्यकता होती है, इस दस्तावेज़ के दायरे से परे है।

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

समाधान लागत को कम करने, प्रदर्शन और मापनीयता सुनिश्चित करने के लिए सिफारिशें

यह खंड डिजाइन विधियों का वर्णन करता है जो उत्पादकता बढ़ाता है और स्केलेबिलिटी में सुधार करता है, साथ ही टर्नकी समाधान की लागत को कम करता है।

सिस्टम कार्यान्वयन टेम्प्लेट को एक अधिक प्रभावी समाधान कहा जा सकता है, यदि यह निम्नलिखित लक्ष्यों की उपलब्धि सुनिश्चित करता है:

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

कार्यान्वयन टेम्पलेट को सिस्टम को जटिल किए बिना इन कार्यों को करना चाहिए, अन्यथा इसके कार्यान्वयन के लाभ शून्य हो जाएंगे।

भंडारण के साथ डेटा का आदान-प्रदान करते समय लेनदेन की लागत के अनुकूलन के लिए सिफारिशें

विंडोज एज़्योर प्लेटफ़ॉर्म पर तैनात समाधान के स्वामित्व (TCO) की कुल लागत और निवेश पर वापसी (ROI) के संकेतकों का मूल्यांकन करते समय, TCO सूत्र के सबसे महत्वपूर्ण चर में से एक भंडारण के साथ डेटा एक्सचेंज के दौरान लेनदेन की मात्रा है। विंडोज एज़्योर कतार के साथ डेटा का आदान-प्रदान करने के लिए लेनदेन की संख्या कम करने से विंडोज एज़्योर समाधान के उपयोग से जुड़ी परिचालन लागत कम हो सकती है।

कतार-आधारित मैसेजिंग समाधान को लागू करते समय, डेवलपर्स भंडारण के साथ डेटा विनिमय लेनदेन की संख्या को कम कर सकते हैं।

1. कतार में संदेश भेजते समय, आप एक दूसरे से संबंधित संदेशों को एक बड़े पैकेज में समूहित कर सकते हैं, और संकुचित छवि को बूँद भंडारण में संग्रहीत कर सकते हैं, और फिर इस डेटा के साथ लिंक को बूँद में संग्रहीत करने के लिए कतार का उपयोग कर सकते हैं।
2. कतार से संदेश प्राप्त करते समय, आप भंडार के साथ डेटा के आदान-प्रदान पर लेनदेन करने के लिए कई संदेशों को एक पैकेज में जोड़ सकते हैं । कतार सेवा API में कार्यान्वित GetMessages विधि यह सुनिश्चित करती है कि एक निर्दिष्ट लेन-देन से एक पंक्ति में संदेशों की एक निर्दिष्ट संख्या हटा दी जाती है (नीचे नोट देखें)।
3. कतार में काम की वस्तुओं की उपस्थिति की जांच करते समय, आक्रामक मतदान अंतराल का उपयोग करने से बचें और एक समय विलंब सेट करें जो कि कतार के मतदान अंतराल को बढ़ाता है यदि इसके लिए अनुरोध डेटा वापस नहीं करता है।
4. कतार श्रोताओं की संख्या कम करें - क्वेरी-आधारित मॉडल का उपयोग करते समय, प्रत्येक भूमिका उदाहरण के लिए केवल एक श्रोता का उपयोग करें जब कतार खाली हो। प्रत्येक भूमिका उदाहरण के लिए श्रोताओं की संख्या को कम करने के लिए, श्रवण उदाहरणों को बनाने के लिए सूचना तंत्र का उपयोग करें जब कतार कार्य आइटम प्राप्त करती है।
5. यदि काम की कतारें अधिकांश समय खाली रहती हैं, तो सिस्टम मेट्रिक्स की निगरानी करने के लिए सिस्टम मेट्रिक्स की संख्या को स्वचालित रूप से कम करने के लिए एक तंत्र बनाएं , जब यह निर्धारित करने के लिए कि अनुप्रयोग को बढ़े हुए कार्यभार को संभालने के लिए भूमिका इंस्टेंसेस की संख्या बढ़ाने की आवश्यकता है।

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

महत्वपूर्ण जानकारी । जब आप GetMessages विधि का उपयोग करके संदेश प्राप्त करते हैं, तो कतार से हटाए जाने वाले ऑपरेशन के लिए अधिकतम कतार सेवा एपीआई पैकेज का आकार 32 होता है। इस मूल्य से अधिक होने पर एक रनटाइम अपवाद होगा।

विंडोज एज़्योर कतारों में लेन-देन की लागत रैखिक रूप से बढ़ जाती है क्योंकि कतार सेवा ग्राहकों की संख्या बढ़ जाती है, उदाहरण के लिए, जब रोल इंस्टेंसेस की संख्या को स्केलिंग या जब डिलीट थ्रेड की संख्या बढ़ जाती है। उपरोक्त सिफारिशों को ध्यान में रखते हुए किसी समाधान को लागू करते समय लागत में संभावित वृद्धि को प्रदर्शित करने के लिए, हम विशिष्ट आंकड़ों के साथ एक उदाहरण देते हैं।

लागत पर अकुशल वास्तुकला का प्रभाव

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

परिदृश्य की परिभाषा के अनुसार, सॉफ्टवेयर समाधान नियमित अंतराल पर व्यावसायिक लेनदेन डेटा प्राप्त करता है। मान लीजिए कि यह समाधान मानक आठ घंटे के कार्य दिवस के समय के केवल 25% के कार्यभार को संसाधित करने में व्यस्त है। परिणामस्वरूप, 6 घंटे (8 घंटे * 0.75) "निष्क्रियता समय" पर गिर जाता है जब सिस्टम लेनदेन प्रसंस्करण में शामिल नहीं होता है। इसके अलावा, समाधान 16 घंटे के लिए हर दिन घंटों के बाद डेटा प्राप्त नहीं करता है।

निष्क्रियता की अवधि के दौरान, जो 22 घंटे का योग देता है, समाधान नए डेटा को जोड़ने के बारे में सूचनाएं प्राप्त किए बिना कतार से काम की जानकारी को हटाने की कोशिश करता है। इस समय के दौरान, कतार से हटाने का प्रत्येक व्यक्ति धागा एक सेकंड के डिफ़ॉल्ट मतदान अंतराल के साथ इनपुट कतार से जुड़े 79,200 लेनदेन (22 घंटे * 60 मिनट * प्रति मिनट 60 लेनदेन) तक करता है।

जैसा कि ऊपर कहा गया है, विंडोज एज़्योर प्लेटफ़ॉर्म मूल्य निर्धारण मॉडल आधार इकाई के रूप में अलग "स्टोरेज लेनदेन" का उपयोग करता है। एक रिपॉजिटरी लेनदेन एक उपयोगकर्ता एप्लिकेशन का अनुरोध है कि रिपॉजिटरी डेटा को जोड़ने, पढ़ने, अपडेट करने या हटाने के लिए। इस श्वेत पत्र के लेखन के समय, गोदाम की लेनदेन लागत $ 10,000 प्रति लेनदेन थी। अद्यतन : हस्तांतरण के प्रकाशन के समय: $ 100,000 प्रति लेनदेन।

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

ऊपर वर्णित परिदृश्य में एक एकल कतार विलोपन प्रवाह द्वारा बनाई गई तिजोरी लेनदेन मासिक सेवा बिल में लगभग $ 2.38 ($ 79,200 / 10,000 * $ 0.01 * 30 दिन) जोड़ देगा। कतार से संदेशों को हटाने के लिए 200 धागे (या काम की भूमिका की 200 प्रतियों में एक धागा) आपके मासिक खर्च को $ 457.2 ( UPDATE : यदि आप लेख के अनुवाद के प्रकाशन के समय पर गणना करते हैं, तो यह 45.7 डॉलर है) बढ़ा देगा। ये लागत तब उत्पन्न होती है जब सिस्टम कोई गणना नहीं करता है, लेकिन केवल कतार में काम की वस्तुओं की उपस्थिति के लिए जांच करता है। उपरोक्त उदाहरण सार है, क्योंकि कोई भी इस तरह से सेवा को लागू नहीं करेगा। आपको निम्नलिखित अनुकूलन तकनीकों का उपयोग करना चाहिए।

अनावश्यक देरी को खत्म करने के लिए सिफारिशें

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

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

कतार का उपयोग करके एक मैसेजिंग सिस्टम बनाने की प्रक्रिया निम्नलिखित पैटर्न का उपयोग कर सकती है:

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

महत्वपूर्ण जानकारी । Windows Azure एकीकरण बस का उपयोग एक मूल्य निर्धारण योजना द्वारा नियंत्रित किया जाता है जो इस प्रक्रिया के दो महत्वपूर्ण घटकों को ध्यान में रखता है। सबसे पहले, डेटा केंद्रों का आदान-प्रदान करते समय डेटा प्राप्त करने और भेजने के लिए एक शुल्क लिया जाता है। दूसरे, आवेदन और एकीकरण बस बुनियादी ढांचे के बीच स्थापित कनेक्शन की संख्या के लिए एक शुल्क लिया जाता है।
इस संबंध में, विशिष्ट वास्तुकला को लागू करने के लिए एकीकरण बस का उपयोग करने के सभी सकारात्मक और नकारात्मक पहलुओं का मूल्यांकन करने के लिए लागत और लाभों का विश्लेषण करना महत्वपूर्ण है। यह आकलन किया जाना चाहिए कि एकीकरण बस के आधार पर अधिसूचना प्रेषण स्तर के कार्यान्वयन से वास्तव में लागत में कमी आएगी, जो इस परियोजना में निवेश और डेवलपर्स की अतिरिक्त श्रम लागत को सही ठहरा सकती है।

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

डायनामिक स्केलिंग दिशानिर्देश

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

गतिशील स्केलिंग- यह एक विशेष समाधान की एक तकनीकी विशेषता है जो आपको रनवे के लिए उपलब्ध स्टोरेज स्पेस और कंप्यूटिंग शक्ति को बढ़ाकर और कम करके एक चर वर्कलोड के अनुकूल होने की अनुमति देता है। विंडोज एज़्योर प्लेटफ़ॉर्म में वितरित कंप्यूटिंग अवसंरचना का उपयोग करके डायनेमिक स्केलिंग के लिए अंतर्निहित समर्थन शामिल है जो उपभोक्ताओं को एक निर्धारित शुल्क के लिए आवश्यक शक्ति आवंटित करने की अनुमति देता है।

Windows Azure प्लेटफ़ॉर्म द्वारा समर्थित दो प्रकार की डायनेमिक स्केलिंग में अंतर करना महत्वपूर्ण है:

• - . . Windows Azure , , .
• () ( ) .

भूमिका-आधारित संदेश समाधान में डायनामिक स्केलिंग लागू करने के लिए निम्नलिखित अनुशंसाओं की आवश्यकता होती है:

1. सीपीयू उपयोग, कतार गहराई, प्रतिक्रिया समय और संदेश प्रसंस्करण विलंबता सहित प्रमुख प्रदर्शन मीट्रिक ट्रैक करें ।
2. गतिशील रूप से चोटी के कार्यभार को संभालने के लिए कार्य भूमिका की संख्या में वृद्धि या कमी , दोनों अपेक्षित और अप्रत्याशित।
3. वर्कलोड के विभिन्न संकेतकों के लिए सिस्टम को अनुकूलित करने के लिए प्रसंस्करण थ्रेड्स की संख्या में उल्लेखनीय रूप से वृद्धि और कमी करें ।
4. .NET फ्रेमवर्क 4 के टास्क पैरेलल लाइब्रेरी का उपयोग करके कार्य विभाजन और छोटे टुकड़ों के समानांतर प्रसंस्करण ।
5. वर्कलोड के एक चर स्तर के साथ समाधान का प्रबंधन करते समय कंप्यूटिंग शक्ति की उपलब्धता सुनिश्चित करें ; यह अतिरिक्त प्रतियाँ बनाने के लिए अतिरिक्त प्रयास किए बिना, भार में अचानक वृद्धि का सामना करने की अनुमति देगा।

सेवा प्रबंधन API, Windows Azure प्लेटफ़ॉर्म पर होस्ट की गई सेवाओं को रनटाइम में परिनियोजन कॉन्फ़िगरेशन बदलकर भूमिका उदाहरणों की संख्या बढ़ाने या घटाने की अनुमति देता है।

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

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

महत्वपूर्ण जानकारी . Windows Azure 500 . , , , , HTTP- 503 « ». . HTTP 503 , , .

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

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

स्केलिंग पर देरी के समय के प्रभाव, भंडारण के साथ डेटा विनिमय के दौरान लेनदेन की लागत और गतिशील स्केलिंग के लिए आवश्यकताओं पर चर्चा करने के बाद, हम इन सिफारिशों के व्यावहारिक कार्यान्वयन की ओर मुड़ते हैं।

तकनीकी कार्यान्वयन

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

यह खंड विंडोज एज़्योर एप्लिकेशन के डेवलपर्स के लिए अभिप्रेत है और टेम्प्लेट के सॉफ़्टवेयर कार्यान्वयन का वर्णन करता है।

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

एक मानक कतार श्रोता बनाना

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

///    ,     Windows Azure. public interface ICloudQueueServiceWorkerRoleExtension { ///    ,         . void StartListener(int threadCount); ///            . CloudQueueListenerInfo QueryState(); ///             Windows Azure. int DequeueBatchSize { get; set; } ///      ,           . TimeSpan DequeueInterval { get; set; } ///    , ,   . event WorkCompletedDelegate QueueEmpty; } 

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

 /// <summary> ///    ,        ///       . /// </summary> /// <param name="sender"> .</param> /// <param name="idleCount"> ,    .</param> /// <param name="delay">,             .</param> /// <returns>,              .</returns> public delegate bool WorkCompletedDelegate(object sender, int idleCount, out TimeSpan delay); 

प्रसंस्करण कतार तत्वों को श्रोताओं को बनाकर सरल बनाया जा सकता है जो एसडीके में निर्मित वर्गों का उपयोग करने के बजाय जेनेरिक टेम्पलेट्स का समर्थन करते हैं, जैसे कि क्लाउडक्यूयू मेसेज । यूनिवर्सल कतार एक्सेस पैटर्न के समर्थन के साथ एक नया कतार श्रोता इंटरफ़ेस बनाएँ:

 /// <summary> ///     ,       . /// </summary> /// <typeparam name="T">   ,     .</typeparam> public interface ICloudQueueListenerExtension<T> : ICloudQueueServiceWorkerRoleExtension, IObservable<T> { } 

कृपया ध्यान दें: हमने .NET फ्रेमवर्क 4 में उपलब्ध IObservable इंटरफ़ेस का उपयोग करके ऑब्जर्वर डिज़ाइन टेम्पलेट को लागू करके एक या कई ग्राहकों को कतार तत्वों को प्रसारित करने के लिए सार्वभौमिक टेम्प्लेट के समर्थन के साथ श्रोता को भी अनुमति दी।
हम उस घटक के एक उदाहरण को बचाने का इरादा रखते हैं जिसमें ICloudQueueListenerExtension इंटरफ़ेस कार्यान्वित किया गया है। हालाँकि, हमें कतार से संदेश निकालने के लिए एक साथ कई थ्रेड (कार्य) चलाने की क्षमता की आवश्यकता होती है। इसलिए, हम श्रोता घटक में कतार से संदेशों को हटाने के लिए मल्टीथ्रेडेड तर्क के लिए समर्थन जोड़ते हैं। इस समस्या को हल करने के लिए, समानांतर डाटा प्रोसेसिंग टास्क पैरेलल लाइब्रेरी (TPL) के कार्यों के एक पुस्तकालय का उपयोग किया जाता है। StartListener विधि हमें कतार से संदेश निकालने के लिए आवश्यक संख्या में थ्रेड बनाने की अनुमति देगी:

 /// <summary> ///        . /// </summary> /// <param name="threadCount">     .</param> public void StartListener(int threadCount) { Guard.ArgumentNotZeroOrNegativeValue(threadCount, "threadCount"); //             . if (this.dequeueTasks.IsAddingCompleted) { this.dequeueTasks = new BlockingCollection<Task>(this.dequeueTaskList); } for (int i = 0; i < threadCount; i++) { CancellationToken cancellationToken = this.cancellationSignal.Token; CloudQueueListenerDequeueTaskState<T> workerState = new CloudQueueListenerDequeueTaskState<T>(Subscriptions, cancellationToken, this.queueLocation, this.queueStorage); //             ,      . this.dequeueTasks.Add(Task.Factory.StartNew(DequeueTaskMain, workerState, cancellationToken, TaskCreationOptions.LongRunning, TaskScheduler.Default)); } //    ,    . this.dequeueTasks.CompleteAdding(); } 

DequeueTaskMain विधि कतार से संदेशों को हटाने वाले थ्रेड के कार्यों को लागू करती है। यह निम्नलिखित बुनियादी कार्यों का समर्थन करता है:

 /// <summary> ///        Windows Azure. /// </summary> /// <param name="state">,    .</param> private void DequeueTaskMain(object state) { CloudQueueListenerDequeueTaskState<T> workerState = (CloudQueueListenerDequeueTaskState<T>)state; int idleStateCount = 0; TimeSpan sleepInterval = DequeueInterval; try { //          ,             . while (workerState.CanRun) { try { var queueMessages = from msg in workerState.QueueStorage.Get<T>(workerState.QueueLocation.QueueName, DequeueBatchSize, workerState.QueueLocation.VisibilityTimeout).AsParallel() where msg != null select msg; int messageCount = 0; //            PLINQ. queueMessages.ForAll((message) => { //     . idleStateCount = 0; //       ,   . workerState.OnNext(message); //    ,     . workerState.QueueStorage.Delete<T>(message); //       . messageCount++; }); // ,       . if (0 == messageCount) { //     ,        (,     ). idleStateCount++; //    ,      . if (QueueEmpty != null) { // ,          . if (QueueEmpty(this, idleStateCount, out sleepInterval)) { //      ,      . break; } } //        . Thread.Sleep(sleepInterval); } } catch (Exception ex) { if (ex is OperationCanceledException) { throw; } else { //           . workerState.OnError(ex); //        ,         . Thread.Sleep(sleepInterval); } } } } finally { workerState.OnCompleted(); } } 

DequeueTaskMain पद्धति के कार्यान्वयन सुविधाओं से संबंधित कुछ स्पष्टीकरण करना आवश्यक है।
पहले, समानांतर LINQ (PLINQ) विधि का उपयोग बाद के प्रसंस्करण के उद्देश्य के लिए संदेश भेजने के लिए किया जाता है।

इस समस्या को हल करने के लिए PLINQ का उपयोग करने का मुख्य लाभ यह है कि जब भी संभव हो विभिन्न प्रोसेसर पर अलग-अलग वर्कफ़्लो में प्रतिनिधि के समानांतर उपयोग के कारण संदेश प्रसंस्करण का त्वरण होता है।

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

दूसरे, हम प्रत्येक विशिष्ट संदेश प्राप्त करने के लिए अलग-अलग अनुरोध नहीं बनाते हैं। इसके बजाय, कतार सेवा API का उपयोग कतार से संदेशों की निर्दिष्ट संख्या प्राप्त करने के लिए किया जाता है। प्राप्त संदेशों की संख्या DequeueBatchSize पैरामीटर द्वारा निर्धारित की जाती है, जो कि गेट विधि को पारित किया जाता है। डेटा वेयरहाउस एब्स्ट्रैक्शन लेवल तक पहुँचने पर, यह पैरामीटर क्यू सर्विस एपीआई को पास कर दिया जाता है। इसके अलावा, यह सुनिश्चित करने के लिए एक सुरक्षा जांच की जाती है कि पैकेट का आकार एपीआई के लिए अनुमत अधिकतम सीमा से अधिक न हो। निम्नलिखित इस दृष्टिकोण का एक सॉफ्टवेयर कार्यान्वयन है:

 ///          Windows Azure    . public sealed class ReliableCloudQueueStorage : ICloudQueueStorage { ///   ,   API  Queue Service     Get. private const int MaxDequeueMessageCount = 32; ///             . public IEnumerable<T> Get<T>(string queueName, int count, TimeSpan visibilityTimeout) { Guard.ArgumentNotNullOrEmptyString(queueName, "queueName"); Guard.ArgumentNotZeroOrNegativeValue(count, "count"); try { var queue = this.queueStorage.GetQueueReference(CloudUtility.GetSafeContainerName(queueName)); IEnumerable<CloudQueueMessage> queueMessages = this.retryPolicy.ExecuteAction<IEnumerable<CloudQueueMessage>>(() => { return queue.GetMessages(Math.Min(count, MaxDequeueMessageCount), visibilityTimeout); }); // ...     ... 

अंत में, हम ध्यान दें कि हम संदेश को कतार से अनिश्चित काल के लिए हटाने का कार्य पूरा करने का इरादा नहीं रखते हैं। हमने एक स्पष्ट रूप से परिभाषित चेकपॉइंट बनाया, जिसे क्वेइम खाली घटना के रूप में लागू किया गया, जिसे हर बार कतार खाली होने के बाद कहा जाता है। इस स्थिति में, QueueEmpty इवेंट हैंडलर कहा जाता है , जो निर्धारित करता है कि क्या कतार से संदेशों को हटाने का कार्य पूरा हो सकता है। क्यूएमी खाली इवेंट हैंडलर का सही कार्यान्वयन "स्वचालित कमी" के लिए समर्थन प्रदान करता है, जिसकी चर्चा अगले भाग में की गई है।

कतार से संदेशों को हटाने के कार्य को स्वचालित रूप से कम करें

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

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

 private bool HandleQueueEmptyEvent(object sender, int idleCount, out TimeSpan delay) { //     ICloudQueueServiceWorkerRoleExtension,     . ICloudQueueServiceWorkerRoleExtension queueService = sender as ICloudQueueServiceWorkerRoleExtension; //    ,         . IWorkItemProcessorConfigurationExtension config = Extensions.Find<IWorkItemProcessorConfigurationExtension>(); //              . CloudQueueListenerInfo queueServiceState = queueService.QueryState(); //   ,   . int deltaBackoffMs = 100; int minimumIdleIntervalMs = Convert.ToInt32(config.Settings.MinimumIdleInterval.TotalMilliseconds); int maximumIdleIntervalMs = Convert.ToInt32(config.Settings.MaximumIdleInterval.TotalMilliseconds); //               . int delta = (int)((Math.Pow(2.0, (double)idleCount) - 1.0) * (new Random()).Next((int)(deltaBackoffMs * 0.8), (int)(deltaBackoffMs * 1.2))); int interval = Math.Min(minimumIdleIntervalMs + delta, maximumIdleIntervalMs); //                 . delay = TimeSpan.FromMilliseconds((double)interval); //               , //          .    ,        . return delay.TotalMilliseconds >= maximumIdleIntervalMs && queueServiceState.ActiveDequeueTasks > 1; } 

स्वचालित स्केलिंग तंत्र को निम्नानुसार वर्णित किया जा सकता है:

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

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

 ///  ,        . public struct CloudQueueListenerInfo { ///       Windows Azure. public int CurrentQueueDepth { get; internal set; } ///       ,       . public int ActiveDequeueTasks { get; internal set; } ///         ,  . public int TotalDequeueTasks { get; internal set; } } 

दूसरे, कतार श्रोता एक विधि का उपयोग करता है जो अपने लोड मैट्रिक्स को लौटाता है (नीचे उदाहरण देखें)।

 ///            . public CloudQueueListenerInfo QueryState() { return new CloudQueueListenerInfo() { CurrentQueueDepth = this.queueStorage.GetCount(this.queueLocation.QueueName), ActiveDequeueTasks = (from task in this.dequeueTasks where task.Status != TaskStatus.Canceled && task.Status != TaskStatus.Faulted && task.Status != TaskStatus.RanToCompletion select task).Count(), TotalDequeueTasks = this.dequeueTasks.Count }; } 

स्वचालित रूप से पैमाने हटाएं कार्यों को हटा दें

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

घटनाओं को ट्रिगर करने के लिए एक खाली से गैर-खाली कतार में संक्रमण को ट्रैक करने के लिए एक प्रतिनिधि बनाएं, उदाहरण के लिए, स्वचालित स्केलिंग:

 /// <summary> ///  ,        ,    . /// </summary> /// <param name="sender"> .</param> public delegate void WorkDetectedDelegate(object sender);     ICloudQueueServiceWorkerRoleExtension,      ,   ,        (       ): public interface ICloudQueueServiceWorkerRoleExtension { // ...    ,   . .        ... ///  ,        ,    . event WorkDetectedDelegate QueueWorkDetected; } 

आइए हम निर्धारित करें कि कतार श्रोता के कार्यक्रम कोड की किस पंक्ति में घटना को ट्रिगर किया जाना चाहिए। हमारे मामले में, क्यूक्वेर्कडिकेटेड ईवेंट को DequeueTaskMain पद्धति का उपयोग करके कार्यान्वित किए गए डीक्यू लूप से बुलाया जाएगा, जिसे निम्नानुसार विस्तारित किया जाना चाहिए:

 public class CloudQueueListenerExtension<T> : ICloudQueueListenerExtension<T> { //  ,        ,    . public event WorkDetectedDelegate QueueWorkDetected; private void DequeueTaskMain(object state) { CloudQueueListenerDequeueTaskState<T> workerState = (CloudQueueListenerDequeueTaskState<T>)state; int idleStateCount = 0; TimeSpan sleepInterval = DequeueInterval; try { //          ,             . while (workerState.CanRun) { try { var queueMessages = from msg in workerState.QueueStorage.Get<T>(workerState.QueueLocation.QueueName, DequeueBatchSize, workerState.QueueLocation.VisibilityTimeout).AsParallel() where msg != null select msg; int messageCount = 0; //      ,   . if (idleStateCount > 0 && queueMessages.Count() > 0) { if (QueueWorkDetected != null) { QueueWorkDetected(this); } } // ...    ,   . .        ... 

अंतिम चरण में, एक QueueWorkDetected इवेंट हैंडलर बनाएँ। इस ईवेंट हैंडलर का कार्यान्वयन उस घटक में सम्‍मिलित होगा जो कतार श्रोता को तत्‍काल करता है। हमारे मामले में, यह घटक काम कर रहा है। ईवेंट हैंडलर को लागू करने और उसकी आवृत्ति बनाने के लिए जिम्मेदार प्रोग्राम कोड में निम्नलिखित भाग होते हैं:

 public class WorkItemProcessorWorkerRole : RoleEntryPoint { //  Windows Azure    . public override sealed bool OnStart() { // ...      ... //       . var inputQueueListener = new CloudQueueListenerExtension<XDocument>(inputQueueLocation); //    . inputQueueListener.QueueEmpty += HandleQueueEmptyEvent; inputQueueListener.QueueWorkDetected += HandleQueueWorkDetectedEvent; inputQueueListener.DequeueBatchSize = configSettingsExtension.Settings.DequeueBatchSize; inputQueueListener.DequeueInterval = configSettingsExtension.Settings.MinimumIdleInterval; // ...     ... } ///  ,        ,    . private void HandleQueueWorkDetectedEvent(object sender) { //     ICloudQueueServiceWorkerRoleExtension,     . ICloudQueueServiceWorkerRoleExtension queueService = sender as ICloudQueueServiceWorkerRoleExtension; //              . CloudQueueListenerInfo queueServiceState = queueService.QueryState(); //         ,     . int dequeueTaskCount = GetOptimalDequeueTaskCount(queueServiceState.CurrentQueueDepth); //             ,         . if (queueServiceState.ActiveDequeueTasks < dequeueTaskCount) { //       . queueService.StartListener(dequeueTaskCount - queueServiceState.ActiveDequeueTasks); } } // ...     ... 

उपरोक्त उदाहरण के प्रकाश में, आपको GetOptimalDequeueTaskCount विधि के उपयोग को स्पष्ट करने की आवश्यकता है । यह विधि कार्यभार को संभालने के लिए कतार हटाने के कार्यों की संख्या की गणना के लिए जिम्मेदार है। कॉल करते समय, यह निर्धारित करना आवश्यक है (किसी भी उपयुक्त निर्णय लेने वाले तंत्र का उपयोग करके) कतार के श्रोता को अपेक्षित अधिभार को संसाधित करने के लिए कितनी कंप्यूटिंग शक्ति की आवश्यकता होती है।

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

निम्न उदाहरण कतार से हटाने के कार्यों की इष्टतम संख्या निर्धारित करने के लिए एक सरलीकृत विधि का उपयोग करता है:

 /// <summary> ///         ,     . /// </summary> /// <param name="currentDepth">    .</param> /// <returns>     .</returns> private int GetOptimalDequeueTaskCount(int currentDepth) { if (currentDepth < 100) return 10; if (currentDepth >= 100 && currentDepth < 1000) return 50; if (currentDepth >= 1000) return 100; //    . return 1; } 

उपरोक्त कोड उदाहरण एक सार्वभौमिक समाधान नहीं हो सकता है। आदर्श के करीब एक समाधान एक नियम को कॉल करना है जो बाहर से कॉन्फ़िगरेशन और नियंत्रण का समर्थन करता है और सभी आवश्यक गणना करने में सक्षम है।

वर्तमान में, एक कतार श्रोता का एक कार्यशील प्रोटोटाइप है जो स्वचालित रूप से कार्यभार में उतार-चढ़ाव (वृद्धि या कमी) के अनुसार स्केल कर सकता है। शायद इसके कार्यों का विस्तार इसके प्रसंस्करण के दौरान कार्यभार में उतार-चढ़ाव के अनुकूल करने के लिए किया जाना चाहिए। आप इस फ़ंक्शन को उसी टेम्पलेट को लागू करके जोड़ सकते हैं जिसका उपयोग QueueWorkDetected इवेंट के लिए समर्थन जोड़ने के लिए किया गया था ।

कतार श्रोताओं के साथ काम करते समय देरी समय को कम करने के लिए एक और महत्वपूर्ण अनुकूलन विधि पर विचार करने के लिए आगे बढ़ते हैं।

शून्य देरी के साथ कतार से हटाने के लिए प्रकाशक और ग्राहक स्तर का कार्यान्वयन

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

एक नया कार्यभार दिखाई देने पर कतार श्रोता द्वारा प्राप्त एक ट्रिगर इवेंट बनाएँ:

 ///  -,         . [DataContract(Namespace = WellKnownNamespace.DataContracts.Infrastructure)] public class CloudQueueWorkDetectedTriggerEvent { ///     ,    . [DataMember] public string StorageAccount { get; private set; } ///   ,     . [DataMember] public string QueueName { get; private set; } ///      (,       ). [DataMember] public long PayloadSize { get; private set; } // ...      ... } 

बता दें कि कतार श्रोता कार्यान्वयन ट्रिगर इवेंट प्राप्त करने वाले ग्राहकों के रूप में कार्य करते हैं। पहला कदम क्लाउड श्रोता को CloudQueueWorkDetectedTriggerEvent ईवेंट के लिए पर्यवेक्षक के रूप में नामित करना है :

 ///    ,     Windows Azure. public interface ICloudQueueServiceWorkerRoleExtension : IObserver<CloudQueueWorkDetectedTriggerEvent> { // ...  , . .      ... } 

दूसरा कदम IObserver इंटरफ़ेस में परिभाषित OnNext विधि का कार्यान्वयन होगा । इस विधि को प्रदाता द्वारा एक नई घटना के पर्यवेक्षक को सूचित करने के लिए कहा जाता है:

 public class CloudQueueListenerExtension<T> : ICloudQueueListenerExtension<T> { // ...      ... /// <summary> ///          /// </summary> /// <param name="e">-,        .</param> public void OnNext(CloudQueueWorkDetectedTriggerEvent e) { Guard.ArgumentNotNull(e, "e"); // ,  -   ,  ;  ,    . if (this.queueLocation.StorageAccount == e.StorageAccount && this.queueLocation.QueueName == e.QueueName) { if (QueueWorkDetected != null) { QueueWorkDetected(this); } } } // ...     ... } 

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

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

 private bool HandleQueueEmptyEvent(object sender, int idleCount, out TimeSpan delay) { // ...      ... //               . return delay.TotalMilliseconds >= maximumIdleIntervalMs; } 

, , . QueueEmpty , .

CloudQueueWorkDetectedTriggerEvent , Windows Azure . , :

 public class InterRoleEventSubscriberExtension : IInterRoleEventSubscriberExtension { // ...      .     . ,     Windows Azure Customer Advisory Team ... public void OnNext(InterRoleCommunicationEvent e) { if (this.owner != null && e.Payload != null) { // ...      ... if (e.Payload is CloudQueueWorkDetectedTriggerEvent) { HandleQueueWorkDetectedTriggerEvent(e.Payload as CloudQueueWorkDetectedTriggerEvent); return; } // ...     ... } } private void HandleQueueWorkDetectedTriggerEvent(CloudQueueWorkDetectedTriggerEvent e) { Guard.ArgumentNotNull(e, "e"); //        -. foreach (var queueService in this.owner.Extensions.FindAll<ICloudQueueServiceWorkerRoleExtension>()) { //  -  . queueService.OnNext(e); } } } 

-, CloudQueueWorkDetectedTriggerEvent , , , . . - , :

 public class ProcessInitiatorWorkerRole : RoleEntryPoint { //   ,       . private volatile IInterRoleCommunicationExtension interRoleCommunicator; // ...      .     . ,     Windows Azure Customer Advisory Team ... private void HandleWorkload() { //  1.   ,     . // ... (    ) ... //  2.      . // ... (    ) ... //  3.       . //  -,   ,        . var trigger = new CloudQueueWorkDetectedTriggerEvent("MyStorageAccount", "InputQueue"); //       . var interRoleEvent = new InterRoleCommunicationEvent(CloudEnvironment.CurrentRoleInstanceId, trigger); //             . interRoleCommunicator.Publish(interRoleEvent); } } 

, , , . , Windows Azure.

निष्कर्ष

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

समाधान आर्किटेक्ट्स को निम्नलिखित पर विचार करना चाहिए:

• क्यू-आधारित मैसेजिंग आर्किटेक्चर बनाते समय, आपको क्लाउड और हाइब्रिड समाधानों में परतों और सेवाओं के बीच अतुल्यकालिक और स्केलेबल मैसेजिंग के लिए विंडोज एज़्योर कतार संग्रहण सेवा का उपयोग करना चाहिए ।
• हम अनुशंसा करते हैं कि आप एक खंडित मैसेजिंग आर्किटेक्चर का उपयोग करें जो प्रति सेकंड 500 से अधिक लेनदेन का समर्थन कर सकता है ।
• Windows Azure ; .
• , .
• .
• वास्तविक समय अधिसूचना के लिए तैयार करने के लिए एकीकरण बस का उपयोग करने से पहले , आपको लाभों और लागतों का मूल्यांकन करने की आवश्यकता है।

डेवलपर्स को निम्नलिखित पर विचार करना चाहिए:

• मैसेजिंग सॉल्यूशन को डिजाइन करने के लिए बैच प्रोसेसिंग की आवश्यकता होती है जब विंडोज एज़्योर क्वीन्स से डेटा को स्टोर करने और पुनः प्राप्त करने के लिए प्रक्रियाएँ लिखनी होती हैं ।
• एक प्रभावी कतार श्रवण सेवा को लागू करने के लिए एक तंत्र के निर्माण की आवश्यकता होती है जो कतारों से वस्तुओं को हटाने के लिए एक एकल धागे के साथ खाली कतारों का सर्वेक्षण करता है ।
• यदि वर्कर लंबे समय तक खाली रहते हैं तो वर्कर रोल इंस्टेंस की संख्या को कम करने के लिए डायनामिक स्केलिंग का उपयोग करें ।
• , .
• , , .
• Windows Azure , .
• Windows Azure , .
• .NET Framework 4, TPL, PLINQ «», , .