🥇आम्ही 1C साठी उच्च-लोड स्केलेबल सेवा कशी आणि का लिहिली: Enterprise: Java, PostgreSQL, Hazelcast

या लेखात आपण कसे आणि का विकसित केले याबद्दल बोलू परस्परसंवाद प्रणाली - क्लायंट ऍप्लिकेशन्स आणि 1C:एंटरप्राइझ सर्व्हर दरम्यान माहिती हस्तांतरित करणारी यंत्रणा - कार्य सेट करण्यापासून ते आर्किटेक्चर आणि अंमलबजावणी तपशीलांद्वारे विचार करण्यापर्यंत.

परस्परसंवाद प्रणाली (यापुढे SV म्हणून संदर्भित) एक वितरित, दोष-सहिष्णु संदेशन प्रणाली आहे ज्यात वितरणाची हमी आहे. SV ची रचना उच्च स्केलेबिलिटीसह उच्च-लोड सेवा म्हणून केली गेली आहे, ऑनलाइन सेवा (1C द्वारे प्रदान केलेली) आणि मोठ्या प्रमाणात उत्पादित उत्पादन म्हणून उपलब्ध आहे जी आपल्या स्वतःच्या सर्व्हर सुविधांवर तैनात केली जाऊ शकते.

SV वितरित स्टोरेज वापरते हेझेलकास्ट आणि शोध इंजिन Elasticsearch. आम्ही Java बद्दल आणि PostgreSQL क्षैतिजरित्या कसे स्केल करतो याबद्दल देखील बोलू.

समस्येची निर्मिती

आम्ही परस्परसंवाद प्रणाली का तयार केली हे स्पष्ट करण्यासाठी, मी तुम्हाला 1C मध्ये व्यवसाय अनुप्रयोगांचा विकास कसा कार्य करतो याबद्दल थोडेसे सांगेन.

सुरुवातीला, आम्ही काय करतो हे अद्याप माहित नसलेल्यांसाठी आमच्याबद्दल थोडेसे :) आम्ही 1C:Enterprise तंत्रज्ञान मंच बनवत आहोत. प्लॅटफॉर्ममध्ये बिझनेस ऍप्लिकेशन डेव्हलपमेंट टूल, तसेच रनटाइम समाविष्ट आहे जो क्रॉस-प्लॅटफॉर्म वातावरणात बिझनेस ऍप्लिकेशन्स चालवण्यास अनुमती देतो.

क्लायंट-सर्व्हर विकास नमुना

1C वर तयार केलेले व्यवसाय अनुप्रयोग: एंटरप्राइझ तीन-स्तरीय कार्य करतात क्लायंट-सर्व्हर आर्किटेक्चर "DBMS - ऍप्लिकेशन सर्व्हर - क्लायंट". अर्ज कोड लिहिलेला आहे अंगभूत 1C भाषा, अनुप्रयोग सर्व्हरवर किंवा क्लायंटवर कार्यान्वित केले जाऊ शकते. ऍप्लिकेशन ऑब्जेक्ट्स (डिरेक्टरी, दस्तऐवज इ.) सह सर्व कार्य, तसेच डेटाबेस वाचणे आणि लिहिणे, केवळ सर्व्हरवर केले जाते. फॉर्म आणि कमांड इंटरफेसची कार्यक्षमता देखील सर्व्हरवर लागू केली जाते. क्लायंट फॉर्म प्राप्त करणे, उघडणे आणि प्रदर्शित करणे, वापरकर्त्याशी "संप्रेषण करणे" (इशारे, प्रश्न...), फॉर्ममध्ये लहान गणना करतो ज्यासाठी द्रुत प्रतिसाद आवश्यक असतो (उदाहरणार्थ, किंमत प्रमाणानुसार गुणाकार करणे), स्थानिक फाइल्ससह कार्य करणे, उपकरणांसह काम करणे.

ऍप्लिकेशन कोडमध्ये, प्रक्रिया आणि फंक्शन्सच्या शीर्षलेखांनी स्पष्टपणे सूचित केले पाहिजे की कोड कुठे अंमलात आणला जाईल - &AtClient / &AtServer निर्देशांचा वापर करून (&AtClient / &AtServer भाषेच्या इंग्रजी आवृत्तीमध्ये). 1C विकासक आता मला असे सांगून दुरुस्त करतील की निर्देश प्रत्यक्षात आहेत पेक्षा अधिक, परंतु आमच्यासाठी हे आता महत्त्वाचे नाही.

