🛳️ ㊙️ 🧒🏼 कुशल क्लाउड कतार प्रबंधन (नीला कतार) 💈 🤙 💃🏻

"AtContent.com सेवा की आंतरिक संरचना और वास्तुकला" श्रृंखला के इस चौथे लेख में, मैं Azure सेवा (वर्कर रोल) के उदाहरणों का उपयोग करके नौकरियों की पृष्ठभूमि प्रसंस्करण से परिचित होने का प्रस्ताव करता हूं।

हम अनुशंसा करते हैं कि आप उदाहरणों के बीच प्राथमिक संचार चैनल के रूप में Azure Queues का उपयोग करें। लेकिन केवल इस चैनल का उपयोग सेवा उदाहरणों के सबसे कुशल उपयोग की अनुमति नहीं देता है। तो इस लेख में आप जानेंगे कि कैसे

एक उदाहरण के लिए एक नौकरी भेजने और इसके प्रसंस्करण की शुरुआत के बीच देरी को कम करें
Azure Queue को लेन-देन की संख्या कम करें
नौकरी प्रसंस्करण की दक्षता में वृद्धि

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

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

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

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

आप इंस्टेंस और भूमिकाओं के बीच मैसेजिंग तंत्र का उपयोग करके इन समस्याओं को हल कर सकते हैं। श्रृंखला के पिछले लेख ( http://habrahabr.ru/post/140461/ ) में इसका वर्णन किया गया था। इस तंत्र के बारे में कुछ शब्द। यह आपको संदेश को एक उदाहरण से दूसरे में या भूमिका के सभी उदाहरणों में स्थानांतरित करने की अनुमति देता है। इसका उपयोग करते हुए, आप उदाहरणों पर विभिन्न हैंडलर चला सकते हैं, जो उदाहरण के लिए, उदाहरणों की स्थिति को सिंक्रनाइज़ करने की अनुमति देता है। जैसा कि कार्य पर लागू होता है, यह आपको कार्य को कतार में जोड़ने के तुरंत बाद कतार को संसाधित करने की अनुमति देता है। इसी समय, कतार में नौकरियों की उपलब्धता की लगातार जांच करना आवश्यक नहीं है, जो "निष्क्रिय" लेनदेन को समाप्त करता है।

यदि हम इस तंत्र पर अधिक विस्तार से विचार करते हैं, तो हम निम्नलिखित देखेंगे:

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

हैंडलर सेटिंग्स को विभिन्न तरीकों से संग्रहीत किया जा सकता है। उदाहरण के लिए, उदाहरण के मेमोरी में (जो सबसे विश्वसनीय तरीका नहीं है), उदाहरण के भंडारण में या ब्लॉब्स (एज़्योर ब्लॉब स्टोरेज) के भंडारण में।

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

public interface IWorkerQueueHandler { bool HandleQueue(string Message); } public static class WorkerQueueHandlerExtensions { private static string CleanUpQueueName(string DirtyQueueName) { return DirtyQueueName.Substring(0, DirtyQueueName.IndexOf(",")).ToLowerInvariant().Replace(".", "-"); } public static string GetQueueName(this IWorkerQueueHandler Handler) { return CleanUpQueueName(Handler.GetType().AssemblyQualifiedName); } public static string GetQueueName(Type HandlerType) { return CleanUpQueueName(HandlerType.AssemblyQualifiedName); } }

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

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

 public static CloudQueue GetQueue(string QueueName) { CreateOnceQueue(QueueName); return queueStorage.GetQueueReference(QueueName); } public static bool AddToQueue<QueueHandlerType>(string Task) where QueueHandlerType : IWorkerQueueHandler { var Queue = GetQueue(WorkerQueueHandlerExtensions.GetQueueName(typeof(QueueHandlerType))); return AddToQueue<QueueHandlerType>(Queue, Task); } public static bool AddToQueue<QueueHandlerType>(CloudQueue Queue, string Task) { try { var Message = new CloudQueueMessage(Task); Queue.AddMessage(Message); Internal.RoleCommunicatior.WorkerRoleCommand(typeof(QueueHandlerType)); return true; } catch { return false; } }

इस तरह के समाधान के लाभों की गणना करना आसान है यदि आप कतार में आने वाले कार्यों की लगभग मात्रा और धारा की अनुमानित संरचना को जानते हैं। इसलिए, उदाहरण के लिए, यदि आपके कार्य मुख्य रूप से शाम को 20 से 23 घंटे तक आते हैं, तो दिन में अधिकांश अंतराल के साथ कार्यों की जाँच करना "बेकार" होगा। और यह गणना करना आसान है कि 21 घंटों के लिए वह बिना परिणाम के कतार से कार्यों का चयन करेगी। इसके अलावा, अगर इस तरह के चेक को एक बार एक सेकंड में किया जाता है, तो यह प्रति दिन लगभग 75,000 "निष्क्रिय" लेनदेन करेगा। $ 0.01 प्रति 10,000 के लेनदेन मूल्य के साथ, यह राशि $ 0.075 प्रति दिन या $ 2.25 प्रति माह होगी। लेकिन अगर आपके पास 100 अलग-अलग कतारें हैं, तो प्रति माह अतिरिक्त लागत $ 225 होगी।

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

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

मैं यह भी ध्यान देता हूं कि कतारों के साथ काम करने का तंत्र CPase ओपन सोर्स लाइब्रेरी का हिस्सा है, जो जल्द ही प्रकाशित और सभी के लिए उपलब्ध होगा।

श्रृंखला में पढ़ें:

कुशल क्लाउड कतार प्रबंधन (नीला कतार)

More articles: