🥇हमने 1सी के लिए हाई-लोड स्केलेबल सेवा कैसे और क्यों लिखी: एंटरप्राइज़: जावा, पोस्टग्रेएसक्यूएल, हेज़ेलकास्ट

इस लेख में हम बात करेंगे कि हमने कैसे और क्यों विकास किया इंटरेक्शन सिस्टम - एक तंत्र जो क्लाइंट एप्लिकेशन और 1C:एंटरप्राइज़ सर्वर के बीच जानकारी स्थानांतरित करता है - किसी कार्य को सेट करने से लेकर आर्किटेक्चर और कार्यान्वयन विवरण के बारे में सोचने तक।

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

एसवी वितरित भंडारण का उपयोग करता है हेज़लकास्ट और खोज इंजन Elasticsearch. हम जावा के बारे में भी बात करेंगे और हम PostgreSQL को क्षैतिज रूप से कैसे मापते हैं।

समस्या का निरूपण

यह स्पष्ट करने के लिए कि हमने इंटरेक्शन सिस्टम क्यों बनाया, मैं आपको थोड़ा बताऊंगा कि 1सी में व्यावसायिक अनुप्रयोगों का विकास कैसे काम करता है।

आरंभ करने के लिए, उन लोगों के लिए हमारे बारे में थोड़ा सा जो अभी तक नहीं जानते कि हम क्या करते हैं :) हम 1C: एंटरप्राइज़ प्रौद्योगिकी प्लेटफ़ॉर्म बना रहे हैं। प्लेटफ़ॉर्म में एक व्यावसायिक अनुप्रयोग विकास उपकरण, साथ ही एक रनटाइम शामिल है जो व्यावसायिक अनुप्रयोगों को क्रॉस-प्लेटफ़ॉर्म वातावरण में चलाने की अनुमति देता है।

क्लाइंट-सर्वर विकास प्रतिमान

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

एप्लिकेशन कोड में, प्रक्रियाओं और कार्यों के हेडर को स्पष्ट रूप से इंगित करना चाहिए कि कोड कहां निष्पादित किया जाएगा - &AtClient / &AtServer निर्देशों (भाषा के अंग्रेजी संस्करण में &AtClient / &AtServer) का उपयोग करके। 1C डेवलपर्स अब मुझे यह कहकर सही करेंगे कि निर्देश वास्तव में हैं बेहतर, लेकिन हमारे लिए यह अब महत्वपूर्ण नहीं है.

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

कोड जो एक बटन क्लिक को संभालता है: क्लाइंट से सर्वर प्रक्रिया को कॉल करना काम करेगा, सर्वर से क्लाइंट प्रक्रिया को कॉल करना नहीं

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

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

उत्पादन ही

एक संदेश तंत्र बनाएँ. तेज़, विश्वसनीय, गारंटीकृत डिलीवरी के साथ, संदेशों को लचीले ढंग से खोजने की क्षमता के साथ। तंत्र के आधार पर, 1सी अनुप्रयोगों के अंदर चलने वाले एक मैसेंजर (संदेश, वीडियो कॉल) को कार्यान्वित करें।

सिस्टम को क्षैतिज रूप से स्केलेबल होने के लिए डिज़ाइन करें। बढ़ते लोड को नोड्स की संख्या बढ़ाकर कवर किया जाना चाहिए।

कार्यान्वयन

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

