🥇हामीले 1C को लागि उच्च-लोड स्केलेबल सेवा कसरी र किन लेख्यौं: इन्टरप्राइज: Java, PostgreSQL, Hazelcast

यस लेखमा हामी कसरी र किन विकास भयो भन्ने बारे कुरा गर्नेछौं अन्तरक्रिया प्रणाली - क्लाइन्ट एप्लिकेसनहरू र 1C: इन्टरप्राइज सर्भरहरू बीच जानकारी स्थानान्तरण गर्ने एक संयन्त्र - कार्य सेटिङदेखि वास्तुकला र कार्यान्वयन विवरणहरू मार्फत सोच्न।

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

SV वितरित भण्डारण प्रयोग गर्दछ हेजलकास्ट र खोज इन्जिन Elasticsearch। हामी जाभाको बारेमा पनि कुरा गर्नेछौं र कसरी हामी तेर्सो रूपमा PostgreSQL मापन गर्छौं।

समस्याको गठन

हामीले अन्तरक्रिया प्रणाली किन सिर्जना गर्यौं भन्ने कुरा स्पष्ट गर्न, म तपाईंलाई 1C मा व्यावसायिक अनुप्रयोगहरूको विकास कसरी काम गर्छ भन्ने बारे थोरै बताउँछु।

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

ग्राहक-सर्भर विकास प्रतिमान

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/.

अनुप्रयोग

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

ग्राहक र सर्भर बीचको सञ्चार वेबसकेट मार्फत हुन्छ। यो वास्तविक-समय प्रणालीहरूको लागि राम्रोसँग उपयुक्त छ।

वितरित क्यास

हामीले Redis, Hazelcast र Ehcache बीच रोज्यौं। यो 2015 हो। रेडिसले भर्खरै नयाँ क्लस्टर जारी गर्‍यो (धेरै नयाँ, डरलाग्दो), त्यहाँ धेरै प्रतिबन्धहरूको साथ सेन्टिनेल छ। Ehcache लाई क्लस्टरमा कसरी जम्मा गर्ने थाहा छैन (यो कार्यक्षमता पछि देखा पर्यो)। हामीले Hazelcast 3.4 को साथ प्रयास गर्ने निर्णय गर्यौं।
Hazelcast बक्स बाहिर एक क्लस्टर मा भेला गरिएको छ। एकल नोड मोडमा, यो धेरै उपयोगी छैन र केवल क्यासको रूपमा प्रयोग गर्न सकिन्छ - यसलाई डिस्कमा डाटा कसरी डम्प गर्ने थाहा छैन, यदि तपाईंले मात्र नोड गुमाउनुभयो भने, तपाईंले डाटा गुमाउनुहुन्छ। हामी धेरै Hazelcasts तैनात गर्छौं, जसको बीचमा हामी महत्वपूर्ण डेटा ब्याकअप गर्छौं। हामी क्यास ब्याकअप गर्दैनौं - हामीलाई कुनै आपत्ति छैन।

हाम्रो लागि, Hazelcast हो:

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

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

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

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

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

हामीले जाँच गर्यौं कि त्यहाँ कुनै च्यानल छैन। हामीले लक लियौं, यसलाई फेरि जाँच्यौं, र यसलाई सिर्जना गर्यौं। यदि तपाईंले लक लिइसकेपछि लक जाँच गर्नुभएन भने, त्यस समयमा अर्को थ्रेडले पनि जाँच गरेको र अब उही छलफल सिर्जना गर्ने प्रयास गर्ने मौका छ - तर यो पहिले नै अवस्थित छ। तपाइँ सिङ्क्रोनाइज्ड वा नियमित जाभा लक प्रयोग गरेर लक गर्न सक्नुहुन्न। डाटाबेस मार्फत - यो ढिलो छ, र यो डाटाबेसको लागि दयाको कुरा हो; Hazelcast मार्फत - त्यो तपाईलाई चाहिन्छ।

DBMS छनौट गर्दै

हामीसँग PostgreSQL सँग काम गर्ने र यस DBMS को विकासकर्ताहरूसँग सहकार्य गर्ने व्यापक र सफल अनुभव छ।