तुम्ही क्लायंट कोडवरून सर्व्हर कोड कॉल करू शकता, परंतु तुम्ही सर्व्हर कोडवरून क्लायंट कोड कॉल करू शकत नाही. ही एक मूलभूत मर्यादा आहे जी आम्ही अनेक कारणांसाठी केली आहे. विशेषतः, कारण सर्व्हर कोड अशा प्रकारे लिहिला जाणे आवश्यक आहे की तो क्लायंटकडून किंवा सर्व्हरकडून कॉल केला जात असला तरीही तो त्याच प्रकारे कार्यान्वित करतो. आणि दुसर्‍या सर्व्हर कोडवरून सर्व्हर कोड कॉल करण्याच्या बाबतीत, असा कोणताही क्लायंट नाही. आणि कारण सर्व्हर कोडच्या अंमलबजावणीदरम्यान, ज्या क्लायंटने त्याला कॉल केला तो बंद करू शकतो, ऍप्लिकेशनमधून बाहेर पडू शकतो आणि सर्व्हरकडे यापुढे कोणीही कॉल करणार नाही.

बटण क्लिक हाताळणारा कोड: क्लायंटकडून सर्व्हर प्रक्रिया कॉल करणे कार्य करेल, सर्व्हरवरून क्लायंट प्रक्रियेस कॉल करणे कार्य करणार नाही

याचा अर्थ असा की जर आम्हाला सर्व्हरवरून क्लायंट ऍप्लिकेशनला काही संदेश पाठवायचा असेल, उदाहरणार्थ, “दीर्घकाळ चालणार्‍या” अहवालाची निर्मिती पूर्ण झाली आहे आणि अहवाल पाहिला जाऊ शकतो, तर आमच्याकडे अशी पद्धत नाही. तुम्हाला युक्त्या वापराव्या लागतील, उदाहरणार्थ, क्लायंट कोडवरून वेळोवेळी सर्व्हरचे मतदान करा. परंतु हा दृष्टीकोन अनावश्यक कॉलसह सिस्टम लोड करतो आणि सामान्यत: फार मोहक दिसत नाही.

आणि एक गरज देखील आहे, उदाहरणार्थ, जेव्हा टेलिफोन कॉल येतो एसआयपी- कॉल करताना, क्लायंट ऍप्लिकेशनला याबद्दल सूचित करा जेणेकरुन तो कॉलरचा नंबर काउंटरपार्टी डेटाबेसमध्ये शोधण्यासाठी वापरू शकेल आणि वापरकर्त्याला कॉलिंग काउंटरपार्टीबद्दल माहिती दर्शवू शकेल. किंवा, उदाहरणार्थ, गोदामात ऑर्डर आल्यावर, ग्राहकाच्या क्लायंट ऍप्लिकेशनला याबद्दल सूचित करा. सर्वसाधारणपणे, अशी अनेक प्रकरणे आहेत जिथे अशी यंत्रणा उपयुक्त ठरेल.

उत्पादन स्वतः

संदेशवहन यंत्रणा तयार करा. जलद, विश्वासार्ह, हमी वितरणासह, लवचिकपणे संदेश शोधण्याच्या क्षमतेसह. यंत्रणेवर आधारित, 1C ऍप्लिकेशन्समध्ये चालणारा मेसेंजर (संदेश, व्हिडिओ कॉल) कार्यान्वित करा.

प्रणाली क्षैतिजरित्या स्केलेबल करण्यासाठी डिझाइन करा. नोड्सची संख्या वाढवून वाढणारा भार कव्हर करणे आवश्यक आहे.

अंमलबजावणी

आम्ही SV चा सर्व्हर भाग थेट 1C:Enterprise प्लॅटफॉर्ममध्ये समाकलित न करण्याचे ठरवले आहे, परंतु ते स्वतंत्र उत्पादन म्हणून कार्यान्वित करायचे आहे, ज्याचा API 1C ऍप्लिकेशन सोल्यूशन्सच्या कोडमधून कॉल केला जाऊ शकतो. हे बर्‍याच कारणांसाठी केले गेले, त्यापैकी मुख्य म्हणजे मला वेगवेगळ्या 1C अनुप्रयोगांमध्ये (उदाहरणार्थ, ट्रेड मॅनेजमेंट आणि अकाउंटिंग दरम्यान) संदेशांची देवाणघेवाण करणे शक्य करायचे होते. वेगवेगळे 1C अॅप्लिकेशन 1C च्या वेगवेगळ्या आवृत्त्यांवर चालू शकतात: एंटरप्राइज प्लॅटफॉर्म, वेगवेगळ्या सर्व्हरवर स्थित असू शकतात इ. अशा परिस्थितीत, 1C इंस्टॉलेशन्सच्या “बाजूला” स्थित स्वतंत्र उत्पादन म्हणून SV ची अंमलबजावणी हा इष्टतम उपाय आहे.

