💪🏿 🖍️ 🏇🏿 ZeroMQ और टारनटूल पर आधारित स्मार्ट कैश सेवा 👲🏻 😮 👍🏾

रुस्लान अरोमातोव, मुख्य विकासकर्ता, आईसीडी

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

यह सब कैसे शुरू हुआ

लगभग 6 साल पहले, यह योजना सरल थी। आउटसोर्सिंग कंपनी से विरासत के रूप में, हमें iOS और Android के लिए दो मोबाइल बैंकिंग क्लाइंट मिले, साथ ही एक फ्रंट सर्वर भी था। सर्वर स्वयं जावा में लिखा गया था, अलग-अलग तरीकों (मुख्य रूप से साबुन) में इसके बैकेंड में गया, और https के माध्यम से xml प्रसारित करके ग्राहकों के साथ संवाद किया।

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

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

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

इसी समय, दोष सहिष्णुता, अतिरेक, प्रतिकृति, और - सोचने के लिए डरावने - हाईलोड जैसे मुद्दे उठने लगे।

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

ऐसा लगता था कि जीवन बेहतर हो रहा था ...

आप ऐसे नहीं रह सकते

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

सत्रों का नुकसान। सबसे महत्वपूर्ण माइनस। उदाहरण के लिए, एक एप्लिकेशन सर्वर -1 को दो अनुरोध भेजता है: पहला अनुरोध प्रमाणीकरण है, और दूसरा खातों की सूची के लिए एक अनुरोध है। प्रमाणीकरण सफल होता है, सर्वर -1 पर एक सत्र बनाया जाता है। इस समय, दूसरा क्लाइंट अनुरोध खराब संचार के कारण अचानक बंद हो जाता है, और एप्लिकेशन सर्वर -2 में स्विच हो जाता है, दूसरा अनुरोध अग्रेषित करता है। लेकिन एक निश्चित कार्यभार में, Infinispan के पास नोड्स के बीच डेटा को सिंक्रनाइज़ करने का समय नहीं हो सकता है। नतीजतन, सर्वर -2 क्लाइंट सत्र को सत्यापित नहीं कर सकता है, ग्राहक को क्रोधित प्रतिक्रिया भेजता है, ग्राहक उदास है और अपना सत्र समाप्त करता है। उपयोगकर्ता को फिर से लॉगिन करना होगा। दु: खी।
सर्वर को फिर से शुरू करने से सत्रों का नुकसान भी हो सकता है। उदाहरण के लिए, एक अद्यतन के बाद (और यह अक्सर होता है)। जब सर्वर -2 शुरू होता है, तो यह तब तक काम नहीं कर सकता जब तक सर्वर -1 के साथ डेटा को सिंक्रनाइज़ नहीं किया जाता है। ऐसा लगता है कि सर्वर शुरू हो गया, लेकिन वास्तव में अनुरोध स्वीकार नहीं करना चाहिए। यह असुविधाजनक है।
यह एक बिल्ट-इन WildFly मॉड्यूल है जो हमें इस एप्लिकेशन सर्वर से माइक्रोसॉर्विस की ओर जाने से रोकता है।

यहां से, हम जो चाहते हैं, उसकी एक सूची किसी तरह अपने आप ही बन गई थी।

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

पसंद का आटा

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

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

खैर, यह मुझे लगता है कि पहले से ही बहुत अधिक सिद्धांत था।

शुरू करो और खत्म करो

इस तरह की योजना का डिज़ाइन परिणाम लगभग था।

कोष

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

ग्राहक सत्रों के लिए तालिका (स्थान):

सत्र आईडी
ग्राहक आईडी;
संस्करण (सेवा)
अद्यतन समय (टाइमस्टैम्प);
जीवन काल (ttl);
क्रमबद्ध सत्र डेटा।

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

सरल कैश टेबल (किसी भी सत्र डेटा के लिए):

कुंजी;
सत्र आईडी
संग्रहीत डेटा का प्रकार (मनमानी संख्या);
अद्यतन समय (टाइमस्टैम्प);
जीवन काल (ttl);
क्रमबद्ध डेटा।