PostgreSQL क्लस्टरको साथ यो सजिलो छैन - त्यहाँ छ XL, XC, सिटस, तर सामान्यतया यी NoSQL हरू होइनन् जुन बाकस बाहिर मापन हुन्छ। हामीले NoSQL लाई मुख्य भण्डारणको रूपमा विचार गरेनौं; यो पर्याप्त थियो कि हामीले Hazelcast लियौं, जुन हामीले पहिले काम गरेका थिएनौं।

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

हाम्रो शार्डिङको पहिलो संस्करणले हाम्रो अनुप्रयोगको प्रत्येक तालिकालाई विभिन्न सर्भरहरूमा विभिन्न अनुपातमा वितरण गर्ने क्षमतालाई ग्रहण गर्‍यो। त्यहाँ सर्भर A मा धेरै सन्देशहरू छन् - कृपया, यो तालिकाको भागलाई सर्भर B मा सारौं। यो निर्णयले समयभन्दा पहिले अप्टिमाइजेसनको बारेमा चिच्यायो, त्यसैले हामीले आफूलाई बहु-भाडादार दृष्टिकोणमा सीमित गर्ने निर्णय गर्यौं।

तपाईं बहु-भाडादार बारे पढ्न सक्नुहुन्छ, उदाहरणका लागि, वेबसाइटमा साइटस डाटा.

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

हामीसँग एक मुख्य डाटाबेस छ जहाँ सबै ग्राहक डाटाबेसहरूको स्थानको बारेमा जानकारीको साथ रूटिङ तालिका भण्डार गरिएको छ।

मुख्य डाटाबेसलाई अड्चन हुनबाट रोक्नको लागि, हामी क्यासमा रूटिङ टेबल (र अन्य बारम्बार आवश्यक डाटा) राख्छौं।

यदि ग्राहकको डाटाबेस सुस्त हुन थाल्छ भने, हामी यसलाई भित्र विभाजनहरूमा काट्नेछौं। हामीले प्रयोग गर्ने अन्य परियोजनाहरूमा pg_pathman.

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

यदि सिंक्रोनस प्रतिकृति हराएको छ भने, एसिन्क्रोनस प्रतिकृति सिंक्रोनस हुन्छ।
यदि मुख्य डाटाबेस हरायो भने, सिंक्रोनस प्रतिकृति मुख्य डाटाबेस बन्छ, र एसिन्क्रोनस प्रतिकृति सिंक्रोनस प्रतिकृति हुन्छ।

खोजको लागि लोचदार खोज

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

Github मा हामीले भेट्टायौं रूसी आकार विज्ञान प्लगइन Elasticsearch को लागि र यसलाई प्रयोग गर्नुहोस्। इलास्टिकसर्च इन्डेक्समा हामी शब्दको जरा (जसलाई प्लगइनले निर्धारण गर्छ) र एन-ग्रामहरू भण्डार गर्छौं। प्रयोगकर्ताले खोजी गर्न पाठ प्रविष्ट गर्दा, हामी N-grams बीच टाइप गरिएको पाठ खोज्छौं। अनुक्रमणिकामा बचत गर्दा, शब्द "पाठहरू" निम्न एन-ग्रामहरूमा विभाजित हुनेछ:

[ती, टेक, टेक्स, टेक्स्ट, टेक्स्ट, एक, एक्स, एक्सट, टेक्स्ट, केएस, केएसटी, केस्टी, स्ट, स्टाइ, यू],

र शब्द "पाठ" को मूल पनि सुरक्षित गरिनेछ। यो दृष्टिकोणले तपाईंलाई सुरुमा, बीचमा र शब्दको अन्त्यमा खोजी गर्न अनुमति दिन्छ।

ठूलो तस्वीर

लेखको सुरुबाट चित्र दोहोर्याउनुहोस्, तर स्पष्टीकरणको साथ:

ब्यालेन्सर इन्टरनेटमा उजागर; हामीसँग nginx छ, यो कुनै पनि हुन सक्छ।
Java अनुप्रयोग उदाहरणहरू Hazelcast मार्फत एक-अर्कासँग सञ्चार गर्छन्।
वेब सकेट संग काम गर्न को लागी हामी प्रयोग गर्दछौं नेट्टी.
Java अनुप्रयोग Java 8 मा लेखिएको छ र बन्डलहरू समावेश गर्दछ OSGi। योजनाहरूमा जाभा 10 मा माइग्रेसन र मोड्युलहरूमा संक्रमण समावेश छ।

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

SV को विकास र परीक्षणको प्रक्रियामा, हामीले प्रयोग गर्ने उत्पादनहरूको धेरै रोचक सुविधाहरू भेट्यौं।

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

प्रत्येक SV रिलीजको रिलीजमा लोड परीक्षण समावेश छ। यो सफल हुन्छ जब:

परीक्षणले धेरै दिन काम गर्यो र त्यहाँ कुनै सेवा विफलताहरू थिएनन्
प्रमुख कार्यहरूको लागि प्रतिक्रिया समय एक आरामदायक थ्रेसहोल्ड भन्दा बढी थिएन
अघिल्लो संस्करणको तुलनामा प्रदर्शन गिरावट 10% भन्दा बढी छैन

हामी डेटाको साथ परीक्षण डाटाबेस भर्छौं - यो गर्नको लागि, हामीले उत्पादन सर्भरबाट सबैभन्दा सक्रिय सदस्यहरूको बारेमा जानकारी प्राप्त गर्छौं, यसको संख्याहरू 5 (सन्देशहरू, छलफलहरू, प्रयोगकर्ताहरूको संख्या) द्वारा गुणा गर्नुहोस् र त्यसरी परीक्षण गर्नुहोस्।

हामी तीन कन्फिगरेसनहरूमा अन्तरक्रिया प्रणालीको लोड परीक्षण गर्छौं:

तनाव परीक्षण
जडानहरू मात्र
सदस्य दर्ता

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

उदाहरण को लागी, यो तनाव परीक्षण को भाग जस्तो देखिन्छ:

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

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

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

हामी लोड जेनरेटरको रूपमा प्रयोग गर्छौं JMeter। वेबसकेटसँग कसरी काम गर्ने थाहा छैन; यसलाई प्लगइन चाहिन्छ। क्वेरी "jmeter websocket" को लागि खोज परिणामहरूमा पहिलो हो: BlazeMeter बाट लेखहरू, जसले सिफारिस गर्दछ Maciej Zaleski द्वारा प्लगइन.

त्यहीँबाट हामीले सुरु गर्ने निर्णय गर्यौं।

गम्भीर परीक्षण सुरु गरेपछि लगभग तुरुन्तै, हामीले पत्ता लगायौं कि JMeter ले मेमोरी लीक गर्न थाल्यो।

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

बहु-थ्रेड गरिएको वातावरणमा, एक नियमित LinkedList प्रयोग गरिएको थियो, र परिणाम थियो 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).

यो github मा ती मध्ये एक हो। हामीले के गर्यौं:

लिएका छन् फोर्क Elyran कोगन (@elyrank) - यसले 1 र 3 समस्याहरू समाधान गर्दछ
समस्या समाधान २
जेट्टी ९.२.१४ देखि ९.३.१२ सम्म अद्यावधिक गरियो
ThreadLocal मा सरल मिति ढाँचा बेरिएको; SimpleDateFormat थ्रेड-सुरक्षित छैन, जसले रनटाइममा NPE लाई नेतृत्व गर्यो
अर्को मेमोरी चुहावट फिक्स गरियो (विच्छेद हुँदा जडान गलत रूपमा बन्द भयो)

र अझै यो बग्छ!

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

दुई दिन बितिसक्यो...

अब Hazelcast मेमोरी समाप्त हुँदैछ। लगहरूले देखाएको छ कि केहि दिनको परीक्षण पछि, हेजलकास्टले मेमोरीको कमीको बारेमा गुनासो गर्न थाले, र केहि समय पछि क्लस्टर अलग भयो, र नोडहरू एक एक गरेर मर्न जारी राखे। हामीले JVisualVM लाई hazelcast मा जडान गर्यौं र "बढ्दो आरा" देख्यौं - यसलाई नियमित रूपमा 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 लाई ग्रूवीमा लेख्न र कम्पाइलेशन क्यास समावेश गर्न आवश्यक छ - यो धेरै छिटो छ। लिङ्क.
Jmeter-Plugins ग्राफहरू मानक भन्दा बुझ्न सजिलो छ। लिङ्क.