म्हणून, आम्ही एक वेगळे उत्पादन म्हणून SV बनवण्याचा निर्णय घेतला. आम्ही शिफारस करतो की छोट्या कंपन्यांनी आम्ही आमच्या क्लाउडमध्ये (wss://1cdialog.com) स्थापित केलेला CB सर्व्हर वापरावा जेणेकरून सर्व्हरची स्थानिक स्थापना आणि कॉन्फिगरेशनशी संबंधित ओव्हरहेड खर्च टाळण्यासाठी. मोठ्या ग्राहकांना त्यांच्या सुविधांवर त्यांचे स्वतःचे CB सर्व्हर स्थापित करण्याचा सल्ला दिला जाऊ शकतो. आम्ही आमच्या क्लाउड SaaS उत्पादनामध्ये समान दृष्टीकोन वापरला 1cताजे - हे क्लायंटच्या साइटवर स्थापनेसाठी मोठ्या प्रमाणात उत्पादित उत्पादन म्हणून तयार केले जाते आणि आमच्या क्लाउडमध्ये देखील तैनात केले जाते https://1cfresh.com/.

अनुप्रयोग

लोड आणि फॉल्ट टॉलरन्स वितरीत करण्यासाठी, आम्ही एक Java ऍप्लिकेशन नाही तर त्यांच्या समोर लोड बॅलन्सरसह अनेक उपयोजित करू. तुम्हाला एखादा संदेश नोडपासून नोडवर हस्तांतरित करायचा असल्यास, Hazelcast मध्ये प्रकाशित/सदस्यता घ्या.

क्लायंट आणि सर्व्हरमधील संप्रेषण वेबसॉकेटद्वारे होते. हे रिअल-टाइम सिस्टमसाठी योग्य आहे.

वितरित कॅशे

आम्ही Redis, Hazelcast आणि Ehcache दरम्यान निवडले. हे 2015 आहे. रेडिसने नुकताच एक नवीन क्लस्टर जारी केला (खूप नवीन, धडकी भरवणारा), तेथे सेंटिनेल आहे ज्यामध्ये बरेच निर्बंध आहेत. क्लस्टरमध्ये कसे एकत्र करायचे हे Ehcache ला माहित नाही (ही कार्यक्षमता नंतर दिसून आली). आम्ही हेझलकास्ट 3.4 सह प्रयत्न करण्याचा निर्णय घेतला.
हेझेलकास्ट बॉक्सच्या बाहेर क्लस्टरमध्ये एकत्र केले जाते. सिंगल नोड मोडमध्ये, ते फारसे उपयुक्त नाही आणि फक्त कॅशे म्हणून वापरले जाऊ शकते - डिस्कवर डेटा कसा डंप करायचा हे माहित नाही, जर तुम्ही एकमेव नोड गमावला तर तुम्ही डेटा गमावाल. आम्ही अनेक Hazelcasts तैनात करतो, ज्या दरम्यान आम्ही गंभीर डेटाचा बॅकअप घेतो. आम्ही कॅशेचा बॅकअप घेत नाही - आम्हाला काही हरकत नाही.

आमच्यासाठी, हेझेलकास्ट आहे:

वापरकर्ता सत्रांचे संचयन. प्रत्येक वेळी एका सत्रासाठी डेटाबेसमध्ये जाण्यासाठी बराच वेळ लागतो, म्हणून आम्ही सर्व सत्रे Hazelcast मध्ये ठेवतो.
कॅशे. आपण वापरकर्ता प्रोफाइल शोधत असल्यास, कॅशे तपासा. एक नवीन संदेश लिहिला - तो कॅशेमध्ये ठेवा.
अनुप्रयोग उदाहरणांमधील संवादासाठी विषय. नोड एक इव्हेंट व्युत्पन्न करतो आणि तो Hazelcast विषयामध्ये ठेवतो. या विषयावर सदस्यत्व घेतलेले इतर अनुप्रयोग नोड इव्हेंट प्राप्त करतात आणि त्यावर प्रक्रिया करतात.
क्लस्टर लॉक. उदाहरणार्थ, आम्ही एक अद्वितीय की वापरून चर्चा तयार करतो (1C डेटाबेसमध्ये सिंगलटन चर्चा):

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

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

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

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

आम्ही तपासले की तेथे कोणतेही चॅनेल नाही. आम्ही लॉक घेतला, ते पुन्हा तपासले आणि ते तयार केले. लॉक घेतल्यानंतर तुम्ही लॉक तपासले नाही, तर त्या क्षणी दुसर्‍या थ्रेडने देखील तपासण्याची शक्यता आहे आणि आता तीच चर्चा तयार करण्याचा प्रयत्न करेल - परंतु ती आधीच अस्तित्वात आहे. तुम्ही सिंक्रोनाइझ केलेले किंवा नियमित जावा लॉक वापरून लॉक करू शकत नाही. डेटाबेसद्वारे - ते मंद आहे, आणि डेटाबेससाठी हे खेदजनक आहे; हेझेलकास्टद्वारे - आपल्याला तेच हवे आहे.

DBMS निवडत आहे

आमच्याकडे PostgreSQL सह काम करण्याचा आणि या DBMS च्या डेव्हलपर्ससोबत सहयोग करण्याचा व्यापक आणि यशस्वी अनुभव आहे.

पोस्टग्रेएसक्यूएल क्लस्टरसह हे सोपे नाही - आहे XL, XC, सायटस, परंतु सर्वसाधारणपणे हे NoSQL नाहीत जे बॉक्सच्या बाहेर मोजतात. आम्ही NoSQL ला मुख्य स्टोरेज म्हणून मानले नाही; आम्ही हेझेलकास्ट घेतले ते पुरेसे आहे, ज्यावर आम्ही यापूर्वी काम केले नव्हते.

तुम्हाला रिलेशनल डेटाबेस स्केल करण्याची आवश्यकता असल्यास, याचा अर्थ शार्डिंग. तुम्हाला माहिती आहेच, शार्डिंगसह आम्ही डेटाबेस वेगळ्या भागांमध्ये विभागतो जेणेकरून प्रत्येकाला वेगळ्या सर्व्हरवर ठेवता येईल.

आमच्‍या शार्डिंगच्‍या पहिल्‍या आवृत्‍तीने आमच्‍या अॅप्लिकेशनच्‍या प्रत्‍येक सारणीच्‍या वेगवेगळ्या सर्व्हरवर वेगवेगळ्या प्रमाणात वितरीत करण्‍याची क्षमता गृहीत धरली. सर्व्हर A वर बरेच संदेश आहेत - कृपया, या सारणीचा काही भाग सर्व्हर B वर हलवू या. हा निर्णय केवळ अकाली ऑप्टिमायझेशनबद्दल ओरडत होता, म्हणून आम्ही स्वतःला बहु-भाडेकरू दृष्टिकोनापर्यंत मर्यादित ठेवण्याचा निर्णय घेतला.

आपण बहु-भाडेकरू बद्दल वाचू शकता, उदाहरणार्थ, वेबसाइटवर साइटस डेटा.

SV मध्ये अॅप्लिकेशन आणि सब्सक्राइबर या संकल्पना आहेत. अनुप्रयोग म्हणजे व्यवसाय अनुप्रयोगाची विशिष्ट स्थापना, जसे की ERP किंवा लेखा, त्याचे वापरकर्ते आणि व्यवसाय डेटा. सदस्य ही एक संस्था किंवा व्यक्ती आहे जिच्या वतीने SV सर्व्हरमध्ये अर्ज नोंदणीकृत आहे. एका सदस्याकडे अनेक अनुप्रयोग नोंदणीकृत असू शकतात आणि हे अनुप्रयोग एकमेकांशी संदेशांची देवाणघेवाण करू शकतात. आमच्या सिस्टममध्ये ग्राहक भाडेकरू झाला. अनेक सदस्यांचे संदेश एका भौतिक डेटाबेसमध्ये असू शकतात; जर आपण पाहतो की एखाद्या ग्राहकाने भरपूर रहदारी निर्माण करण्यास सुरुवात केली आहे, तर आम्ही त्यास वेगळ्या भौतिक डेटाबेसवर (किंवा स्वतंत्र डेटाबेस सर्व्हर) हलवतो.

आमच्याकडे एक मुख्य डेटाबेस आहे जिथे सर्व ग्राहक डेटाबेसच्या स्थानाबद्दल माहितीसह राउटिंग टेबल संग्रहित केले जाते.

मुख्य डेटाबेसला अडथळे येण्यापासून रोखण्यासाठी, आम्ही राउटिंग टेबल (आणि इतर वारंवार आवश्यक असलेला डेटा) कॅशेमध्ये ठेवतो.

जर सबस्क्राइबरचा डेटाबेस मंद होण्यास सुरुवात झाली, तर आम्ही ते विभाजनांमध्ये कट करू. आम्ही वापरत असलेल्या इतर प्रकल्पांवर pg_pathman.

वापरकर्ता संदेश गमावणे वाईट असल्याने, आम्ही प्रतिकृतीसह आमचे डेटाबेस राखतो. सिंक्रोनस आणि एसिंक्रोनस प्रतिकृतींचे संयोजन आपल्याला मुख्य डेटाबेस गमावल्यास स्वतःचा विमा काढण्याची परवानगी देते. प्राथमिक डेटाबेस आणि त्याची सिंक्रोनस प्रतिकृती एकाच वेळी अयशस्वी झाल्यासच संदेशाचे नुकसान होईल.

सिंक्रोनस प्रतिकृती हरवल्यास, अतुल्यकालिक प्रतिकृती समकालिक होते.
मुख्य डेटाबेस हरवल्यास, समकालिक प्रतिकृती मुख्य डेटाबेस बनते आणि असिंक्रोनस प्रतिकृती समकालिक प्रतिकृती बनते.

शोधासाठी लवचिक शोधा

इतर गोष्टींबरोबरच, SV देखील एक मेसेंजर असल्याने, त्याला अचूक जुळणी वापरून, आकारविज्ञान लक्षात घेऊन जलद, सोयीस्कर आणि लवचिक शोध आवश्यक आहे. आम्ही चाक पुन्हा शोधण्याचा आणि लायब्ररीवर आधारित मुक्त शोध इंजिन Elasticsearch वापरण्याचे ठरवले. लुसीन. ऍप्लिकेशन नोड्स अयशस्वी झाल्यास समस्या दूर करण्यासाठी आम्ही क्लस्टर (मास्टर – डेटा – डेटा) मध्ये Elasticsearch देखील तैनात करतो.

गिथब वर आम्हाला सापडले रशियन मॉर्फोलॉजी प्लगइन Elasticsearch साठी आणि ते वापरा. इलास्टिकसर्च इंडेक्समध्ये आम्ही शब्द मूळ (जे प्लगइन ठरवते) आणि एन-ग्राम साठवतो. वापरकर्ता शोधण्यासाठी मजकूर प्रविष्ट करतो तेव्हा, आम्ही N-grams मध्ये टाइप केलेला मजकूर शोधतो. इंडेक्समध्ये सेव्ह केल्यावर, "टेक्स्ट" हा शब्द खालील एन-ग्रॅममध्ये विभागला जाईल:

[ते, tek, tex, मजकूर, मजकूर, ek, ex, ext, मजकूर, ks, kst, ksty, st, sty, you],

आणि "मजकूर" शब्दाचे मूळ देखील संरक्षित केले जाईल. हा दृष्टिकोन तुम्हाला शब्दाच्या सुरुवातीला, मध्यभागी आणि शेवटी शोधण्याची परवानगी देतो.

मोठे चित्र

लेखाच्या सुरुवातीपासून चित्राची पुनरावृत्ती करा, परंतु स्पष्टीकरणांसह:

इंटरनेटवर बॅलन्सर उघड; आमच्याकडे nginx आहे, ते कोणतेही असू शकते.
Java ऍप्लिकेशन्स हेझेलकास्ट द्वारे एकमेकांशी संवाद साधतात.
वेब सॉकेटसह कार्य करण्यासाठी आम्ही वापरतो नेटी.
Java ऍप्लिकेशन Java 8 मध्ये लिहिलेले आहे आणि त्यात बंडल आहेत ओएसजी. योजनांमध्ये Java 10 मध्ये स्थलांतर आणि मॉड्यूलमध्ये संक्रमण समाविष्ट आहे.

विकास आणि चाचणी

SV विकसित करण्याच्या आणि चाचणीच्या प्रक्रियेत, आम्ही वापरत असलेल्या उत्पादनांची अनेक मनोरंजक वैशिष्ट्ये आमच्याकडे आली.

लोड चाचणी आणि मेमरी लीक

प्रत्येक एसव्ही रिलीझमध्ये लोड चाचणी समाविष्ट असते. हे यशस्वी होते जेव्हा:

चाचणीने बरेच दिवस काम केले आणि कोणतीही सेवा अपयशी ठरली नाही
मुख्य ऑपरेशन्ससाठी प्रतिसाद वेळ आरामदायक थ्रेशोल्डपेक्षा जास्त नाही
मागील आवृत्तीच्या तुलनेत कार्यप्रदर्शन खराब होणे 10% पेक्षा जास्त नाही

आम्ही चाचणी डेटाबेस डेटासह भरतो - हे करण्यासाठी, आम्ही उत्पादन सर्व्हरवरून सर्वात सक्रिय सदस्यांबद्दल माहिती प्राप्त करतो, त्याची संख्या 5 ने गुणाकार करतो (संदेशांची संख्या, चर्चा, वापरकर्ते) आणि अशा प्रकारे चाचणी करतो.

आम्ही तीन कॉन्फिगरेशनमध्ये परस्परसंवाद प्रणालीची लोड चाचणी करतो:

तणाव चाचणी
फक्त कनेक्शन
सदस्य नोंदणी

तणाव चाचणी दरम्यान, आम्ही अनेक शंभर थ्रेड्स लॉन्च करतो आणि ते न थांबता सिस्टम लोड करतात: संदेश लिहिणे, चर्चा तयार करणे, संदेशांची सूची प्राप्त करणे. आम्ही सामान्य वापरकर्त्यांच्या क्रियांचे अनुकरण करतो (माझ्या न वाचलेल्या संदेशांची सूची मिळवा, एखाद्याला लिहा) आणि सॉफ्टवेअर सोल्यूशन्स (वेगळ्या कॉन्फिगरेशनचे पॅकेज प्रसारित करा, अॅलर्टवर प्रक्रिया करा).

उदाहरणार्थ, तणाव चाचणीचा हा भाग असा दिसतो:

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

"केवळ कनेक्शन" परिस्थिती एका कारणासाठी दिसून आली. अशी परिस्थिती आहे: वापरकर्त्यांनी सिस्टम कनेक्ट केले आहे, परंतु अद्याप ते सामील झालेले नाहीत. प्रत्येक वापरकर्ता सकाळी 09:00 वाजता संगणक चालू करतो, सर्व्हरशी कनेक्शन स्थापित करतो आणि शांत राहतो. हे लोक धोकादायक आहेत, त्यापैकी बरेच आहेत - त्यांच्याकडे फक्त PING/PONG ही पॅकेजेस आहेत, परंतु ते सर्व्हरशी कनेक्शन ठेवतात (ते ते चालू ठेवू शकत नाहीत - नवीन संदेश असल्यास काय होईल). चाचणी अशा परिस्थितीचे पुनरुत्पादन करते जेथे अशा मोठ्या संख्येने वापरकर्ते अर्ध्या तासात सिस्टममध्ये लॉग इन करण्याचा प्रयत्न करतात. हे तणाव चाचणीसारखेच आहे, परंतु त्याचे लक्ष या पहिल्या इनपुटवर तंतोतंत आहे - जेणेकरून कोणतेही अपयश येत नाहीत (एखादी व्यक्ती सिस्टम वापरत नाही आणि ती आधीच बंद पडते - काहीतरी वाईट विचार करणे कठीण आहे).

ग्राहक नोंदणी स्क्रिप्ट पहिल्या लॉन्चपासून सुरू होते. आम्ही एक तणाव चाचणी घेतली आणि पत्रव्यवहारादरम्यान प्रणालीची गती कमी होणार नाही याची खात्री होती. परंतु वापरकर्ते आले आणि कालबाह्य झाल्यामुळे नोंदणी अयशस्वी होऊ लागली. नोंदणी करताना आम्ही वापरले / देव / यादृच्छिक, जे सिस्टमच्या एन्ट्रॉपीशी संबंधित आहे. पुरेशी एन्ट्रॉपी जमा करण्यासाठी सर्व्हरकडे वेळ नव्हता आणि जेव्हा नवीन SecureRandom ची विनंती केली गेली तेव्हा ते दहा सेकंदांसाठी गोठले. या परिस्थितीतून बाहेर पडण्याचे अनेक मार्ग आहेत, उदाहरणार्थ: कमी सुरक्षित /dev/urandom वर स्विच करा, एक विशेष बोर्ड स्थापित करा जो एंट्रॉपी निर्माण करतो, यादृच्छिक संख्या आगाऊ तयार करा आणि त्यांना पूलमध्ये संग्रहित करा. आम्ही पूलमधील समस्या तात्पुरती बंद केली, परंतु तेव्हापासून आम्ही नवीन सदस्यांची नोंदणी करण्यासाठी स्वतंत्र चाचणी चालवत आहोत.

आम्ही लोड जनरेटर म्हणून वापरतो जेमीटर. वेबसॉकेटसह कसे कार्य करावे हे माहित नाही; त्याला प्लगइन आवश्यक आहे. "jmeter websocket" क्वेरीसाठी शोध परिणामांमध्ये पहिले आहेत: BlazeMeter मधील लेख, जे शिफारस करतात Maciej Zaleski द्वारे प्लगइन.

तिथूनच आम्ही सुरुवात करण्याचा निर्णय घेतला.

गंभीर चाचणी सुरू केल्यानंतर, आम्हाला आढळले की JMeter मेमरी लीक करू लागला.

प्लगइन ही एक वेगळी मोठी कथा आहे; 176 तार्यांसह, त्यात गिथबवर 132 काटे आहेत. लेखकाने स्वत: 2015 पासून त्यास वचनबद्ध केले नाही (आम्ही ते 2015 मध्ये घेतले, नंतर त्याने शंका निर्माण केली नाही), मेमरी लीकशी संबंधित अनेक गिथब समस्या, 7 अनक्लोज्ड पुल विनंत्या.
तुम्ही हे प्लगइन वापरून लोड चाचणी करण्याचे ठरविल्यास, कृपया खालील चर्चांकडे लक्ष द्या:

मल्टी-थ्रेडेड वातावरणात, नियमित लिंक्डलिस्ट वापरली गेली आणि त्याचा परिणाम झाला NPE रनटाइम मध्ये. हे 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).

