2009-12-01 11 views
6

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

मेरे पास दो डिज़ाइन हैं और सलाह मांगना चाहते हैं कि कौन सा बेहतर है।

  1. पुश मॉडल: अलग-अलग श्रमिकों को कार्य इकाइयों को असाइन करने के लिए केंद्रीय नौकरी शेड्यूलर का उपयोग करके, यह सुनिश्चित करने के लिए कि विभिन्न कर्मचारी एक ही कार्य इकाई पर काम नहीं कर रहे हैं;
  2. मॉडल खींचें: प्रत्येक कार्यकर्ता कार्य इकाइयों के लिए केंद्रीय नौकरी शेड्यूलर से प्रक्रिया करने के लिए कहेंगे, और नौकरी शेड्यूलर एक उपयुक्त कार्य इकाई का चयन करेगा जिसे अन्य कार्यकर्ता द्वारा पूछताछ कार्यकर्ता के लिए संसाधित नहीं किया जा रहा है।

मैं प्रत्येक डिज़ाइन के पेशेवरों और विपक्ष को जानना चाहता हूं। और मेरी प्रमुख चिंताओं में से एक है - एक कमजोर युग्मित डिजाइन ढूंढना (यह मेरा मुख्य लक्ष्य है, लेकिन एकमात्र लक्ष्य नहीं है)। मुझे यकीन नहीं है कि पुश मॉडल या पोल मॉडल में बेहतर विस्तारशीलता है (विकल्प 1 अधिक कमजोर युग्मित है)? पहले से

धन्यवाद, जॉर्ज

+1

पूल इस मामले में मतदान से अधिक उपयुक्त नहीं है? –

+2

मैं जिस शब्द को आप ढूंढ रहे हैं उसे विश्वास करें "खींचें" है। – jldupont

+0

पुल भी एक अच्छा नाम है। –

उत्तर

3

"पुल" मॉडल का लाभ है कि प्रत्येक कार्यकर्ता स्थानीय स्तर पर यह कितना भरी हुई है जानता है और इस तरह अपनी लोड का प्रबंधन कर सकते हैं।

इसके अलावा, "खींचें" मॉडल अधिक "decoupled" हो सकता है क्योंकि "लोड" के चर को कार्यकर्ता को स्थानीय रखा जाता है जबकि "पुश" मॉडल में किसी को संचार संचार प्रोटोकॉल (और ओवरहेड) की आवश्यकता होती है ताकि इसे संवाद किया जा सके। राज्य। ऑटो उद्योग में मॉडल "पुल" की सफलता का


सोचें: यह ट्रैक करने के लिए पारंपरिक "धक्का" मॉडल जहां माल मुश्किल होगा से चला गया और अब सफल और सर्वव्यापी करने के लिए प्रतिक्रिया की बहुत सारी की आवश्यकता " खींचो "मॉडल।


यह स्केलिंग की बात आती है, तो आप के ऊपर परत से नौकरियों के लिए "शेड्यूलर" है कि "चुनाव" के एक मध्यवर्ती परत हो सकता है। आधार श्रमिक अब विभाजित तरीके से मध्यवर्ती परत के साथ बातचीत कर सकते हैं।


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

+1

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

+1

इसे सामान्य तरीके से हल किया जा सकता है: किसी असाइन किए गए नौकरी की स्थिति को किसी प्रकार की "नियंत्रण इकाई" को सूचित किया जाना चाहिए। – jldupont

+1

यदि "टाइम एक्स" में कोई "नौकरी" रिपोर्ट होने में विफल रहता है, तो विफलता पुनर्प्राप्ति को ट्रिगर किया जा सकता है। – jldupont

2

मैं निश्चित रूप से पुल मॉडल का उपयोग करता हूं क्योंकि इसे कार्यान्वित करना आसान है।

मैं केवल 2 कार्यान्वयन कल्पना कर सकते हैं: कार्य संग्रह के साथ साथ कई कार्यकर्ता ग्राहकों के साथ

  1. पुल मॉडल = 1 सेवा।

  2. कार्य संग्रह के साथ पुश मॉडल = 1 सेवा और सक्रिय ग्राहकों की एक सूची और कई सक्रिय ग्राहकों (श्रमिकों) की सूची।

चूंकि पुल मॉडल को पूर्ण डुप्लेक्स सेवा कॉल लागू करने की आवश्यकता नहीं है, न तो ग्राहक सूची, यह आसान है।

+1

क्यों आसान है? क्या आप अधिक जानकारी प्रदान कर सकते हैं? – George2

+1

हालांकि मैं "पुल" मॉडल का समर्थक हूं, बिना किसी सहायक तथ्यों के आपके "उत्तर" या अन्यथा "वाष्प" सर्वोत्तम रूप से प्रतीत होता है। – jldupont

+1

सामग्री –

संबंधित मुद्दे