इसलिए, हमने एसवी को एक अलग उत्पाद के रूप में बनाने का फैसला किया। हम अनुशंसा करते हैं कि छोटी कंपनियाँ सीबी सर्वर का उपयोग करें जिसे हमने अपने क्लाउड (wss://1cdialog.com) में स्थापित किया है ताकि सर्वर की स्थानीय स्थापना और कॉन्फ़िगरेशन से जुड़ी ओवरहेड लागत से बचा जा सके। बड़े ग्राहकों को अपनी सुविधाओं पर अपना स्वयं का सीबी सर्वर स्थापित करना उचित लग सकता है। हमने अपने क्लाउड SaaS उत्पाद में एक समान दृष्टिकोण का उपयोग किया 1सीताजा - इसे ग्राहकों की साइटों पर इंस्टॉलेशन के लिए बड़े पैमाने पर उत्पादित उत्पाद के रूप में उत्पादित किया जाता है, और इसे हमारे क्लाउड में भी तैनात किया जाता है https://1cfresh.com/.

अनुप्रयोग

लोड और दोष सहनशीलता को वितरित करने के लिए, हम एक नहीं, बल्कि कई जावा एप्लिकेशन तैनात करेंगे, जिनके सामने एक लोड बैलेंसर होगा। यदि आपको किसी संदेश को नोड से नोड में स्थानांतरित करने की आवश्यकता है, तो हेज़लकास्ट में प्रकाशित/सदस्यता लें का उपयोग करें।

क्लाइंट और सर्वर के बीच संचार वेबसोकेट के माध्यम से होता है। यह रीयल-टाइम सिस्टम के लिए उपयुक्त है।

वितरित कैश

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

हमारे लिए, हेज़लकास्ट है:

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

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

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

DBMS चुनना

हमारे पास PostgreSQL के साथ काम करने और इस DBMS के डेवलपर्स के साथ सहयोग करने का व्यापक और सफल अनुभव है।

PostgreSQL क्लस्टर के साथ यह आसान नहीं है - वहाँ है XL, XC, साइटस, लेकिन सामान्य तौर पर ये बॉक्स से बाहर स्केल करने वाले NoSQL नहीं हैं। हमने NoSQL को मुख्य स्टोरेज नहीं माना; यह पर्याप्त था कि हमने हेज़ेलकास्ट लिया, जिसके साथ हमने पहले काम नहीं किया था।

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

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

उदाहरण के लिए, आप वेबसाइट पर बहु-किरायेदार के बारे में पढ़ सकते हैं साइटस डेटा.

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

हमारे पास एक मुख्य डेटाबेस है जहां सभी ग्राहक डेटाबेस के स्थान के बारे में जानकारी के साथ एक रूटिंग टेबल संग्रहीत है।

मुख्य डेटाबेस को बाधा बनने से रोकने के लिए, हम राउटिंग टेबल (और अन्य अक्सर आवश्यक डेटा) को कैश में रखते हैं।

यदि सब्सक्राइबर का डेटाबेस धीमा होने लगता है, तो हम इसे अंदर के विभाजनों में काट देंगे। अन्य परियोजनाओं पर हम उपयोग करते हैं pg_pathman.

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

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

खोज के लिए इलास्टिक्स खोज

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

जीथब पर हमने पाया रूसी आकृति विज्ञान प्लगइन Elasticsearch के लिए और इसका उपयोग करें। इलास्टिक्स खोज सूचकांक में हम शब्द जड़ों (जिसे प्लगइन निर्धारित करता है) और एन-ग्राम संग्रहीत करते हैं। जैसे ही उपयोगकर्ता खोज के लिए पाठ में प्रवेश करता है, हम एन-ग्राम के बीच टाइप किए गए पाठ की तलाश करते हैं। सूचकांक में सहेजे जाने पर, शब्द "टेक्स्ट" को निम्नलिखित एन-ग्राम में विभाजित किया जाएगा:

[वे, टेक, टेक्स, टेक्स्ट, टेक्स्ट, एक, पूर्व, टेक्स्ट, टेक्स्ट, केएस, केएसटी, केएसटीवाई, एसटी, स्टाई, आप],

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

कुल मिलाकर तस्वीर

लेख की शुरुआत से चित्र की पुनरावृत्ति, लेकिन स्पष्टीकरण के साथ:

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

विकास एवं परीक्षण

एसवी के विकास और परीक्षण की प्रक्रिया में, हमें हमारे द्वारा उपयोग किए जाने वाले उत्पादों की कई दिलचस्प विशेषताओं के बारे में पता चला।

लोड परीक्षण और मेमोरी लीक

प्रत्येक एसवी रिलीज की रिलीज में लोड परीक्षण शामिल है। यह तब सफल होता है जब:

परीक्षण कई दिनों तक काम करता रहा और कोई सेवा विफलता नहीं हुई
प्रमुख परिचालनों के लिए प्रतिक्रिया समय एक आरामदायक सीमा से अधिक नहीं था
पिछले संस्करण की तुलना में प्रदर्शन में गिरावट 10% से अधिक नहीं है

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

हम तीन कॉन्फ़िगरेशन में इंटरेक्शन सिस्टम का लोड परीक्षण करते हैं:

तनाव की जांच
केवल कनेक्शन
सब्सक्राइबर पंजीकरण

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

उदाहरण के लिए, तनाव परीक्षण का भाग इस प्रकार दिखता है:

उपयोगकर्ता लॉग इन करता है
- आपकी अपठित चर्चाओं का अनुरोध करता हूँ
- संदेश पढ़ने की संभावना 50% है
- पाठ करने की संभावना 50% है
- अगला उपयोगकर्ता:
  - नई चर्चा पैदा होने की 20% संभावना है
  - अपनी किसी भी चर्चा को यादृच्छिक रूप से चुनता है
  - अंदर चला जाता है
  - अनुरोध संदेश, उपयोगकर्ता प्रोफ़ाइल
  - इस चर्चा से यादृच्छिक उपयोगकर्ताओं को संबोधित पांच संदेश बनाता है
  - चर्चा छोड़ देता है
  - 20 बार दोहराता है
  - लॉग आउट करता है, स्क्रिप्ट की शुरुआत में वापस जाता है
- एक चैटबॉट सिस्टम में प्रवेश करता है (एप्लिकेशन कोड से मैसेजिंग का अनुकरण करता है)
  - डेटा विनिमय के लिए एक नया चैनल बनाने की 50% संभावना है (विशेष चर्चा)
  - किसी भी मौजूदा चैनल पर संदेश लिखने की 50% संभावना है

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

ग्राहक पंजीकरण स्क्रिप्ट पहले लॉन्च से शुरू होती है। हमने एक तनाव परीक्षण किया और आश्वस्त थे कि पत्राचार के दौरान सिस्टम धीमा नहीं हुआ। लेकिन उपयोगकर्ता आए और समय समाप्त होने के कारण पंजीकरण विफल होने लगा। पंजीकरण करते समय हमने उपयोग किया / Dev / यादृच्छिक, जो सिस्टम की एन्ट्रापी से संबंधित है। सर्वर के पास पर्याप्त एन्ट्रॉपी जमा करने का समय नहीं था और जब एक नए सिक्योररैंडम का अनुरोध किया गया, तो यह दसियों सेकंड के लिए रुक गया। इस स्थिति से बाहर निकलने के कई तरीके हैं, उदाहरण के लिए: कम सुरक्षित /dev/urandom पर स्विच करें, एक विशेष बोर्ड स्थापित करें जो एन्ट्रापी उत्पन्न करता है, पहले से यादृच्छिक संख्याएँ उत्पन्न करता है और उन्हें एक पूल में संग्रहीत करता है। हमने पूल के साथ समस्या को अस्थायी रूप से बंद कर दिया है, लेकिन तब से हम नए ग्राहकों को पंजीकृत करने के लिए एक अलग परीक्षण चला रहे हैं।

हम लोड जनरेटर के रूप में उपयोग करते हैं JMeter. यह नहीं जानता कि वेबसॉकेट के साथ कैसे काम करना है; इसे एक प्लगइन की आवश्यकता है। "जेएमटर वेबसॉकेट" क्वेरी के लिए खोज परिणामों में प्रथम हैं: ब्लेज़मीटर के लेख, जो अनुशंसा करता है मैकिएज ज़लेस्की द्वारा प्लगइन.

यहीं से हमने शुरुआत करने का फैसला किया।

गंभीर परीक्षण शुरू करने के लगभग तुरंत बाद, हमें पता चला कि JMeter ने मेमोरी लीक करना शुरू कर दिया है।

प्लगइन एक अलग बड़ी कहानी है; 176 सितारों के साथ, जीथब पर इसके 132 फोर्क हैं। लेखक ने स्वयं 2015 के बाद से इसके लिए प्रतिबद्ध नहीं किया है (हमने इसे 2015 में लिया था, तब इसने संदेह पैदा नहीं किया था), मेमोरी लीक के संबंध में कई जीथब मुद्दे, 7 अज्ञात पुल अनुरोध।
यदि आप इस प्लगइन का उपयोग करके लोड परीक्षण करने का निर्णय लेते हैं, तो कृपया निम्नलिखित चर्चाओं पर ध्यान दें:

बहु-थ्रेडेड वातावरण में, एक नियमित लिंक्डलिस्ट का उपयोग किया गया था, और परिणाम यह था एनपीई रनटाइम में. इसे या तो ConcurrentLinkedDeque पर स्विच करके या सिंक्रोनाइज़्ड ब्लॉक्स द्वारा हल किया जा सकता है। हमने अपने लिए पहला विकल्प चुना (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
मेमोरी लीक; डिस्कनेक्ट होने पर, कनेक्शन जानकारी हटाई नहीं जाती है (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
स्ट्रीमिंग मोड में (जब वेबसॉकेट नमूने के अंत में बंद नहीं होता है, लेकिन बाद में योजना में उपयोग किया जाता है), प्रतिक्रिया पैटर्न काम नहीं करते हैं (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

यह जीथब पर मौजूद लोगों में से एक है। हमने क्या किया था:

ले लिया है कांटा एलीरन कोगन (@elyrank) - यह समस्या 1 और 3 को ठीक करता है
हल हुई समस्या 2
जेटी को 9.2.14 से 9.3.12 तक अद्यतन किया गया
ThreadLocal में SimpleDateFormat लपेटा गया; SimpleDateFormat थ्रेड-सुरक्षित नहीं है, जिसके कारण रनटाइम पर NPE हो गया
एक और मेमोरी लीक को ठीक किया गया (डिस्कनेक्ट होने पर कनेक्शन गलत तरीके से बंद हो गया था)

और फिर भी यह बहती है!

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

दो दिन बीत गए...

अब हेज़लकास्ट की स्मृति ख़त्म हो रही है. लॉग से पता चला कि कुछ दिनों के परीक्षण के बाद, हेज़लकास्ट ने मेमोरी की कमी के बारे में शिकायत करना शुरू कर दिया, और कुछ समय बाद क्लस्टर टूट गया, और नोड्स एक-एक करके मरते रहे। हमने JVisualVM को हेज़लकास्ट से जोड़ा और एक "राइजिंग सॉ" देखा - यह नियमित रूप से GC को कॉल करता था, लेकिन मेमोरी को साफ़ नहीं कर सका।

यह पता चला कि हेज़ेलकास्ट 3.4 में, मानचित्र / मल्टीमैप (map.destroy()) को हटाते समय, मेमोरी पूरी तरह से मुक्त नहीं होती है:

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

बग को अब 3.5 में ठीक कर दिया गया है, लेकिन तब यह एक समस्या थी। हमने गतिशील नामों के साथ नए मल्टीमैप्स बनाए और अपने तर्क के अनुसार उन्हें हटा दिया। कोड कुछ इस तरह दिखता था:

public void join(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

पुकारना:

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

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

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

चार्ट में सुधार हुआ है.

लोड परीक्षण के बारे में हमने और क्या सीखा है?

JSR223 को ग्रूवी में लिखने और संकलन कैश को शामिल करने की आवश्यकता है - यह बहुत तेज़ है। लिंक.
जेमीटर-प्लगइन्स ग्राफ़ को मानक ग्राफ़ की तुलना में समझना आसान है। लिंक.

हेज़लकास्ट के साथ हमारे अनुभव के बारे में

हेज़लकास्ट हमारे लिए एक नया उत्पाद था, हमने संस्करण 3.4.1 से इसके साथ काम करना शुरू किया, अब हमारा उत्पादन सर्वर संस्करण 3.9.2 चला रहा है (लेखन के समय, हेज़लकास्ट का नवीनतम संस्करण 3.10 है)।

आईडी जनरेशन

हमने पूर्णांक पहचानकर्ताओं के साथ शुरुआत की। आइए कल्पना करें कि हमें एक नई इकाई के लिए एक और लॉन्ग की आवश्यकता है। डेटाबेस में अनुक्रम उपयुक्त नहीं है, तालिकाएँ शार्डिंग में शामिल हैं - यह पता चलता है कि DB1 में एक संदेश ID=1 है और DB1 में एक संदेश ID=2 है, आप इस ID को Elasticsearch में नहीं डाल सकते, न ही हेज़ेलकास्ट में , लेकिन सबसे बुरी बात यह है कि यदि आप डेटा को दो डेटाबेस से एक में जोड़ना चाहते हैं (उदाहरण के लिए, यह निर्णय लेना कि एक डेटाबेस इन ग्राहकों के लिए पर्याप्त है)। आप हेज़लकास्ट में कई एटॉमिकलॉन्ग जोड़ सकते हैं और काउंटर को वहां रख सकते हैं, फिर एक नई आईडी प्राप्त करने का प्रदर्शन बढ़ जाता है और साथ ही हेज़लकास्ट के लिए अनुरोध का समय बढ़ जाता है। लेकिन हेज़लकास्ट के पास कुछ अधिक इष्टतम है - FlakeIdGenerator। प्रत्येक ग्राहक से संपर्क करने पर, उन्हें एक आईडी रेंज दी जाती है, उदाहरण के लिए, पहला - 1 से 10 तक, दूसरा - 000 से 10 तक, और इसी तरह। अब ग्राहक अपने आप नए पहचानकर्ता जारी कर सकता है जब तक कि उसे जारी की गई सीमा समाप्त न हो जाए। यह तेजी से काम करता है, लेकिन जब आप एप्लिकेशन (और हेज़ेलकास्ट क्लाइंट) को पुनरारंभ करते हैं, तो एक नया अनुक्रम शुरू होता है - इसलिए स्किप आदि। इसके अलावा, डेवलपर्स वास्तव में यह नहीं समझते हैं कि आईडी पूर्णांक क्यों हैं, लेकिन इतनी असंगत हैं। हमने सब कुछ तौला और यूयूआईडी पर स्विच किया।

वैसे, जो लोग ट्विटर जैसा बनना चाहते हैं, उनके लिए ऐसी स्नोकास्ट लाइब्रेरी है - यह हेज़लकास्ट के शीर्ष पर स्नोफ्लेक का कार्यान्वयन है। आप इसे यहां देख सकते हैं:

github.com/noctarius/snowcast
github.com/twitter/snowflake

लेकिन हम अब तक इसके आसपास नहीं पहुंचे हैं।

ट्रांजेक्शनलमैप.प्रतिस्थापन

एक और आश्चर्य: TransactionalMap.replace काम नहीं करता। यहाँ एक परीक्षण है:

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Expected : newValue
Actual : oldValue

मुझे getForUpdate का उपयोग करके अपना स्वयं का प्रतिस्थापन लिखना पड़ा:

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

न केवल नियमित डेटा संरचनाओं का परीक्षण करें, बल्कि उनके लेनदेन संबंधी संस्करणों का भी परीक्षण करें। ऐसा होता है कि IMAp काम करता है, लेकिन TransactionalMap अब मौजूद नहीं है।

बिना डाउनटाइम के नया JAR डालें

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

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

हम पढ़ते हैं:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

सब कुछ काम कर रहा है. फिर हमने खोजने के लिए हेज़लकास्ट में एक इंडेक्स बनाने का निर्णय लिया:

map.addIndex("subscriberId", false);

और एक नई इकाई लिखते समय, उन्हें ClassNotFoundException प्राप्त होना शुरू हो गया। हेज़लकास्ट ने सूचकांक में जोड़ने की कोशिश की, लेकिन वह हमारी कक्षा के बारे में कुछ नहीं जानता था और चाहता था कि इस कक्षा के साथ एक JAR उसे आपूर्ति की जाए। हमने वैसा ही किया, सब कुछ काम कर गया, लेकिन एक नई समस्या सामने आई: क्लस्टर को पूरी तरह से बंद किए बिना JAR को कैसे अपडेट किया जाए? नोड-दर-नोड अपडेट के दौरान हेज़लकास्ट नया JAR नहीं उठाता है। इस बिंदु पर हमने निर्णय लिया कि हम सूचकांक खोज के बिना रह सकते हैं। आख़िरकार, यदि आप हेज़लकास्ट को की-वैल्यू स्टोर के रूप में उपयोग करते हैं, तो सब कुछ काम करेगा? ज़रूरी नहीं। यहां भी IMAp और TransactionalMap का व्यवहार अलग है। जहां IMAp को कोई परवाह नहीं है, वहां TransactionalMap एक त्रुटि देता है।

आईमैप. हम 5000 वस्तुएं लिखते हैं, पढ़ते हैं। सब कुछ अपेक्षित है.

@Test
void get5000() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

लेकिन यह लेन-देन में काम नहीं करता है, हमें एक ClassNotFoundException मिलता है:

@Test
void get_transaction() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

3.8 में, उपयोगकर्ता वर्ग परिनियोजन तंत्र दिखाई दिया। आप एक मास्टर नोड निर्दिष्ट कर सकते हैं और उस पर JAR फ़ाइल को अपडेट कर सकते हैं।

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

हम उच्च प्रदर्शन कैसे सुनिश्चित करते हैं

हेज़लकास्ट की चार यात्राएँ - अच्छी, डेटाबेस की दो - ख़राब

डेटा के लिए कैश में जाना डेटाबेस पर जाने से हमेशा बेहतर होता है, लेकिन आप अप्रयुक्त रिकॉर्ड को भी संग्रहीत नहीं करना चाहते हैं। हम विकास के अंतिम चरण तक क्या कैश करना है इसका निर्णय छोड़ देते हैं। जब नई कार्यक्षमता कोडित हो जाती है, तो हम PostgreSQL (log_min_duration_statement to 0) में सभी प्रश्नों की लॉगिंग चालू करते हैं और 20 मिनट के लिए लोड परीक्षण चलाते हैं। एकत्रित लॉग का उपयोग करके, pgFouine और pgBadger जैसी उपयोगिताएँ विश्लेषणात्मक रिपोर्ट बना सकती हैं। रिपोर्ट में, हम मुख्य रूप से धीमी और बार-बार आने वाली क्वेरीज़ पर ध्यान देते हैं। धीमी क्वेरी के लिए, हम एक निष्पादन योजना (EXPLAIN) बनाते हैं और मूल्यांकन करते हैं कि क्या ऐसी क्वेरी को त्वरित किया जा सकता है। समान इनपुट डेटा के लिए बार-बार अनुरोध कैश में अच्छी तरह से फिट होते हैं। हम प्रश्नों को "सपाट" रखने का प्रयास करते हैं, प्रति प्रश्न एक तालिका।

शोषण

एक ऑनलाइन सेवा के रूप में एसवी को 2017 के वसंत में परिचालन में लाया गया था, और एक अलग उत्पाद के रूप में, एसवी को नवंबर 2017 में जारी किया गया था (उस समय बीटा संस्करण स्थिति में)।

संचालन के एक वर्ष से अधिक समय में, सीबी ऑनलाइन सेवा के संचालन में कोई गंभीर समस्या नहीं आई है। हम ऑनलाइन सेवा की निगरानी करते हैं Zabbix, से एकत्र करें और तैनात करें बांस.

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

स्रोत: www.habr.com

हमने 1सी के लिए हाई-लोड स्केलेबल सेवा कैसे और क्यों लिखी: एंटरप्राइज़: जावा, पोस्टग्रेएसक्यूएल, हेज़ेलकास्ट