2011-11-13 10 views
59

मैं अक्का ढांचे में नया हूं और मैं नेटी + अक्का के शीर्ष पर एक HTTP सर्वर एप्लिकेशन बना रहा हूं।अक्का - एक अभिनेता के कितने उदाहरण आपको बनाना चाहिए?

मेरा विचार अब तक प्रत्येक प्रकार के अनुरोध के लिए एक अभिनेता बनाना है। जैसे मेरे पास एक पोस्ट/मेरे संसाधन के लिए एक अभिनेता होगा और एक अन्य अभिनेता के लिए एक जीईटी/मेरे संसाधन के लिए होगा।

जहां मैं उलझन में हूं, मुझे अभिनेता निर्माण के बारे में कैसे जाना चाहिए? मैं चाहिए:

  1. हर अनुरोध के लिए एक नए अभिनेता बनाना होगा (यह द्वारा मैं हर अनुरोध के लिए मतलब मैं उपयुक्त अभिनेता की एक TypedActor.newInstance() करना चाहिए)? एक नया अभिनेता बनाने के लिए कितना महंगा है?

  2. सर्वर पर प्रत्येक अभिनेता का एक उदाहरण बनाएं और प्रत्येक अनुरोध के लिए उस अभिनेता उदाहरण का उपयोग करें? मैंने पढ़ा है कि एक अभिनेता एक समय में केवल एक संदेश संसाधित कर सकता है, तो क्या यह बोतल की गर्दन नहीं हो सकता है?

  3. कुछ और करो?

किसी भी प्रतिक्रिया के लिए धन्यवाद।

उत्तर

30

ठीक है, आप उत्परिवर्तनीय स्थिति के प्रत्येक उदाहरण के लिए एक अभिनेता बनाते हैं जिसे आप प्रबंधित करना चाहते हैं।

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

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

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

8
  1. यह काफी उचित विकल्प है, लेकिन क्या यह उपयुक्त है आपके अनुरोध हैंडलिंग के विनिर्देशों पर निर्भर करता है।

  2. हां, ज़ाहिर है कि यह हो सकता है।

  3. कई मामलों के लिए सबसे अच्छा काम यह होगा कि सिर्फ एक अभिनेता प्रत्येक अनुरोध (या शायद एक अभिनेता प्रति अनुरोध के लिए) का जवाब दे, लेकिन यह अभिनेता केवल एक अन्य अभिनेता को कार्य को आगे बढ़ाने के लिए है (या Future स्पॉन करें) जो वास्तव में नौकरी करेगा।

+0

3), इसका मतलब यह नहीं होगा कि अगर अभिनेता को निष्पादित करने वाली मशीन में एक से अधिक कोर हैं, तो इसका उपयोग ठीक से नहीं किया जाएगा? – Diego

+1

@ डिएगो नहीं, क्योंकि अभिनेताओं/वायदा आगे बढ़ने के लिए उन कोरों पर काम कर सकते हैं। –

3

धारावाहिक अनुरोध हैंडलिंग स्केलिंग के लिए, एक मास्टर अभिनेता (Supervisor) जो बदले में कार्यकर्ता अभिनेताओं (Children) (round-robin fashion) को सौंप देंगे।

20

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

एक साल पहले मैंने थ्रेड-आधारित और घटना-आधारित मानक अभिनेताओं की संसाधन खपत के बीच comparison बनाया था। और अक्का घटना-आधार से भी बेहतर है।

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

मैं सुझाव है कि आप विकल्प 1.

20

विकल्प 1) या 2) है दोनों अपने खामियों के लिए जाना। तो फिर, के विकल्पों 3) Routing (अक्का 2.0+)

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

अक्का प्रदाता संदेश को रूट करने के लिए विभिन्न तर्कों के साथ विभिन्न राउटर कार्यान्वयन (उदाहरण के लिए सबसे छोटामेलबॉक्सपूल या RoundRobinPool)।

प्रत्येक राउटर में कई बच्चे हो सकते हैं और इसका कार्य उनके मेलबॉक्स की निगरानी करना है ताकि यह सुनिश्चित किया जा सके कि प्राप्त संदेश को कहां रूट किया जाए।

//This will create 5 instances of the actor ExampleActor 
//managed and supervised by a RoundRobinRouter 
ActorRef roundRobinRouter = getContext().actorOf(
Props.create(ExampleActor.class).withRouter(new RoundRobinRouter(5)),"router"); 

यह प्रक्रिया अच्छी तरह से this blog में समझाया गया है।

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