क्लाइंट डेटा की तालिका जिसे लॉगिन से पहले गर्म करने की आवश्यकता है:

ग्राहक आईडी;
सत्र आईडी
संस्करण (सेवा)
संग्रहीत डेटा का प्रकार (मनमानी संख्या);
अद्यतन समय (टाइमस्टैम्प);
राज्य;
क्रमबद्ध डेटा।

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

डिवाइस तालिका:

ग्राहक आईडी;
डिवाइस आईडी
अद्यतन समय (टाइमस्टैम्प);

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

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

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

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

जावा सेवा

एक विशिष्ट स्टेटलेस माइक्रोसर्विस के रूप में बनाया गया है। इसमें कोई भी विन्यास नहीं है, सभी आवश्यक पैरामीटर (और उनमें से 6 हैं) डॉकटर कंटेनर बनाते समय पर्यावरण चर के माध्यम से पारित किए जाते हैं। यह ZeroMQ ट्रांसपोर्ट (org.zeromq.jzmq - java इंटरफ़ेस देशी libzmq.so.5.1.1, जो हमने खुद बनाया था) के माध्यम से अपने स्वयं के प्रोटोकॉल का उपयोग करके काम करता है। यह जावा कनेक्टर (org.tarantool.connector) के माध्यम से टारेंटयुला के साथ काम करता है।

सेवा आरंभ काफी सरल है:

हम एक लकड़हारा (log4j2) शुरू करते हैं;
पर्यावरण चर (हम कर्ता में हैं) से हम काम के लिए आवश्यक मापदंडों को पढ़ते हैं;
हम मैट्रिक्स (जेटी) का सर्वर शुरू करते हैं;
टारेंटयुला से कनेक्ट करें (एसिंक्रोनस रूप से);
हम थ्रेड-हैंडलर (श्रमिकों) की आवश्यक संख्या शुरू करते हैं;
हम एक दलाल शुरू करते हैं (zmq) - एक अंतहीन संदेश प्रसंस्करण चक्र।

उपरोक्त सभी में, केवल संदेश प्रसंस्करण इंजन दिलचस्प है। नीचे microservice का आरेख है।

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

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

