उपभोक्ता / निर्माता और पर्यवेक्षक / अवलोकन के बीच अंतर

Question

मैं एक एप्लीकेशन के डिज़ाइन पर काम कर रहा हूँ जिसमें तीन भाग हैं:

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

हालांकि यह बहुत बुनियादी है और इसे लागू करना मुश्किल नहीं है, मैं सोच रहा हूं कि ऐसा करने का "सही" तरीका क्या होगा (जावा में इस ठोस मामले में, लेकिन उच्च अमूर्त उत्तर भी सराहना की जाती हैं)। दो रणनीतियां दिमाग में आती हैं:

• ऑब्जर्वर / ऑब्जर्वेबल: कंट्रोलर द्वारा देखे जाने वाले धागे को देखा जाता है। किसी घटना के घटित होने की स्थिति में, नियंत्रक को सूचित किया जाता है और नए कार्य को पुन: प्रयोज्य कैश्ड थ्रेड पूल से मुक्त थ्रेड को निर्दिष्ट कर सकता है (या यदि सभी थ्रेड वर्तमान में व्यस्त हैं तो FIFO कतार में कार्यों को प्रतीक्षा करें और कैश करें)। कार्यकर्ता सूत्र कॉलेबल को लागू करते हैं और या तो परिणाम (या बूलियन मान) के साथ सफल हो जाते हैं, या एक त्रुटि के साथ लौटते हैं, जिस स्थिति में नियंत्रक तय कर सकता है कि क्या (त्रुटि की प्रकृति के आधार पर खुशी हुई है)।

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

दोनों दृष्टिकोणों के अंतिम परिणाम समान हैं, लेकिन उनमें से प्रत्येक में मामूली अंतर हैं:

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

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

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

Answer 1

आप अपने स्वयं के प्रश्न का उत्तर देने के लिए काफी करीब हैं। :)

ऑब्जर्वेबल / ऑब्जर्वर पैटर्न (फ्लिप पर ध्यान दें) में, ध्यान रखने योग्य तीन बातें हैं:

1. आम तौर पर, परिवर्तन की सूचना, यानी 'पेलोड', अवलोकन योग्य होती है।
2. अवलोकनीय है ।
3. पर्यवेक्षकों को मौजूदा अवलोकन के बारे में पता होना चाहिए (या फिर उनके पास देखने के लिए कुछ भी नहीं है)।

इन बिंदुओं को मिलाकर, जो निहित है, वह यह है कि अवलोकन करने वाला जानता है कि इसके बहाव के घटक, यानी पर्यवेक्षक क्या हैं। डेटा प्रवाह स्वाभाविक रूप से अवलोकनीय है - पर्यवेक्षक केवल 'जीवित और मर' से संचालित होते हैं जो वे देख रहे हैं।

निर्माता / उपभोक्ता पैटर्न में, आपको एक बहुत भिन्न सहभागिता मिलती है:

1. आम तौर पर, पेलोड निर्माता के स्वतंत्र रूप से उत्पादन के लिए जिम्मेदार होता है।
2. निर्माता यह नहीं जानते कि उपभोक्ता कब या कैसे सक्रिय होते हैं।
3. उपभोक्ताओं को पेलोड के निर्माता को जानने की आवश्यकता नहीं है।

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

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

उन्हें अपने आवेदन में फिट करने के लिए:

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

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

Comments

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

— उपयोगकर्ता 183536

@ user183536 कोई समस्या नहीं, मदद करने के लिए खुश! :)

— hjk