Hazelcast संग हाम्रो अनुभव को बारे मा

Hazelcast हाम्रो लागि नयाँ उत्पादन थियो, हामीले संस्करण 3.4.1 बाट यसको साथ काम गर्न थाल्यौं, अब हाम्रो उत्पादन सर्भर संस्करण 3.9.2 चलिरहेको छ (लेख्ने समयमा, Hazelcast को नवीनतम संस्करण 3.10 हो)।

आईडी उत्पादन

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

खैर, ट्विटर जस्तै बन्न चाहनेहरूका लागि, त्यहाँ यस्तो स्नोकास्ट पुस्तकालय छ - यो हेजलकास्टको शीर्षमा स्नोफ्लेकको कार्यान्वयन हो। तपाइँ यसलाई यहाँ हेर्न सक्नुहुन्छ:

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 घुसाउनुहोस्

पहिले, हामीले Hazelcast मा हाम्रा कक्षाका वस्तुहरू रेकर्ड गर्ने निर्णय गर्यौं। उदाहरणका लागि, हामीसँग एउटा अनुप्रयोग कक्षा छ, हामी यसलाई बचत गर्न र पढ्न चाहन्छौं। बचत गर्नुहोस्:

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 प्राप्त गर्न थाले। Hazelcast ले अनुक्रमणिकामा थप्न प्रयास गर्यो, तर हाम्रो कक्षाको बारेमा केही थाहा थिएन र यो वर्गसँग एक 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) मा सबै प्रश्नहरूको लगिङ अन गर्छौं र २० मिनेटको लागि लोड परीक्षण चलाउँछौं। सङ्कलन गरिएका लगहरू प्रयोग गरेर, pgFouine र pgBadger जस्ता उपयोगिताहरूले विश्लेषणात्मक रिपोर्टहरू निर्माण गर्न सक्छन्। रिपोर्टहरूमा, हामी मुख्य रूपमा ढिलो र बारम्बार प्रश्नहरू खोज्छौं। ढिलो प्रश्नहरूको लागि, हामी एउटा कार्यान्वयन योजना (EXPLAIN) बनाउँछौं र त्यस्ता क्वेरीलाई गति दिन सकिन्छ कि भनेर मूल्याङ्कन गर्छौं। उही इनपुट डेटाको लागि बारम्बार अनुरोधहरू क्यासमा राम्रोसँग फिट हुन्छन्। हामी प्रश्नहरू "फ्लैट" राख्न प्रयास गर्छौं, प्रति क्वेरी एउटा तालिका।

अपरेशन

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

सञ्चालन भएको एक वर्षभन्दा बढी अवधिमा सीबी अनलाइन सेवा सञ्चालनमा कुनै गम्भीर समस्या आएको छैन। हामी अनलाइन सेवा मार्फत निगरानी गर्छौं Zabbix, बाट संकलन र तैनाती बांस.

SV सर्भर वितरण नेटिभ प्याकेजहरूको रूपमा आपूर्ति गरिन्छ: RPM, DEB, MSI। साथै Windows को लागी हामी एकल EXE को रूपमा एकल स्थापनाकर्ता प्रदान गर्दछौं जसले सर्भर, Hazelcast र Elasticsearch लाई एक मेसिनमा स्थापना गर्दछ। हामीले प्रारम्भमा स्थापनाको यस संस्करणलाई "डेमो" संस्करणको रूपमा उल्लेख गर्यौं, तर अब यो स्पष्ट भएको छ कि यो सबैभन्दा लोकप्रिय डिप्लोइमेन्ट विकल्प हो।

स्रोत: www.habr.com

हामीले कसरी र किन 1C को लागि उच्च-लोड स्केलेबल सेवा लेख्यौं: इन्टरप्राइज: Java, PostgreSQL, Hazelcast