🧜🏿 👨🏽‍🚒 🌰 हमने 1C: Enterprise: Java, PostgreSQL, हेज़ेलकास्ट के लिए एक अत्यधिक भरी हुई स्केलेबल सेवा कैसे और क्यों लिखी 🐛 💇🏼 🤜

इस अनुच्छेद में, हम इस बारे में बात करेंगे कि हमने कैसे और क्यों बातचीत प्रणाली विकसित की है - एक तंत्र जो क्लाइंट अनुप्रयोगों और 1 सी के बीच जानकारी स्थानांतरित करता है: एंटरप्राइज़ सर्वर - कार्य को स्थापित करने से लेकर वास्तुकला और कार्यान्वयन के विवरण तक।

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

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

समस्या का बयान

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

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

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

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

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

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

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

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

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

वास्तव में मंचन

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

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

कार्यान्वयन

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

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

आवेदन

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

सर्वर के साथ क्लाइंट का संचार - वेबसोकेट द्वारा। यह वास्तविक समय प्रणालियों के लिए अच्छी तरह से अनुकूल है।

वितरित कैश

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

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

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

conversationKeyChecker.check(""); doInClusterLock("", () -> { conversationKeyChecker.check(""); createChannel(""); });

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

एक DBMS चुनना

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

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

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

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

आप मल्टी-टेनेंट के बारे में पढ़ सकते हैं , उदाहरण के लिए, साइटस डेटा वेबसाइट पर।

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

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

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

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

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

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

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

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

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

[वे, टेक, टेक्स, टेक्स्ट, टेक्स्ट, ईक, ईक, एक्स्ट, ईकेस्ट, के, केएसटी, केटी, केएसटी, सेंट, सेंट, यू],

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

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

लेख की शुरुआत से तस्वीर को दोहराते हुए, लेकिन स्पष्टीकरण के साथ:

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

विकास और परीक्षण

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

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

प्रत्येक सीबी की रिहाई तनाव परीक्षण है। यह सफल रहा जब:

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

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

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

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

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

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

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

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

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

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

उसके साथ हमने शुरू करने का फैसला किया।

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

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

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

यह गीथुब में से एक है। हमने क्या किया है:

उन्होंने कांटा लिया Elyran Kogan (@elyrank) - समस्याओं 1 और 3 को इसमें तय किया गया था
हल की समस्या २
9.2.14 से 9.3.12 तक अद्यतन जेटी
थ्रेडलोकल में लपेटा गया सिंपलडेटफार्म; 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 है और DB2 में एक संदेश ID = 1 है, आप इस तरह की आईडी को Elasticsearch में या तो हेज़लकास्ट में नहीं डाल सकते हैं, लेकिन सबसे बुरी बात यह है कि यदि आप डेटा कम करना चाहते हैं दो डेटाबेस में से एक में (उदाहरण के लिए, यह तय करना कि एक डेटाबेस इन ग्राहकों के लिए पर्याप्त है)। आप हेज़ेलकास्ट में कई एटॉमिकलॉन्ग बना सकते हैं और वहां काउंटर रख सकते हैं, फिर एक नई आईडी प्राप्त करने का प्रदर्शन इंक्रीमेंट है और साथ ही हेज़ेलकास्ट में अनुरोध के लिए समय है। लेकिन हेज़लकास्ट के बारे में कुछ और अधिक इष्टतम है - फ्लेकेआईडेनजेनर। प्रत्येक ग्राहक को संपर्क करने पर एक आईडी रेंज दी जाती है, उदाहरण के लिए, 1 से 10,000 तक का पहला, 10,001 से 20,000 तक का दूसरा, और इसी तरह। अब ग्राहक नए पहचानकर्ताओं को स्वतंत्र रूप से जारी कर सकता है जब तक कि जारी की गई सीमा समाप्त नहीं हो जाती। यह जल्दी से काम करता है, लेकिन जब आप एप्लिकेशन (और हेज़ेलकास्ट क्लाइंट) को पुनरारंभ करते हैं, तो एक नया अनुक्रम शुरू होता है - इसलिए अंतराल, आदि। इसके अलावा, डेवलपर्स बहुत स्पष्ट नहीं हैं कि आईडी पूर्णांक क्यों हैं, लेकिन वे इतने अलग तरीके से जाते हैं। हम सभी का वजन हुआ और यूयूआईडी में बदल गया।

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

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

लेकिन हम उसके हाथ नहीं पहुंचे हैं।

TransactionalMap.replace

एक और आश्चर्य: 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 चला गया है।

डाउनटाइम के बिना नए जार संलग्न करें

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

 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 को नहीं उठाता है। इस समय, हमने निर्णय लिया कि हम सूचकांक द्वारा खोज किए बिना बहुत अच्छी तरह से रह सकते हैं। आखिरकार, यदि आप हेज़लकास्ट को एक कुंजी-मूल्य भंडारण के रूप में उपयोग करते हैं, तो क्या सब कुछ काम करेगा? वास्तव में नहीं। यहाँ फिर से, IMap और TransactionalMap के विभिन्न व्यवहार। जहां IMap कोई मायने नहीं रखता, वहीं TransactionalMap एक त्रुटि फेंकता है।

IMAP। हम 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 में क्रमबद्ध करते हैं और इसे हेज़ेलकास्ट में सहेजते हैं। हेज़ेलकास्ट को हमारी कक्षाओं की संरचना को जानने की आवश्यकता नहीं है, लेकिन हम डाउनटाइम के बिना अपडेट कर सकते हैं। डोमेन ऑब्जेक्ट का संस्करण अनुप्रयोग द्वारा नियंत्रित किया जाता है। एप्लिकेशन के विभिन्न संस्करणों को एक ही समय में लॉन्च किया जा सकता है, और यह संभव है कि एक नया एप्लिकेशन नए क्षेत्रों के साथ ऑब्जेक्ट लिखता है, लेकिन पुराने को इन क्षेत्रों के बारे में पता नहीं है। और उसी समय, नया एप्लिकेशन पुराने एप्लिकेशन द्वारा रिकॉर्ड की गई वस्तुओं को पढ़ता है, जिसमें कोई नया फ़ील्ड नहीं है। हम एप्लिकेशन के अंदर ऐसी स्थितियों को संभालते हैं, लेकिन सादगी के लिए हम फ़ील्ड नहीं बदलते या हटाते नहीं हैं, हम केवल नए फ़ील्ड जोड़कर कक्षाएं बढ़ाते हैं।

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

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

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

शोषण

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

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

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

हमने 1C: Enterprise: Java, PostgreSQL, हेज़ेलकास्ट के लिए एक अत्यधिक भरी हुई स्केलेबल सेवा कैसे और क्यों लिखी