कतार आधारित सिस्टम

हाय, हब्रोज़ितेली!

हमने आगामी नवीनता "वितरित प्रणाली" से अध्याय "टास्क कतारों पर आधारित सिस्टम" के अनुवाद को साझा करने का निर्णय लिया। डिजाइन पैटर्न ”(पहले से ही प्रिंटिंग हाउस में)।


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

सामान्यीकृत कार्य कतार पर आधारित प्रणाली

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

अंजीर में दिखाए गए कार्य कतार का उपयोग करके इस कथन को स्पष्ट करें। 10.1। इसे फिर से देखने के बाद, यह निर्धारित करें कि कंटेनरों के साझा समूह द्वारा क्या कार्य प्रदान किए जा सकते हैं। यह स्पष्ट हो जाता है कि कंटेनरीकृत कार्य कतार के अधिकांश कार्यान्वयन का उपयोग उपयोगकर्ताओं की एक विस्तृत श्रृंखला द्वारा किया जा सकता है।


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

स्रोत कंटेनर इंटरफ़ेस

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


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

टास्क कतार एपीआई कार्य कतार और अनुप्रयोग-निर्भर कंटेनर के बीच बातचीत के तंत्र को देखते हुए, हमें दो कंटेनरों के बीच इंटरफ़ेस की एक औपचारिक परिभाषा तैयार करनी चाहिए। कई अलग-अलग प्रोटोकॉल हैं, लेकिन HTTP रेस्टफुल एपीआई को लागू करना आसान है और ऐसे इंटरफेस के लिए वास्तविक मानक हैं। कार्य कतार निम्नलिखित URL को कंटेनर में लागू होने की उम्मीद करती है:

• लोकलहोस्ट / एपीआई / v1 / आइटम प्राप्त करें;
• लोकलहोस्ट / एपीआई / v1 / आइटम <आइटम-नाम> प्राप्त करें।

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

URL / आइटम / सभी कार्यों की सूची लौटाता है:

{ kind: ItemList, apiVersion: v1, items: [ "item-1", "item-2", …. ] } 

URL / आइटम / <आइटम-नाम> एक विशिष्ट कार्य के बारे में विस्तृत जानकारी प्रदान करता है:

 { kind: Item, apiVersion: v1, data: { "some": "json", "object": "here", } } 

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

इस एपीआई से हमें एक विशिष्ट कार्य के बारे में जानकारी मिलती है, और फिर निष्पादक के कंटेनर इंटरफ़ेस के आइटम.डेटा फ़ील्ड का मान पास होता है।

कंटेनर इंटरफ़ेस निष्पादित करना

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

स्रोत कंटेनर में, हमने कार्य प्रबंधक को कार्य सूची भेजने के लिए एक सरल HTTP कॉल का उपयोग किया। यह इस धारणा पर किया गया था कि इस एपीआई कॉल को कई बार किए जाने की आवश्यकता थी, और सुरक्षा मुद्दों को ध्यान में नहीं रखा गया था, क्योंकि सब कुछ स्थानीयहोस्ट ढांचे के भीतर काम करता था। कंटेनर API को केवल एक बार कॉल किया जाना चाहिए और यह सुनिश्चित करना महत्वपूर्ण है कि सिस्टम के अन्य उपयोगकर्ता निष्पादनकर्ताओं को काम नहीं जोड़ सकते हैं, यहां तक ​​कि दुर्घटना या दुर्भावनापूर्ण इरादे से भी। इसलिए, निष्पादित कंटेनर के लिए, हम फ़ाइल एपीआई का उपयोग करेंगे। निर्माण के बाद, हम कंटेनर को WORK_ITEM_FILE नामक एक पर्यावरण चर पास करेंगे, जिसका मान कंटेनर के आंतरिक फ़ाइल सिस्टम में एक फ़ाइल को संदर्भित करता है। इस फ़ाइल में कार्य पूरा होने के बारे में डेटा है। इस तरह की एपीआई, जैसा कि नीचे दिखाया गया है, कॉन्फिगरेशन कुबेरनेट्स ऑब्जेक्ट द्वारा लागू किया जा सकता है। इसे कंटेनर के एक समूह में फ़ाइल (छवि 10.3) के रूप में रखा जा सकता है।


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

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

सामान्य कार्य कतार अवसंरचना

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

1. स्रोत कंटेनर से वर्तमान में उपलब्ध कार्यों को डाउनलोड करें।
2. कार्य कतार की स्थिति स्पष्ट करें कि कौन से कार्य पहले ही पूरे हो चुके हैं या अभी भी किए जा रहे हैं।
3. प्रत्येक अनसुलझे कार्यों के लिए, एक उपयुक्त इंटरफ़ेस के साथ कंटेनर कंटेनर बनाएं।
4. निष्पादित कंटेनर के सफल समापन पर, रिकॉर्ड करें कि कार्य पूरा हो गया है।

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

