🎒 🤘🏽 🙏🏿 क्लस्टर इंटरैक्शन का विकास। हमने ActiveMQ और हेज़ेलकास्ट को कैसे लागू किया 👩🏻‍🤝‍👨🏾 😹 👨‍🏫

पिछले 7 वर्षों में, अपनी टीम के साथ, मैं Miro उत्पाद (एक्स-रियलटाइम बोर्ड) के मूल का समर्थन और विकास कर रहा हूं: क्लाइंट-सर्वर और क्लस्टर इंटरैक्शन, डेटाबेस के साथ काम करना।

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

व्यावसायिक तर्क के संदर्भ में, आवेदन में शामिल हैं:

कस्टम बोर्डों और उनकी सामग्री के साथ काम करना;
बोर्ड के उपयोगकर्ता पंजीकरण, निर्माण और प्रबंधन के लिए कार्यक्षमता;
कस्टम संसाधन जनरेटर। उदाहरण के लिए, यह एप्लिकेशन पर अपलोड की गई बड़ी छवियों का अनुकूलन करता है ताकि वे हमारे ग्राहकों को धीमा न करें;
तृतीय-पक्ष सेवाओं के साथ कई एकीकरण।

2011 में, जब हम शुरू कर रहे थे, पूरा Miro एक ही सर्वर पर था। सब कुछ उस पर था: नग्नेक्स जिस पर एक साइट के लिए php, एक जावा एप्लिकेशन और डेटाबेस।

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

दुर्भाग्य से, कुछ समय बाद, समस्याएं फिर से पैदा हुईं, क्योंकि आवेदन पर भार बढ़ता रहा। तब हमने इस बारे में सोचा कि बुनियादी ढांचे को कैसे बढ़ाया जाए।

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

क्षैतिज आधारभूत संरचना

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

हम सिस्टम के इन हिस्सों को कैसे स्केल करना चाहते हैं, इसके बारे में सोचना शुरू किया और स्पष्ट समाधानों के लिए आए।

बोर्डों और सामग्री के साथ स्केल काम । उपयोगकर्ता इस तरह से बोर्ड खोलता है: उपयोगकर्ता क्लाइंट को खोलता है → इंगित करता है कि वह किस बोर्ड को खोलना चाहता है → सर्वर से कनेक्ट करता है → सर्वर पर एक स्ट्रीम बनाई जाती है → इस बोर्ड के सभी उपयोगकर्ता एक स्ट्रीम से कनेक्ट होते हैं → इस स्ट्रीम के भीतर विजेट का कोई भी परिवर्तन या निर्माण होता है। यह पता चला है कि बोर्ड के साथ सभी काम प्रवाह द्वारा सख्ती से सीमित हैं, जिसका अर्थ है कि हम सर्वर के बीच इन प्रवाह को वितरित कर सकते हैं।

स्केल उपयोगकर्ता संसाधन पीढ़ी । हम संसाधनों को अलग से उत्पन्न करने के लिए सर्वर को निकाल सकते हैं, और यह पीढ़ी के लिए संदेश प्राप्त करेगा, और फिर जवाब देंगे कि सब कुछ उत्पन्न होता है।

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

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

बॉक्स से बाहर पहला क्लस्टर

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

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

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

संदेश भेजने के लिए सर्वर स्वयं निर्धारित करता है।

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

समस्या यह है कि सर्वर नंबर 1 को यह नहीं पता है कि सर्वर नंबर 4 अभी उच्च लोड के अधीन है और इसका जवाब जल्दी से नहीं दे सकता है। परिणामस्वरूप, सर्वर # 1 अनुरोधों की तुलना में वे धीरे-धीरे संसाधित होते हैं।

सर्वर को पता नहीं है कि दूसरा सर्वर फ्रोजन है

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

इस मामले में, सर्वर # 1 को यह नहीं पता है कि समस्या क्या है, इसलिए यह उत्तर की प्रतीक्षा करना जारी रखता है। क्लस्टर में शेष सर्वर भी सर्वर नंबर 4 के साथ स्थिति के बारे में नहीं जानते हैं, इसलिए वे सर्वर नंबर 4 पर बहुत सारे संदेश भेजेंगे और प्रतिक्रिया की प्रतीक्षा करेंगे। इसलिए यह तब तक रहेगा जब तक सर्वर नंबर 4 की मृत्यु नहीं हो जाती।

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

संदेश दलाल। ActiveMQ

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

परिणामस्वरूप, हमने अपना पूरा क्लस्टर सिस्टम ActiveMQ में स्थानांतरित कर दिया। इसने क्या दिया:

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

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

जब सभी आवश्यक सर्वर झूठ बोल रहे हों तो क्या करें?