हे गिथहबवरील एक आहे. आम्ही काय केले:

घेतले आहे Elyran Kogan काटा (@elyrank) - ते 1 आणि 3 समस्यांचे निराकरण करते
समस्या सोडवली 2
9.2.14 ते 9.3.12 पर्यंत जेट्टी अद्यतनित केली
ThreadLocal मध्ये SimpleDateFormat गुंडाळले; SimpleDateFormat थ्रेड-सेफ नाही, ज्यामुळे रनटाइमवर NPE होते
दुसरी मेमरी गळती निश्चित केली (डिस्कनेक्ट झाल्यावर कनेक्शन चुकीच्या पद्धतीने बंद केले गेले)

आणि तरीही ते वाहते!

स्मरणशक्ती एका दिवसात नाही तर दोन वेळा संपू लागली. तेथे अजिबात वेळ शिल्लक नव्हता, म्हणून आम्ही कमी धागे सुरू करण्याचा निर्णय घेतला, परंतु चार एजंट्सवर. हे किमान एक आठवडा पुरेसे असावे.

दोन दिवस झाले...

आता Hazelcast मेमरी संपत आहे. नोंदींनी दर्शविले की काही दिवसांच्या चाचणीनंतर, हेझेलकास्टने स्मरणशक्तीच्या कमतरतेबद्दल तक्रार करण्यास सुरवात केली आणि काही काळानंतर क्लस्टर वेगळे झाले आणि नोड्स एक एक करून मरत राहिले. आम्ही JVisualVM ला हेझेलकास्टशी जोडले आणि एक "उगवणारा करवत" पाहिला - त्याला नियमितपणे GC म्हटले जाते, परंतु मेमरी साफ करता आली नाही.