इस प्रकार, कार्य कतारबद्ध करना बहुत सरल है, क्योंकि ऑर्केस्ट्रा कार्यों के विश्वसनीय निष्पादन के लिए जिम्मेदारी लेता है।

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

इसका मतलब यह है कि हम अपने स्वयं के भंडार का उपयोग किए बिना कुबेरनेट्स ऑर्केस्ट्रेटर के शीर्ष पर कार्य कतार को लागू कर सकते हैं। यह सब कार्य कतार के बुनियादी ढांचे के निर्माण के कार्य को सरल करता है।

इसलिए, कंटेनर के संचालन के लिए एक विस्तृत एल्गोरिथ्म, कार्य कतार प्रबंधक, निम्नानुसार है।

बार-बार दोहराते हैं।

1. कंटेनर के इंटरफ़ेस के माध्यम से कार्यों की सूची प्राप्त करें - कार्यों का स्रोत।
2. इस कार्य कतार में कार्य करने वाले कार्यों की एक सूची प्राप्त करें।
3. इन सूचियों के आधार पर, अप्रमाणित कार्यों की एक सूची का चयन करें।
4. प्रत्येक असंसाधित कार्य के लिए, एक कार्य ऑब्जेक्ट बनाएं जो संबंधित निष्पादित कंटेनर को जन्म देता है।

यहाँ एक पायथन लिपि है जो इस कतार को लागू करती है:

 import requests import json from kubernetes import client, config import time namespace = "default" def make_container(item, obj): container = client.V1Container() container.image = "my/worker-image" container.name = "worker" return container def make_job(item): response = requests.get("http://localhost:8000/items/{}".format(item)) obj = json.loads(response.text) job = client.V1Job() job.metadata = client.V1ObjectMeta() job.metadata.name = item job.spec = client.V1JobSpec() job.spec.template = client.V1PodTemplate() job.spec.template.spec = client.V1PodTemplateSpec() job.spec.template.spec.restart_policy = "Never" job.spec.template.spec.containers = [ make_container(item, obj) ] return job def update_queue(batch): response = requests.get("http://localhost:8000/items") obj = json.loads(response.text) items = obj['items'] ret = batch.list_namespaced_job(namespace, watch=False) for item in items: found = False for i in ret.items: if i.metadata.name == item: found = True if not found: #    Job,  #   job = make_job(item) batch.create_namespaced_job(namespace, job) config.load_kube_config() batch = client.BatchV1Api() while True: update_queue(batch) time.sleep(10) 

कार्यशाला। वीडियो फ़ाइलों के लिए एक थंबनेल जनरेटर का कार्यान्वयन

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

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

मैं NodeJS पर एक सरल कार्यक्रम दूंगा:

 const http = require('http'); const fs = require('fs'); const port = 8080; const path = process.env.MEDIA_PATH; const requestHandler = (request, response) => { console.log(request.url); fs.readdir(path + '/*.mp4', (err, items) => { var msg = { 'kind': 'ItemList', 'apiVersion': 'v1', 'items': [] }; if (!items) { return msg; } for (var i = 0; i < items.length; i++) { msg.items.push(items[i]); } response.end(JSON.stringify(msg)); }); } const server = http.createServer(requestHandler); server.listen(port, (err) => { if (err) { return console.log('  ', err); } console.log(`    ${port}`) }); 

यह स्रोत संसाधित होने वाली फिल्मों की सूची को परिभाषित करता है। Ffmpeg उपयोगिता का उपयोग थंबनेल निकालने के लिए किया जाता है।

आप एक कंटेनर बना सकते हैं जो निम्न कमांड चलाता है:

 ffmpeg -i ${INPUT_FILE} -frames:v 100 thumb.png 

कमांड प्रत्येक 100 फ्रेम (-फ्रेम: वी 100 पैरामीटर) में से एक को निकालता है और इसे पीएनजी प्रारूप (उदाहरण के लिए, thumb1.png, thumb2.png, आदि) में बचाता है।

मौजूदा ffmpeg Docker इमेज के आधार पर इस तरह की प्रोसेसिंग को लागू किया जा सकता है। Jrottenberg / ffmpeg की छवि लोकप्रिय है।

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

कलाकारों की गतिशील स्केलिंग

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

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

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

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

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

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

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

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

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

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

मल्टी-वर्कर पैटर्न

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

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


कंटेनर निष्पादित करके कोड का पुन: उपयोग करके, वितरित बैच प्रसंस्करण प्रणालियों को डिजाइन करने वाले लोगों का श्रम कम हो जाता है।

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

हब्रोज़िटेलमी के लिए कूपन पर 20% की छूट - वितरित सिस्टम ।