मान लें कि सर्वर # 3 एक कतार में संसाधन उत्पन्न करने के लिए एक संदेश भेजना चाहता है। वह उम्मीद करता है कि उसका संदेश संसाधित हो जाएगा। लेकिन वह नहीं जानता कि किसी कारण से संदेश का एक भी प्राप्तकर्ता नहीं है। उदाहरण के लिए, प्राप्तकर्ता एक त्रुटि के कारण दुर्घटनाग्रस्त हो गया।

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

नतीजतन, हम संसाधनों की पीढ़ी पर सर्वर क्षमता खर्च करते हैं, और किसी को भी परिणाम की आवश्यकता नहीं होती है।

मैं समस्या को कैसे हल कर सकता हूं? हम मॉनिटरिंग सेट कर सकते हैं, जो आपको सूचित कर रहा है कि क्या हो रहा है। लेकिन उस क्षण से जब निगरानी कुछ रिपोर्ट करती है, उस क्षण तक जब तक हम समझते हैं कि हमारे सर्वर खराब हैं, समय बीत जाएगा। यह हमें शोभा नहीं देता।

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

कुछ सेवाओं को क्षैतिज रूप से नहीं बढ़ाया जा सकता है

यह हमारे शुरुआती कोड की समस्या है, ActiveMQ की नहीं। मैं आपको एक उदाहरण दिखाता हूं:

Permission ownerPermission = service.getOwnerPermission(board); Permission permission = service.getPermission(board,user); ownerPermission.setRole(EDITOR); permission.setRole(OWNER);

हमारे पास बोर्ड पर उपयोगकर्ता अधिकारों के साथ काम करने के लिए एक सेवा है: उपयोगकर्ता बोर्ड या उसके संपादक का मालिक हो सकता है। बोर्ड में केवल एक ही मालिक हो सकता है। मान लीजिए हमारे पास एक परिदृश्य है जहां हम एक उपयोगकर्ता से दूसरे बोर्ड के स्वामित्व को स्थानांतरित करना चाहते हैं। पहली पंक्ति में हमें बोर्ड के वर्तमान मालिक मिलते हैं, दूसरे पर - हम उस उपयोगकर्ता को लेते हैं जो संपादक था, और अब मालिक बन गया। इसके अलावा, वर्तमान मालिक हमने EDITOR की भूमिका निभाई, और पूर्व संपादक - OWNER की भूमिका।

आइए देखें कि यह बहु-थ्रेडेड वातावरण में कैसे काम करेगा। जब पहला धागा EDITOR भूमिका स्थापित करता है, और दूसरा धागा वर्तमान OWNER लेने की कोशिश करता है, तो ऐसा हो सकता है कि OWNER मौजूद नहीं है, लेकिन दो EDITOR हैं।

कारण सिंक्रनाइज़ेशन की कमी है। हम बोर्ड पर एक सिंक्रनाइज़ ब्लॉक को जोड़कर समस्या को हल कर सकते हैं।

 synchronized (board) { Permission ownerPermission = service.getOwnerPermission(board); Permission permission = service.getPermission(board,user); ownerPermission.setRole(EDITOR); permission.setRole(OWNER); }

यह समाधान क्लस्टर में काम नहीं करेगा। SQL डेटाबेस लेनदेन की मदद से हमारी मदद कर सकता है। लेकिन हमारे पास रेडिस हैं।

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

बोर्ड में प्रवेश करते समय विफलता का एक बिंदु

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

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

मुख्य सर्वर जवाब देता है कि आपको सर्वर नंबर 1 से कनेक्ट करने की आवश्यकता है → उपयोगकर्ता कनेक्ट हो रहा है। जाहिर है, यदि मुख्य सर्वर की मृत्यु हो जाती है, तो उपयोगकर्ता अब नए बोर्डों तक नहीं पहुंच पाएगा।

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

हेज़लकास्ट पर स्विच करें

एक तरह से या किसी अन्य, हम उन समस्याओं के साथ सामना करते हैं जो उत्पन्न हुई थीं, लेकिन यह सबसे सुंदर तरीका नहीं हो सकता है। अब हमें यह समझने की आवश्यकता है कि उन्हें सही तरीके से कैसे हल किया जाए, इसलिए हमने नए क्लस्टर समाधान के लिए आवश्यकताओं की एक सूची तैयार की:

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

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

ActiveMQ के साथ, हमने लगभग सभी चीज़ों को हेज़ेलकास्ट में स्थानांतरित कर दिया:

ExecutorService के माध्यम से उपयोगकर्ता संसाधनों की पीढ़ी;
वितरित लॉक जब अधिकार बदले जाते हैं;
सर्वर की भूमिकाएं और विशेषताएँ (सेवा खोज);
ओपन बोर्ड आदि की एक रजिस्ट्री।

हेज़ेलकास्ट टोपोलॉजी

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

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

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

