क्लस्टर में अभिनेताओं के बीच अक्का और राज्य

Question

मैं अपने बीसी थीसिस प्रोजेक्ट पर काम कर रहा हूं जो स्कैला और अक्का में लिखा गया एक Minecraft सर्वर होना चाहिए। सर्वर को क्लाउड में या क्लस्टर पर आसानी से तैनाती योग्य होना चाहिए (सुनिश्चित नहीं है कि मैं उचित शब्दावली का उपयोग करता हूं ... इसे एकाधिक नोड्स पर चलाना चाहिए)। हालांकि, मैं अक्का में नौसिखिया हूं और मैं सोच रहा हूं कि ऐसी चीज को कैसे कार्यान्वित किया जाए। जिस समस्या को मैं अभी समझने की कोशिश कर रहा हूं, यह है कि विभिन्न नोड्स पर कलाकारों के बीच राज्य कैसे साझा करें। मेरा पहला विचार एक ऊंट अभिनेता होना था जो Minecraft क्लाइंट से टीसीपी स्ट्रीम पढ़ेगा और फिर इसे बैलेंसर लोड करने के लिए भेज देगा जो अनुरोध को संसाधित करने वाले नोड का चयन करेगा और फिर टीसीपी के माध्यम से क्लाइंट को कुछ प्रतिक्रिया भेजेंगे। आइए कहें कि मेरे पास एक प्रमाणीकरण सेवा लागू करने वाला अभिनेता है जो जांचता है कि उपयोगकर्ता द्वारा प्रदान किए गए प्रमाण-पत्र मान्य हैं या नहीं। प्रत्येक नोड में ऐसे अभिनेता (या शायद उनमें से अधिक) होंगे और सभी कलाकारों के पास हर समय उपयोगकर्ताओं के समान डेटाबेस (या राज्य) होना चाहिए। मेरा सवाल है, इस राज्य को रखने के लिए सबसे अच्छा तरीका क्या है? मैं कुछ समाधान मैं के बारे में सोच सकता है के साथ आया है, लेकिन मैं तो कृपया दोष का कहना है इस तरह कुछ नहीं किया है:

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

समाधान # 2: हर बार एक निश्चित अभिनेता से अनुरोध होगा कि यह राज्य बदल जाएगा, अभिनेता अनुरोध संसाधित करने के बाद, उसी प्रकार के अन्य सभी कलाकारों के परिवर्तन के बारे में जानकारी प्रसारित करेगा, जो बदलेगा मूल अभिनेता द्वारा भेजी गई जानकारी के अनुसार उनका राज्य। यह बहुत अक्षम और बदसूरत लगता है।

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

तो आपके पास यह है। केवल समाधान जो मुझे वास्तव में पसंद है वह पहला है, लेकिन जैसा कि मैंने कहा, यह शायद समस्याओं के केवल सीमित सीमित सबसेट में काम करता है (जब राज्य को रेडिस संरचनाओं में विभाजित किया जा सकता है)। अधिक अनुभवी गुरुओं से कोई प्रतिक्रिया बहुत सराहना की जाएगी। सादर, टॉमस हरमन

Answer 1

समाधान # 1 संभवतः धीमी गति से हो सकता है। साथ ही, यह एक बाधा और असफलता का एक बिंदु है (जिसका मतलब है कि डेटाबेस विफल होने पर एप्लिकेशन काम करना बंद कर देता है)। समाधान # 3 में समान समस्याएं हैं।

समाधान # 2 की तुलना में यह लगता है कम तुच्छ है। सबसे पहले, यह विफलता का एक बिंदु है। दूसरा, पढ़ने या लिखने के लिए कोई परमाणु या अन्य आदेश गारंटी (जैसे नियमितता) नहीं है, जब तक कि आप total order broadcast (जो नियमित प्रसारण से अधिक महंगा है) करते हैं। वास्तव में, अधिकांश वितरित रजिस्टर एल्गोरिदम ब्रॉडकास्ट अंडर-द-हूड करेंगे, इसलिए, अक्षम होने पर, यह आवश्यक हो सकता है।

आप क्या वर्णन किया है से, आप अपने वितरित रजिस्टर के लिए atomicity की जरूरत है। परमाणुता से मेरा क्या मतलब है? परमाणुता का अर्थ है कि समवर्ती पढ़ने और लिखने के अनुक्रम में कोई भी पढ़ना या लिखना प्रतीत होता है जैसे यह समय में एक बिंदु में होता है। अनौपचारिक रूप से, में # 2 समाधान एक भी अभिनेता के लिए एक रजिस्टर पकड़े साथ, यह गारंटी देता है कि अगर 2 बाद राईट W1 और फिर डब्ल्यू 2 रजिस्टर करने के लिए होते हैं (2 प्रसारण अर्थ), तो कोई अन्य अभिनेता रजिस्टर से मूल्यों को पढ़ने जाएगा उन्हें पहले W1 से अलग क्रम में पढ़ें और फिर W2 (यह वास्तव में उससे अधिक शामिल है)। यदि आप बाद के प्रसारणों के कुछ उदाहरणों के माध्यम से जाते हैं जहां संदेश समय पर विभिन्न बिंदुओं पर गंतव्य तक पहुंचते हैं, तो आप देखेंगे कि ऐसी ऑर्डरिंग संपत्ति की गारंटी नहीं है।

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

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

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