क्लस्टर में अक्का अभिनेताओं की खोज

Question

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

मैं WebSocket chat example that comes with Play Framework 2.0 का उपयोग करके इस मुद्दे को चित्रित करने का प्रयास करूंगा: एक ऐसा अभिनेता है जो वेबसाकेट रखता है और जो वर्तमान में जुड़े उपयोगकर्ताओं की एक सूची रखता है। कलाकार मूल रूप से चैट रूम को तकनीकी रूप से और तर्कसंगत दोनों का प्रतिनिधित्व करते हैं। जब तक एक सर्वर पर एक सिंगल चैट रूम चल रहा है, यह पूरी तरह से ठीक काम करता है।

अब मैं यह समझने की कोशिश कर रहा हूं कि जब हम कई गतिशील चैट रूम (नए कमरे किसी भी समय खोले/बंद हो सकते हैं) सर्वर के समूह पर चल रहे हैं (एकल नोड्स के साथ) इस उदाहरण को कैसे बढ़ाया जाना चाहिए वर्तमान मांग के अनुसार जोड़ा या हटाया जा रहा है)। ऐसे मामले में उपयोगकर्ता ए सर्वर 1 से कनेक्ट हो सकता है जबकि उपयोगकर्ता बी सर्वर से कनेक्ट होता है 2. दोनों एक ही चैट रूम पर बात कर रहे हैं। प्रत्येक सर्वर पर अभी भी एक अभिनेता (प्रत्येक चैट रूम के लिए?) होगा जो वेबसॉकेट उदाहरणों को सही उपयोगकर्ताओं को ईवेंट (संदेश) प्राप्त करने और प्रकाशित करने के लिए रखता है। लेकिन तार्किक रूप से केवल सर्वर 1 या सर्वर 2 पर एक चैट रूम अभिनेता होना चाहिए जिसमें वर्तमान में जुड़े हुए उपयोगकर्ताओं (या समान कार्य) की सूची है।

आप इसे "शुद्ध अक्का" में और ज़ीरोएमक्यू या खरगोशएमक्यू जैसी अतिरिक्त संदेश प्रणाली को जोड़ने के बिना कैसे प्राप्त करेंगे?

यह वही है मैं अब तक के साथ आ गया है, मुझे पता है यह किसी भी समझ में आता है कि क्या बताएं:

1. उपयोगकर्ता एक सर्वर 1 को जोड़ता है और एक अभिनेता आवंटित किया जाता है कि उसकी WebSocket रखती है।
2. अभिनेता चेक करता है (राउटर का उपयोग कर? इवेंटबस? कुछ और?) चाहे सक्रिय चैट रूम के लिए "चैट रूम एक्टर" किसी भी कनेक्टेड क्लस्टर नोड्स पर मौजूद है। चूंकि यह किसी नए चैट रूम अभिनेता के निर्माण का अनुरोध नहीं करेगा और इस अभिनेता से भविष्य में चैट संदेश भेजेगा और प्राप्त करेगा।
3. उपयोगकर्ता बी सर्वर 2 पर कनेक्ट होता है और एक अभिनेता को भी अपनी वेबसाकेट के लिए आवंटित किया जाता है।
4. यह भी जांचता है कि अनुरोधित चैट रूम के लिए कोई अभिनेता कहीं मौजूद है और इसे सर्वर पर पाता है।
5. सर्वर 1 पर चैट रूम अभिनेता अब दिए गए चैट रूम के लिए केंद्र के रूप में कार्य करता है, सभी को "संदेश भेजता है "चैट सदस्य अभिनेता चैट करें और आने वाले लोगों को वितरित करें।

यदि सर्वर 2 नीचे चला जाता है, तो चैट रूम अभिनेता को किसी भी तरह से सर्वर पर फिर से बनाया/स्थानांतरित करना होगा, हालांकि यह अभी मेरी प्राथमिक चिंता नहीं है। मैं इस बारे में सोच रहा हूं कि कैसे अभिनेताओं की गतिशील खोज विभिन्न, मूल रूप से स्वतंत्र मशीनों के बारे में फैली, अक्का के टूलसेट का उपयोग करके किया जा सकता है।

मैं अब कुछ समय से अक्का के दस्तावेज़ीकरण को देख रहा हूं, इसलिए शायद मैं यहां स्पष्ट रूप से याद कर रहा हूं। यदि हां, तो कृपया मुझे प्रबुद्ध करें :-)

Answer 1