जब सदस्य लटकता है तो क्लस्टर हैंग हो जाता है

हेज़ेलकास्ट को चालू करने के कुछ सप्ताह बाद, समस्याओं को ठेस पर दिखाई दिया।

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

इस बिंदु पर शान्ति में हमने इन संदेशों को देखा:

 2015-07-15 15:35:51,466 [WARN] (cached18) com.hazelcast.spi.impl.operationservice.impl.Invocation: [my.host.address.com]:5701 [dev] [3.5] Asking ifoperation execution has been started: com.hazelcast.spi.impl.operationservice.impl.IsStillRunningService$InvokeIsStillRunningOperationRunnable@6d4274d7 2015-07-15 15:35:51,467 [WARN] (hz._hzInstance_1_dev.async.thread-3) com.hazelcast.spi.impl.operationservice.impl.Invocation:[my.host.address.com]:5701 [dev] [3.5] 'is-executing': true -> Invocation{ serviceName='hz:impl:executorService', op=com.hazelcast.executor.impl.operations.MemberCallableTaskOperation{serviceName='null', partitionId=-1, callId=18062, invocationTime=1436974430783, waitTimeout=-1,callTimeout=60000}, partitionId=-1, replicaIndex=0, tryCount=250, tryPauseMillis=500, invokeCount=1, callTimeout=60000,target=Address[my.host2.address.com]:5701, backupsExpected=0, backupsCompleted=0}

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

स्थिति को कई बार दोहराया गया था। यह पता चला कि यह हेज़ेलकास्ट संस्करण 3.5 में एक त्रुटि है, जिसमें दिल की धड़कन तंत्र को लागू किया गया था, जो अनुरोधों की स्थिति की जांच करता है। इसने हमारे द्वारा सामना किए गए कुछ सीमा मामलों की जांच नहीं की। मुझे आवेदन का अनुकूलन करना था ताकि इन मामलों में न पड़ें, और कुछ हफ्तों के बाद हेज़ेलकास्ट ने घर पर त्रुटि को ठीक किया।

हेज़ेलकास्ट से सदस्यों को बार-बार जोड़ना और हटाना

अगला मुद्दा जो हमने खोजा वह हैज़ेलकास्ट के सदस्यों को जोड़ना और हटाना।

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

जब एक सर्वर को बंद कर दिया जाता है, तो विभाजन अन्य सर्वरों को भेजे जाते हैं। यदि सर्वर की मृत्यु हो जाती है, तो विभाजन को इससे स्थानांतरित नहीं किया जाता है, लेकिन उन सर्वरों से जो अभी भी जीवित हैं और इन विभाजनों का बैकअप रखते हैं।

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

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

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

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

 hazelcastInstance .getExecutorService(...) .submit(new Task(), ...);

कार्य स्वयं एक नियमित जावा वर्ग की तरह दिखता है जो कॉलेबल को लागू करता है।

 public class Task implements Callable<Long> { @Override public Long call() { return 42; } }

समस्या यह है कि हेज़ेलकास्ट क्लाइंट न केवल जावा एप्लिकेशन, बल्कि C ++ एप्लिकेशन, .NET और अन्य भी हो सकते हैं। स्वाभाविक रूप से, हम अपने जावा क्लास को दूसरे प्लेटफॉर्म पर जेनरेट और कन्वर्ट नहीं कर सकते हैं।

एक विकल्प यह है कि अगर हम एक सर्वर से दूसरे सर्वर पर कुछ भेजना चाहते हैं और उत्तर प्राप्त करना चाहते हैं तो http-request का उपयोग करके स्विच करें। लेकिन फिर हमें हेज़लकास्ट को आंशिक रूप से त्यागना होगा।

इसलिए, एक समाधान के रूप में, हमने ExecutorService के बजाय कतारों का उपयोग करना चुना। ऐसा करने के लिए, हमने स्वतंत्र रूप से कतार में एक तत्व को निष्पादित करने के लिए प्रतीक्षा करने के लिए एक तंत्र लागू किया, जो सीमा के मामलों को संसाधित करता है और अनुरोध सर्वर पर परिणाम लौटाता है।

हमने क्या सीखा है

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

क्लीन आर्किटेक्चर में रॉबर्ट मार्टिन इस सिद्धांत के बारे में लिखते हैं:

“आर्किटेक्ट का लक्ष्य सिस्टम के लिए एक फॉर्म तैयार करना है जो राजनीति को सबसे महत्वपूर्ण तत्व बना देगा, और राजनीति से संबंधित विवरण नहीं। यह विवरण के बारे में निर्णय लेने में देरी और देरी करेगा। ”

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

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

क्लस्टर इंटरैक्शन का विकास। हमने ActiveMQ और हेज़ेलकास्ट को कैसे लागू किया