/** //   (   ,   ) ZContext zctx = new ZContext(); //    ZMQ.Socket clientServicePoint = zctx.createSocket(ZMQ.ROUTER); //    ZMQ.Socket workerServicePoint= zctx.createSocket(ZMQ.ROUTER); //     clientServicePoint.bind("tcp://*:" + Config.ZMQ_LISTEN_PORT); //     workerServicePoint.bind("inproc://worker-proc");

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

 /** *      */ public int run() { int status;  try {   ZMQ.Poller poller = new ZMQ.Poller(2);    poller.register(workerServicePoint, ZMQ.Poller.POLLIN);    poller.register(clientServicePoint, ZMQ.Poller.POLLIN);    int rc;    while (true) {      //        rc = poller.poll(POLL_INTERVAL);      if (rc == -1) {        status = -1;        logger.errorInternal("Broker run error rc = -1");        break; //  -     }    //     ()    if (poller.pollin(0)) {       processBackendMessage(ZMsg.recvMsg(workerServicePoint));    }    //        if (poller.pollin(1)) {       processFrontendMessage(ZMsg.recvMsg(clientServicePoint));    }    processQueueForBackend(); }  } catch (Exception e) {    status = -1;  } finally {    clientServicePoint.close();    workerServicePoint.close();  }  return status; }

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

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

आइए उपरोक्त योजना और कोड के उदाहरण का उपयोग करके एल्गोरिथ्म का विश्लेषण करें।

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

क्लाइंट सॉकेट पर एक घटना होती है - हमें message1 प्राप्त हुआ। दलाल आने वाले संदेश हैंडलर को कॉल करता है, जिसका कार्य है:

संदेश हेडर का विश्लेषण;
एक धारक वस्तु में एक संदेश को प्राथमिकता (हेडर विश्लेषण के आधार पर) और जीवनकाल के आधार पर रखना;
धारक को संदेश कतार में रखना;
यदि कतार भरी नहीं है, तो हैंडलर का कार्य समाप्त हो गया है;
यदि कतार भरी है, तो हम क्लाइंट को एक त्रुटि संदेश भेजने के लिए विधि कहते हैं।

लूप के समान पुनरावृत्ति में, हम संदेश पंक्ति हैंडलर कहते हैं:

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

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

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

जिन संदेशों का मैं लगातार उल्लेख करता हूं उनका प्रारूप हमारा अपना उत्पादन है। बॉक्स से बाहर, ZeroMQ हमें ZMsg कक्षाएं प्रदान करता है - संदेश स्वयं, और ZFrame - इस संदेश का एक अभिन्न अंग, अनिवार्य रूप से सिर्फ बाइट्स का एक सरणी, जिसे मैं उपयोग करने के लिए स्वतंत्र हूं। हमारे संदेश में दो भाग (दो ZFrames) होते हैं, जिनमें से पहला एक द्विआधारी हेडर है, और दूसरा डेटा है (अनुरोध शरीर, उदाहरण के लिए, बाइट्स की एक सरणी द्वारा दर्शाए गए एक जेंस स्ट्रिंग के रूप में)। संदेश शीर्षलेख सार्वभौमिक है और क्लाइंट से सर्वर, और सर्वर से क्लाइंट तक दोनों की यात्रा करता है।

वास्तव में, हमारे पास "अनुरोध" या "प्रतिक्रिया" की अवधारणा नहीं है, केवल संदेश। हेडर में शामिल हैं: प्रोटोकॉल संस्करण, सिस्टम प्रकार (जिसे सिस्टम संबोधित किया गया है), संदेश प्रकार, परिवहन स्तर त्रुटि कोड (यदि यह 0 नहीं है, तो संदेश हस्तांतरण इंजन में कुछ हुआ), अनुरोध आईडी (क्लाइंट से आने वाले पास-थ्रू पहचानकर्ता - ट्रेसिंग के लिए आवश्यक), क्लाइंट सेशन आईडी (वैकल्पिक), साथ ही डेटा स्तर की त्रुटि का संकेत (उदाहरण के लिए, यदि बैकएंड प्रतिक्रिया पार्स नहीं की जा सकती है, तो हम इस ध्वज को सेट करते हैं, ताकि क्लाइंट की तरफ पार्सर प्रतिक्रिया को डिस्क्राइब न करे, लेकिन त्रुटि डेटा प्राप्त करता है दूसरे तरीके से)।

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

प्रदर्शन और संसाधनों के बारे में थोड़ा सा

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

एक उदाहरण के रूप में: मुख्य धागे के अलावा, हमारी वर्तमान कैश कॉम्बैट सेवा ने एक और 100 वर्कर थ्रेड लॉन्च किए, और कतार का आकार तीन हजार संदेशों तक सीमित है। सामान्य ऑपरेशन में, प्रत्येक उदाहरण में प्रति सेकंड 200 संदेश होते हैं और 250 एमबी मेमोरी और लगभग 2-3% सीपीयू की खपत होती है। कभी-कभी चरम भार पर यह 7-8% तक कूद जाता है। यह सभी किसी न किसी तरह के दोहरे कोर वर्चुअल एक्सॉन पर काम करता है।

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

पहला स्क्रीनशॉट सेवा के नियमित संचालन को दर्शाता है।

और दूसरे पर, एक दुर्घटना हुई - किसी कारण के बैकएंड ने 30 सेकंड में जवाब नहीं दिया। यह देखा जाता है कि सबसे पहले सभी कार्यकर्ता भाग निकले, जिसके बाद संदेश की कतार शुरू हो गई।

प्रदर्शन परीक्षण

मेरी कार्यशील मशीन (CentOS 7, Core i5, 16Gb RAM) पर सिंथेटिक परीक्षणों ने निम्नलिखित दिखाया।

रिपॉजिटरी के साथ काम करें (टारेंटयुला के लिए लेखन और तुरंत आकार में 100 बाइट्स के इस रिकॉर्ड को पढ़ना - सत्र के साथ अनुकरण कार्य) - 12000 आरपीएस।

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

सेवा इंटेलिजेंस

चौकस पाठक शायद पहले से ही सवाल पूछता है - इस सेवा की "स्मार्टनेस" क्या है, जिसका शीर्षक में उल्लेख किया गया है। मैंने पहले ही इसे पारित करने का उल्लेख किया है, लेकिन अब मैं आपको और बताऊंगा।

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

और उन्होंने इसे काफी अच्छा किया। क्लाइंट कैश को गर्म करने का तर्क निम्नानुसार है:

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

इस प्रकार, व्यवहार में, हम फ्रंट सर्वर के लिए उत्पादों को 200 एमएस से 20 एमएस तक प्राप्त करने के लिए औसत समय को कम करने में सक्षम थे, अर्थात लगभग 10 गुना और बैकएंड के अनुरोधों की संख्या लगभग 4 गुना।

समस्याओं

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

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

एक बार डेटा सेंटर में किसी प्रकार की दुर्घटना हो गई, और यह पता चला कि ऑपरेटिंग सिस्टम (CentOS 7) ने हार्ड ड्राइव को देखना बंद कर दिया है। फ़ाइल सिस्टम रीड-ओनली मोड में चला गया। सबसे आश्चर्यजनक बात यह थी कि सेवाओं ने काम करना जारी रखा, क्योंकि हम सभी डेटा को स्मृति में रखते हैं। टारेंटयुला .xlog फ़ाइलों को नहीं लिख सकता है, किसी ने कुछ भी लॉग इन नहीं किया है, लेकिन किसी तरह सब कुछ काम किया। लेकिन पुनः आरंभ करने का प्रयास असफल रहा - कोई भी शुरू नहीं कर सका।

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

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

इसके तुरंत बाद, टारेंटयुला दास डेटा संशोधन अनुरोधों को स्वीकार करना शुरू कर देता है, जिसके परिणामस्वरूप मास्टर से प्रतिकृति अलग हो जाती है, और हमें असंगत डेटा मिलता है। एक ही समय में, सेवा -2 और 3 पूरी तरह से मास्टर के साथ काम करते हैं, और सेवा -1 पूर्व दास के साथ अच्छी तरह से संचार करता है। यह स्पष्ट है कि इस मामले में हम ग्राहक सत्र और किसी भी अन्य डेटा को खोना शुरू करते हैं, हालांकि सब कुछ तकनीकी पक्ष से काम करता है। हमने अभी तक ऐसी संभावित समस्या का समाधान नहीं किया है। सौभाग्य से, यह 2 वर्षों में नहीं हुआ है, लेकिन स्थिति काफी वास्तविक है। अब प्रत्येक सेवा को पता है कि वह किस स्टोर में जाती है, और हमारे पास इस मीट्रिक के लिए एक अलर्ट है, जो मास्टर से दास पर स्विच करते समय काम करेगा। और आपको अपने हाथों से सब कुछ ठीक करना होगा। आप इस तरह की समस्याओं का समाधान कैसे करते हैं?

योजनाओं

हम ऊपर वर्णित समस्या पर काम करने की योजना बनाते हैं, एक साथ एक प्रकार के अनुरोध के साथ व्यस्त श्रमिकों की संख्या को सीमित करते हैं, सुरक्षित (वर्तमान अनुरोधों को खोए बिना) सेवा को रोकते हुए, और आगे पॉलिशिंग करते हैं।

निष्कर्ष

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

यदि विषय समुदाय के लिए रुचि रखता है, तो मैं आपको हमारे कई समाधानों के बारे में बता सकता हूं जो बैंक के लिए ग्राहक सेवा की गुणवत्ता में सुधार करने में योगदान करते हैं।

ZeroMQ और टारनटूल पर आधारित स्मार्ट कैश सेवा