स्थानीय बनाम रिमोट अभिनेताओं का उपयोग कब करें?

Question

मुझे अकका में अभिनेता बनाम रिमोट एक्टर्स का उपयोग कब करना चाहिए?

मैं समझता हूं कि दोनों मशीन को स्केल कर सकते हैं, लेकिन केवल रिमोट एक्टर्स स्केल कर सकते हैं, तो क्या सामान्य अभिनेता का कोई व्यावहारिक उत्पादन उपयोग है?

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

अभिनेता बनाम रिमोट एक्टर का उपयोग करने के बारे में कोई अंतर्दृष्टि बहुत सराहना की जाएगी।

Answer 1

रिमोट एक्टर्स स्केल नहीं कर सकते हैं, वे किसी अन्य मशीन पर स्थानीय अभिनेता के लिए केवल दूरस्थ संदर्भ हैं।

अक्का 2.0 के लिए हम क्लस्टर अभिनेताओं को पेश करेंगे, जो आपको एक अक्का एप्लिकेशन लिखने और इसे केवल कॉन्फ़िगरेशन का उपयोग करने के लिए स्केल करने की अनुमति देगा।

Answer 2

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

रिमोट अक्का अभिनेता

http://doc.akka.io/docs/akka/snapshot/scala/remoting.html

Answer 3

सवाल पूछते हैं, "एक दूरस्थ अभिनेता ही एक छोटी सी प्रारंभिक सेटअप भूमि के ऊपर है और किसी भी अन्य बड़े भूमि के ऊपर नहीं है, तो फिर मैं सोच सकता है कि प्रयोग करने के लिए यहां देखें एक रिमोट अभिनेता मानक होगा "। फिर भी Fallacies of distributed computing इस बात को इंगित करता है कि यह एक डिजाइन त्रुटि है कि किसी भी तकनीक के साथ रिमोटिंग कोई ओवरहेड नहीं है। आपके पास संदेशों को बाइट्स पर कॉपी करने और नेटवर्क इंटरफ़ेस में ट्रांसमिट करने का ओवरहेड है। आपके पास अलग-अलग प्रक्रियाओं की सभी जटिलताएं भी ऊपर, नीचे, रुक गई या पहुंच योग्य नहीं हैं और नेटवर्क में खोए गए, डुप्लीकेट या रीडर्ड किए गए संदेश होने वाले हिचकी हैं।

This great article में अजीब नेटवर्क त्रुटियों के असली विश्व उदाहरण हैं जो बुलेट प्रूफ बनाने के लिए कड़ी मेहनत कर रहे हैं। अक्का परियोजना के नेतृत्व में रोलैंड कुलन ने अपने free video course about akka में कहा है कि नेटवर्क संदेशों के प्रत्येक 1T के लिए उनके अनुभव में उन्हें भ्रष्टाचार दिखाई देता है। Notes on Distributed Systems for Young Bloods का कहना है कि "वितरित सिस्टमों को वास्तविक, अनुकरण नहीं किया जाता है, उनकी बगों को दूर करने के लिए वितरण की आवश्यकता होती है" ताकि अच्छे यूनिट परीक्षण भी एक परिपूर्ण प्रणाली के लिए न हों। बहुत सारी सलाह है कि रिमोटिंग "मुक्त" नहीं है बल्कि सही होने के लिए कड़ी मेहनत है।

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

जिस क्षण आप रीमोटिंग का उपयोग करना शुरू करते हैं, उसके पास एक वितरित प्रणाली होती है जो Distributed systems for fun and profit में चर्चा की गई चुनौतियों का निर्माण करती है। जब तक आप बहुत ही सरल चीजें नहीं कर रहे हैं जैसे स्टेटलेस कैलकुलेटर जो डुप्लीकेट संदेशों के लिए बेवकूफ हैं, चीजें मुश्किल हो जाती हैं। उपरोक्त लिंक पर उस अक्का वीडियो पाठ्यक्रम पर असाइनमेंट में से एक एक प्रतिलिपि बनाई गई कुंजी-मूल्य स्टोर बनाना है जो तर्क लिखकर खोए गए संदेशों से निपट सकता है। यह एक आसान असाइनमेंट होने से बहुत दूर है। विभिन्न प्रक्रियाओं में वितरित राज्य बहुत कठिन हो जाता है, कलाकार राज्य को समाहित करते हैं, इसलिए आपके द्वारा बनाई जा रही प्रणाली की स्थिरता और उपलब्धता आवश्यकताओं के आधार पर कलाकारों को वितरित करना बहुत कठिन हो सकता है।

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