हे निष्पन्न झाले की hazelcast 3.4 मध्ये, नकाशा / multiMap (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 मध्ये किंवा Hazelcast मध्ये ठेवू शकत नाही. , परंतु सर्वात वाईट गोष्ट म्हणजे जर तुम्हाला दोन डेटाबेसमधील डेटा एकामध्ये एकत्र करायचा असेल (उदाहरणार्थ, या सदस्यांसाठी एक डेटाबेस पुरेसा आहे हे ठरवणे). तुम्ही Hazelcast मध्ये अनेक AtomicLongs जोडू शकता आणि तेथे काउंटर ठेवू शकता, त्यानंतर नवीन आयडी मिळवण्याची कामगिरी म्हणजे incrementAndGet तसेच Hazelcast ला विनंती करण्याची वेळ. परंतु हेझेलकास्टमध्ये काहीतरी अधिक इष्टतम आहे - FlakeIdGenerator. प्रत्येक क्लायंटशी संपर्क साधताना, त्यांना एक आयडी श्रेणी दिली जाते, उदाहरणार्थ, पहिली - 1 ते 10 पर्यंत, दुसरी - 000 ते 10 पर्यंत आणि असेच. आता क्लायंट त्याला जारी केलेली श्रेणी संपेपर्यंत नवीन अभिज्ञापक स्वतः जारी करू शकतो. हे त्वरीत कार्य करते, परंतु जेव्हा तुम्ही अनुप्रयोग (आणि Hazelcast क्लायंट) रीस्टार्ट करता, तेव्हा एक नवीन क्रम सुरू होतो - म्हणून वगळले जाते, इ. याव्यतिरिक्त, विकासकांना खरोखरच ID पूर्णांक का आहेत हे समजत नाही, परंतु ते इतके विसंगत आहेत. आम्ही सर्व काही मोजले आणि UUID वर स्विच केले.

तसे, ज्यांना ट्विटरसारखे व्हायचे आहे त्यांच्यासाठी अशी स्नोकास्ट लायब्ररी आहे - हे हेझेलकास्टच्या शीर्षस्थानी स्नोफ्लेकची अंमलबजावणी आहे. तुम्ही ते येथे पाहू शकता:

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 यापुढे अस्तित्वात नाही.

डाउनटाइमशिवाय नवीन 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 कसे अद्यतनित करावे? नोड-बाय-नोड अपडेट दरम्यान Hazelcast नवीन 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 मध्ये अनुक्रमित करतो आणि Hazelcast मध्ये सेव्ह करतो. Hazelcast ला आमच्या वर्गांची रचना माहित असणे आवश्यक नाही आणि आम्ही डाउनटाइमशिवाय अपडेट करू शकतो. डोमेन ऑब्जेक्ट्सची आवृत्ती अनुप्रयोगाद्वारे नियंत्रित केली जाते. अनुप्रयोगाच्या वेगवेगळ्या आवृत्त्या एकाच वेळी चालू असू शकतात आणि जेव्हा नवीन अनुप्रयोग नवीन फील्डसह ऑब्जेक्ट्स लिहितो तेव्हा परिस्थिती शक्य आहे, परंतु जुन्याला अद्याप या फील्डबद्दल माहिती नाही. आणि त्याच वेळी, नवीन अनुप्रयोग जुन्या अनुप्रयोगाद्वारे लिहिलेल्या वस्तू वाचतो ज्यामध्ये नवीन फील्ड नाहीत. आम्ही ऍप्लिकेशनमध्ये अशा परिस्थिती हाताळतो, परंतु साधेपणासाठी आम्ही फील्ड बदलत नाही किंवा हटवत नाही, आम्ही फक्त नवीन फील्ड जोडून वर्ग वाढवतो.

आम्ही उच्च कार्यक्षमता कशी सुनिश्चित करतो

हेझेलकास्टच्या चार ट्रिप - चांगल्या, डेटाबेससाठी दोन - वाईट

डेटाबेसवर जाण्यापेक्षा डेटासाठी कॅशेवर जाणे नेहमीच चांगले असते, परंतु आपण न वापरलेले रेकॉर्ड देखील संग्रहित करू इच्छित नाही. विकासाच्या शेवटच्या टप्प्यापर्यंत काय कॅशे करायचे याचा निर्णय आम्ही सोडतो. जेव्हा नवीन कार्यक्षमता कोडेड केली जाते, तेव्हा आम्ही PostgreSQL (log_min_duration_statement to 0) मधील सर्व प्रश्नांचे लॉगिंग चालू करतो आणि 20 मिनिटांसाठी लोड चाचणी चालवतो. गोळा केलेले लॉग वापरून, pgFouine आणि pgBadger सारख्या उपयुक्तता विश्लेषणात्मक अहवाल तयार करू शकतात. अहवालांमध्ये, आम्ही प्रामुख्याने हळू आणि वारंवार येणाऱ्या क्वेरी शोधतो. धीमे प्रश्नांसाठी, आम्ही एक अंमलबजावणी योजना तयार करतो (स्पष्टीकरण) आणि अशा क्वेरीला गती दिली जाऊ शकते का याचे मूल्यांकन करतो. समान इनपुट डेटासाठी वारंवार विनंत्या कॅशेमध्ये चांगल्या प्रकारे बसतात. आम्ही क्वेरी "फ्लॅट" ठेवण्याचा प्रयत्न करतो, प्रत्येक क्वेरीसाठी एक टेबल.

शोषण

ऑनलाइन सेवा म्हणून SV 2017 च्या वसंत ऋतूमध्ये कार्यान्वित करण्यात आली आणि एक वेगळे उत्पादन म्हणून, SV नोव्हेंबर 2017 मध्ये (त्यावेळी बीटा आवृत्ती स्थितीत) रिलीज करण्यात आला.

ऑपरेशनच्या एका वर्षाहून अधिक कालावधीत, सीबी ऑनलाइन सेवेच्या कार्यामध्ये कोणतीही गंभीर समस्या आली नाही. द्वारे आम्ही ऑनलाइन सेवेचे निरीक्षण करतो झब्बीक्स, पासून गोळा आणि तैनात बांबू.

SV सर्व्हर वितरण मूळ पॅकेजेसच्या स्वरूपात पुरवले जाते: RPM, DEB, MSI. तसेच विंडोजसाठी आम्ही सिंगल EXE च्या स्वरूपात एकच इंस्टॉलर प्रदान करतो जो सर्व्हर, हेझेलकास्ट आणि इलास्टिकसर्च एका मशीनवर स्थापित करतो. आम्ही सुरुवातीला इंस्टॉलेशनच्या या आवृत्तीला “डेमो” आवृत्ती म्हणून संदर्भित केले, परंतु आता हे स्पष्ट झाले आहे की हा सर्वात लोकप्रिय उपयोजन पर्याय आहे.

स्त्रोत: www.habr.com

आम्ही 1C साठी उच्च-लोड स्केलेबल सेवा कशी आणि का लिहिली: Enterprise: Java, PostgreSQL, Hazelcast