मैं एक निजी परियोजना पर काम कर रहा हूं जो मूल रूप से चैटरूम उदाहरण का एक बहुत विस्तारित संस्करण है और मुझे अक्का और पूरी "विकेन्द्रीकृत" सोच के साथ स्टार्टअप समस्याएं भी थीं। तो मैं आपको बता सकता हूं कि मैंने अपने विस्तारित चैट रूम को "हल" कैसे किया:

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

• WebsocketSession: जो एक उपयोगकर्ता के लिए कनेक्शन रखता है और उपयोगकर्ता से अनुरोध हैंडल और सिस्टम से संदेशों को अग्रेषित करता

  सर्वर निम्नलिखित अभिनेताओं है।

• ChatroomManager: यह केंद्रीय प्रसारणकर्ता है, जो सर्वर के प्रत्येक उदाहरण पर तैनात है। यदि कोई उपयोगकर्ता चैट रूम में संदेश भेजना चाहता है, तो WebSocketSession-Actor सभी जानकारी ChatroomManager-Actor को भेजता है जो तब चैट रूम के सभी सदस्यों को संदेश प्रसारित करता है।
  1. उपयोगकर्ता एक सर्वर 1 जो एक नई WebsocketSession आवंटित को जोड़ता है:

तो यहाँ मेरी प्रक्रिया है। यह अभिनेता इस अभिनेता को रेडिस में पूर्ण पथ डालता है।

उपयोगकर्ता ए चैटरूम एक्स में शामिल हो जाता है जो रेडिस में प्रत्येक पूर्ण पथ (उपयोगकर्ता सत्र की अनन्य आईडी के रूप में इसका उपयोग करता है) को भी सम्मिलित करता है (प्रत्येक चैटरूम में "कनेक्शन" सेट होता है)

उपयोगकर्ता बी सर्वर से कनेक्ट होता है 2 - > redis

उपयोगकर्ता बी चैटरूम एक्स में शामिल हो जाता है -> redis

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

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

• उपयोगकर्ता A और उपयोगकर्ता बी सर्वर पर कर रहे हैं 1.
• चैट रूम X सर्वर 2.

उपयोगकर्ता एक से बात करना चाहता है पर है उपयोगकर्ता बी, दोनों को सर्वर पर चैट रूम-अभिनेता पर संवाद करना होगा।

इसके अलावा मैंने प्रत्येक प्रणाली पर ChatroomManager-अभिनेता के कई उदाहरण बनाने के लिए अक्का की कार्यक्षमताओं जैसे (राउंड-रॉबिन) -उटर का उपयोग किया कई अनुरोधों को संभाल लें।

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

इससे आपको थोड़ा और मदद मिल सकती है और मैं नए प्रश्नों के लिए खुला हूं (कृपया मेरे अंग्रेज़ी के बारे में नहीं;)।

Answer 2

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

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

आप क्लस्टरिंग पर चर्चा और अक्का में बाहर स्केलिंग निम्नलिखित ब्लॉग पोस्ट पर एक नज़र हो सकता है:

http://blog.softmemes.com/2012/06/16/clustered-akka-building-akka-2-2-today-part-1/

http://blog.softmemes.com/2012/06/16/clustered-akka-building-akka-2-2-today-part-2/

Answer 3

मैं का प्रयोग करेंगे Zookeeper + नॉर्बर्ट पता करने के लिए जो के बारे में होस्ट सेट जा रहे हैं और नीचे:

http://www.ibm.com/developerworks/library/j-zookeeper/

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

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

https://github.com/twitter/snowflake/blob/master/src/main/scala/com/twitter/service/snowflake/IdWorker.scala

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

अब तक इतना अच्छा है; अगर उसमें कोई नोड मर जाता है तो हम लचीला संदेश प्राप्त करेंगे, हम चैट रूम की एक जीवित प्रति को खो देंगे नहीं। संदेशों को स्वचालित रूप से दूसरे चैटरूम के माध्यम से निर्बाध प्रवाह होगा।

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

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

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

एक डिमोकिशनिंग चैटरूम प्रत्येक नोड से नॉरबर्ट क्लस्टर सदस्यता पावती संदेशों के लिए सुनेंगे। आखिरकार यह देखेंगे कि क्लस्टर के भीतर सभी नोड्स ने नई क्लस्टर सदस्यता को स्वीकार किया है। यह तब जानता है कि इसे आगे बढ़ाने के लिए कोई और संदेश नहीं मिलेगा। यह तब खुद को मार सकता है। Akka हॉटस्पैपिंग decommissioning व्यवहार को लागू करने के लिए एकदम सही है।

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

https://www.dropbox.com/s/iihpq9bjcfver07/VLDB-Paper.pdf