हामीले स्पोर्टमास्टरमा कसरी क्यासिङ प्रणाली रोज्यौं। भाग 1

नमस्ते! मेरो नाम Alexey Pyankov हो, म Sportmaster कम्पनी मा एक विकासकर्ता हुँ। त्यसमा पोस्ट मैले 2012 मा स्पोर्टमास्टर वेबसाइटमा कसरी काम सुरु भयो, हामीले कुन पहलहरू "पुश थ्रु" गर्न व्यवस्थित गर्यौं र यसको विपरित, हामीले कुन रेक सङ्कलन गर्यौं भनेर बताए।

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

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

जब स्पोर्टमास्टर वेबसाइटको नयाँ संस्करण उत्पादनमा राखिएको थियो, डाटा एक तरिकामा प्राप्त भयो जुन यसलाई हल्का रूपमा भन्नुपर्दा, धेरै सुविधाजनक थिएन। आधार साइट (Bitrix) को अघिल्लो संस्करणको लागि तयार गरिएको तालिका थियो, जसलाई ETL मा तान्नु पर्ने थियो, नयाँ फारममा ल्याइयो र दर्जनौं प्रणालीहरूबाट विभिन्न साना चीजहरूसँग समृद्ध। साइटमा नयाँ तस्विर वा उत्पादन विवरण देखा पर्नको लागि, तपाईंले अर्को दिनसम्म पर्खनु पर्थ्यो - रातमा मात्र अपडेटहरू, दिनमा एक पटक।

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

तर यस पोष्टमा म टाढाबाट सुरु गर्नेछु, म केही विचारहरू प्रस्तुत गर्नेछु - क्यासिङको बारेमा विचारहरू, जुन ठूलो परियोजना अघि स्क्रोल गर्न राम्रो कदम हुनेछ।

जब क्यासिङ कार्य हुन्छ

क्यासिङ कार्य मात्र देखा पर्दैन। हामी विकासकर्ता हौं, सफ्टवेयर उत्पादन लेख्छौं र यो मागमा होस् भन्ने चाहन्छौं। यदि उत्पादन माग र सफल छ भने, प्रयोगकर्ताहरू आउनेछन्। र अधिक र अधिक आउनुहोस्। र त्यसपछि त्यहाँ धेरै प्रयोगकर्ताहरू छन् र त्यसपछि उत्पादन अत्यधिक लोड हुन्छ।

पहिलो चरणहरूमा, हामी अप्टिमाइजेसन र कोड प्रदर्शनको बारेमा सोच्दैनौं। मुख्य कुरा कार्यक्षमता छ, चाँडै एक पायलट रोल आउट र परिकल्पना परीक्षण। र यदि लोड बढ्छ भने, हामी फलाम पम्प गर्छौं। हामी यसलाई दुई वा तीन पटक, पाँच पटक, सायद 10 पटक बढाउँछौं। कतै यहाँ - वित्तले यसलाई अनुमति दिँदैन। प्रयोगकर्ताको संख्या कति पटक बढ्छ? यो 2-5-10 जस्तो हुनेछैन, तर यदि सफल भयो भने, यो 100-1000 देखि 100 हजार पटक सम्म हुनेछ। त्यो छ, ढिलो वा चाँडो, तपाईंले अप्टिमाइजेसन गर्नु पर्छ।

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

त्यो हो, कार्यको कार्यान्वयन हाम्रो लागि महत्त्वपूर्ण छैन। नतिजा कुन प्यारामिटरहरूमा निर्भर हुन्छ भनेर जान्न पर्याप्त छ। त्यसोभए, यदि प्यारामिटर मानहरू वस्तुको रूपमा प्रतिनिधित्व गरिन्छ जुन केही भण्डारणमा कुञ्जीको रूपमा प्रयोग गर्न सकिन्छ, त्यसपछि गणनाको परिणाम बचत गर्न सकिन्छ र अर्को पटक पहुँच गर्दा पढ्न सकिन्छ। यदि यो नतिजाको लेखन र पढाइ कार्य कार्यान्वयन भन्दा छिटो छ भने, हामी गति को मामला मा एक लाभ छ। नाफा को मात्रा 100, 1000, र 100 हजार पटक पुग्न सक्छ (10^5 बरु एक अपवाद हो, तर एक पर्याप्त ढिलो आधार को मामला मा, यो एकदम सम्भव छ)।

क्यासिङ प्रणालीको लागि आधारभूत आवश्यकताहरू

क्यासिङ प्रणालीको लागि आवश्यकता बन्न सक्ने पहिलो कुरा भनेको छिटो पढ्ने गति हो र, थोरै हदसम्म, लेखन गति। यो सत्य हो, तर हामीले उत्पादनमा प्रणाली रोल आउट नगरेसम्म मात्र।

यो मामला खेलौं।

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

र यदि हार्डवेयरको प्रारम्भिक आपूर्ति 2-5 पटक हुन सक्छ, तब क्यासको मद्दतले हामी 10 को एक कारक द्वारा प्रदर्शन सुधार गर्न सक्छौं वा, राम्रो अवस्थामा, 100 को एक कारक द्वारा, केहि स्थानहरुमा शायद एक कारक द्वारा। 1000 को। त्यो, एउटै हार्डवेयरमा - हामी 100 गुणा बढी अनुरोधहरू प्रशोधन गर्छौं। महान, तपाईं जिंजरब्रेडको योग्य हुनुहुन्छ!

तर अब, एक राम्रो क्षणमा, संयोगले, प्रणाली क्र्यास भयो र क्यास पतन भयो। केहि खास छैन - आखिर, क्यास "उच्च पढ्ने र लेख्ने गति, बाँकी केहि फरक पर्दैन" आवश्यकताको आधारमा चयन गरिएको थियो।

सुरु लोड को सापेक्ष, हाम्रो फलाम रिजर्व 2-5 पटक थियो, र यो समयमा लोड 10-100 पटक बढ्यो। क्यास प्रयोग गरेर, हामीले भारी प्रकार्यहरूको लागि कलहरू हटायौं र त्यसैले सबै काम भयो। र अब, क्यास बिना, हाम्रो प्रणाली कति पटक सुस्त हुनेछ? हाम्रो के हुने हो ? प्रणाली खस्नेछ।

यदि हाम्रो क्यास क्र्यास भएन, तर केही समयको लागि मात्र खाली गरियो, यसलाई न्यानो गर्न आवश्यक हुनेछ, र यसले केही समय लिनेछ। र यस समयमा, मुख्य बोझ कार्यक्षमता मा पर्नेछ।

निष्कर्ष: अत्यधिक लोड गरिएका उत्पादन परियोजनाहरूलाई उच्च पढ्ने र लेख्ने गति मात्र नभई डेटा सुरक्षा र विफलताहरूको प्रतिरोध सुनिश्चित गर्न क्यासिङ प्रणाली चाहिन्छ।

छनौटको पीडा

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

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

हामीले के गर्यौं:

1. हामी Google र StackOverflow ले सुझाव दिने सबै प्रणालीहरूको सूची बनाउँछौं। ३० भन्दा अलि बढी
2. हामी उत्पादनको लागि सामान्य लोडको साथ परीक्षणहरू लेख्छौं। यो गर्नको लागि, हामीले उत्पादन वातावरणमा प्रणाली मार्फत जाने डाटा रेकर्ड गर्‍यौं - नेटवर्कमा होइन, तर प्रणाली भित्र डाटाको लागि एक प्रकारको स्निफर। ठ्याक्कै यो डाटा परीक्षण मा प्रयोग भएको थियो।
3. सम्पूर्ण टोलीसँग, सबैले सूचीबाट अर्को प्रणाली चयन गर्दछ, यसलाई कन्फिगर गर्दछ, र परीक्षणहरू चलाउँछ। यसले परीक्षा पास गर्दैन, यसले भार बोक्दैन - हामी यसलाई फ्याँक्छौं र अर्को लाइनमा जान्छौं।
4. 17 औं प्रणालीमा यो स्पष्ट भयो कि सबै आशाहीन थियो। बोतल हल्लाउन बन्द गर्नुहोस्, यो गम्भीरतापूर्वक सोच्ने समय हो।

तर यो एक विकल्प हो जब तपाइँ एक प्रणाली छनोट गर्न आवश्यक छ जुन पूर्व-तयार परीक्षणहरूमा "गति मार्फत प्राप्त" हुनेछ। के हुन्छ यदि त्यस्ता कुनै परीक्षणहरू छैनन् र तपाईं छिट्टै छनौट गर्न चाहनुहुन्छ?

यस विकल्पलाई मोडल गरौं (मध्य+ विकासकर्ता शून्यमा बस्छन् भन्ने कल्पना गर्न गाह्रो छ, र चयनको समयमा कुन उत्पादनलाई पहिले प्रयास गर्ने भनेर आफ्नो प्राथमिकतालाई औपचारिक रूपमा औपचारिक रूपमा तोकेको छैन - त्यसैले, थप तर्क सिद्धान्तवादी/दर्शन/ जुनियर को बारे मा)।

आवश्यकताहरूमा निर्णय गरिसकेपछि, हामी बाकस बाहिर समाधान चयन गर्न सुरु गर्नेछौं। किन व्हील पुन: आविष्कार: हामी जान्छौं र तयार क्यासिङ प्रणाली लिनेछौं।

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

सूची पूर्ण छैन; त्यहाँ दर्जनौं प्रणालीहरू छन्। र हामी केवल एक चीज पेंच गर्नेछौं। "सौंदर्य प्रतियोगिता" को लागि चयन गरिएको 5 प्रणालीहरू लिनुहोस् र चयन गर्नुहोस्। को हुनेछ विजेता ?

Redis

तिनीहरूले आधिकारिक वेबसाइटमा के लेख्छन् हामी पढ्छौं।
Redis - खुला स्रोत परियोजना। इन-मेमोरी डाटा भण्डारण, अन-डिस्क बचत गर्ने क्षमता, स्वत: विभाजन, उच्च उपलब्धता र नेटवर्क आउटेजबाट रिकभरी प्रदान गर्दछ।

यस्तो देखिन्छ कि सबै कुरा ठीक छ, तपाईं यसलाई लिन सक्नुहुन्छ र यसलाई पेंच गर्न सक्नुहुन्छ - तपाईलाई चाहिने सबै कुरा, यसले गर्छ। तर केवल रमाईलोको लागि, अरू उम्मेदवारहरूलाई हेरौं।

EhCache

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

Redis बिर्सिएको छ, म EhCache छनौट गर्न तयार छु।

तर देशभक्तिको भावनाले मलाई टारन्टुलको बारेमा के राम्रो छ भनेर हेर्न प्रेरित गर्छ।

टारान्टुल

टारान्टुल - पदनाम "वास्तविक-समय डाटा एकीकरण प्लेटफर्म" लाई पूरा गर्दछ। यो धेरै जटिल सुनिन्छ, त्यसैले हामी पृष्ठलाई विस्तृत रूपमा पढ्छौं र ठूलो बयान फेला पार्छौं: "RAM मा डाटाको 100% क्यास गर्दछ।" यसले प्रश्न उठाउनु पर्छ - आखिर, मेमोरी भन्दा धेरै डाटा हुन सक्छ। व्याख्या यो हो कि Tarantool ले मेमोरीबाट डिस्कमा डाटा लेख्नको लागि क्रमबद्धता चलाउँदैन। यसको सट्टा, यसले प्रणालीको निम्न-स्तर सुविधाहरू प्रयोग गर्दछ, जब मेमोरीलाई धेरै राम्रो I/O प्रदर्शनको साथ फाइल प्रणालीमा म्याप गरिन्छ। सामान्यतया, तिनीहरूले अद्भुत र राम्रो कुरा गरे।

कार्यान्वयनहरू हेरौं: Mail.ru कर्पोरेट राजमार्ग, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...

यदि Tarantool को बारे मा अझै पनि कुनै शंका थियो भने, मास्टरकार्ड मा कार्यान्वयन मामलाले मलाई समाप्त गर्दछ। म टारन्टुल लिन्छु।

तर जे होस्…

सल्काउनुभयो

… त्यहाँ केहि थप छ सल्काउनुभयो, "इन-मेमोरी कम्प्युटिङ प्लेटफर्म... डाटाको पेटाबाइटहरूमा मेमोरी गति" को रूपमा बिल गरिएको छ। यहाँ धेरै फाइदाहरू पनि छन्: इन-मेमोरी क्यास वितरित, सबैभन्दा छिटो कुञ्जी-मान भण्डारण र क्यास, तेर्सो मापन, उच्च उपलब्धता, कडा अखण्डता। सामान्यतया, यो बाहिर जान्छ कि सबै भन्दा छिटो इग्नाइट हो।

कार्यान्वयन: Sberbank, अमेरिकन एयरलाइन्स, याहू! जापान। र त्यसपछि मैले Ignite Sberbank मा मात्र लागू गरिएको होइन, तर SberTech टोलीले उत्पादनलाई परिष्कृत गर्नका लागि आफ्ना मानिसहरूलाई Ignite टोलीमा पठाउँछ। यो पूर्णतया मनमोहक छ र म इग्नाइट लिन तयार छु।

यो पूर्ण रूपमा स्पष्ट छैन किन, म पाँचौं बिन्दु हेर्दै छु।

हेजलकास्ट

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

त्यो हो, म हेजलकास्ट लिन तयार छु।

तुलना

तर यदि तपाईंले हेर्नुभयो भने, सबै पाँच उम्मेद्वारहरू यसरी वर्णन गरिएको छ कि तिनीहरूमध्ये प्रत्येक उत्कृष्ट छ। कसरी छनौट गर्ने? हामी कुन सबैभन्दा लोकप्रिय छ भनेर देख्न सक्छौं, तुलनाहरू खोज्नुहोस्, र टाउको दुखाइ हट्नेछ।

हामीले यस्तो एउटा भेट्टाउँछौं समीक्षा, हाम्रो 5 प्रणालीहरू छान्नुहोस्।

यहाँ तिनीहरू क्रमबद्ध छन्: Redis शीर्षमा छ, Hazelcast दोस्रो स्थानमा छ, Tarantool र Ignite लोकप्रियता प्राप्त गर्दैछ, EhCache थियो र उस्तै छ।

तर हेरौं गणना विधि: वेबसाइटहरूको लिङ्कहरू, प्रणालीमा सामान्य चासो, जागिर प्रस्तावहरू - उत्कृष्ट! त्यो हो, जब मेरो प्रणाली असफल हुन्छ, म भन्नेछु: "होइन, यो भरपर्दो छ! त्यहाँ धेरै काम प्रस्तावहरू छन् ..." यस्तो साधारण तुलनाले काम गर्दैन।

यी सबै प्रणालीहरू क्यासिङ प्रणाली मात्र होइनन्। तिनीहरूसँग धेरै प्रकार्यहरू पनि छन्, जब डाटा प्रक्रियाको लागि ग्राहकमा पम्प गरिएको छैन, तर यसको विपरित: डेटामा कार्यान्वयन गर्न आवश्यक पर्ने कोड सर्भरमा सर्छ, त्यहाँ कार्यान्वयन हुन्छ, र परिणाम फर्काइन्छ। र तिनीहरू प्राय: क्यासिङको लागि छुट्टै प्रणालीको रूपमा मानिने छैनन्।

ठीक छ, हार नमानौं, प्रणालीहरूको प्रत्यक्ष तुलना फेला पारौं। शीर्ष दुई विकल्पहरू लिनुहोस् - Redis र Hazelcast। हामी गतिमा रुचि राख्छौं, र हामी तिनीहरूलाई यो प्यारामिटरको आधारमा तुलना गर्नेछौं।

हर्ट्ज बनाम रेडिस

हामी यो फेला पार्छौं तुलना:


निलो रेडिस हो, रातो हेजलकास्ट हो। Hazelcast जताततै जित्छ, र यसको लागि एक तर्क छ: यो बहु-थ्रेडेड, अत्यधिक अनुकूलित छ, प्रत्येक थ्रेड आफ्नै विभाजन संग काम गर्दछ, त्यसैले त्यहाँ कुनै अवरोध छैन। र Redis एकल-थ्रेडेड छ; यसले आधुनिक बहु-कोर CPU बाट फाइदा गर्दैन। Hazelcast सँग एसिन्क्रोनस I/O छ, Redis-Jedis सँग ब्लकिङ सकेटहरू छन्। आखिर, Hazelcast ले बाइनरी प्रोटोकल प्रयोग गर्दछ, र Redis पाठ-केन्द्रित छ, यसको मतलब यो असक्षम छ।

बस मामला मा, तुलना को अर्को स्रोत मा फर्कौं। उहाँले हामीलाई के देखाउनुहुन्छ?

रेडिस बनाम हर्ट्ज

अर्को तुलना:


यहाँ, यसको विपरीत, रातो Redis हो। त्यो हो, रेडिसले प्रदर्शनको सन्दर्भमा हेजलकास्टलाई पछाडि पार्छ। हेजलकास्टले पहिलो तुलना जित्यो, रेडिसले दोस्रो जित्यो। ठ्याक्क यहाँ हेजलकास्टले अघिल्लो तुलना किन जित्यो भनेर धेरै स्पष्ट रूपमा वर्णन गरियो।

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

बोतल हल्लाउँदै

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

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

यो विधि यो उदाहरण संग धेरै राम्रो व्याख्या गरिएको छ।

यो एक बोतल मा एक सेल डुङ्गा सङ्कलन गर्न एक पटक धेरै लोकप्रिय थियो। एकै समयमा, पाल डुङ्गा ठूलो र कमजोर छ, र बोतलको गर्दन धेरै साँघुरो छ, यसलाई भित्र धकेल्न असम्भव छ। यसलाई कसरी जम्मा गर्ने?

त्यहाँ यस्तो विधि छ, धेरै छिटो र धेरै प्रभावकारी।

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

हामी कसैलाई यो केहि देखाउँछौं: "Seryoga, तपाईंले देख्नुहुन्छ!?" र वास्तवमा, टाढाबाट यो जहाज जस्तो देखिन्छ। तर यसलाई निरन्तरता दिन सकिँदैन।

त्यहाँ अर्को तरिका छ। तिनीहरू अधिक उन्नत केटाहरू द्वारा प्रयोग गरिन्छ, जस्तै ह्याकरहरू।

मैले यो मान्छेलाई काम दिएँ, उसले सबै गर्यो र छोड्यो। र तपाईले हेर्नुभयो - यो सकियो जस्तो देखिन्छ। र केहि समय पछि, जब कोड फाइनल गर्न आवश्यक छ, यो उनको कारणले सुरु हुन्छ ... यो राम्रो छ कि उसले पहिले नै टाढा भाग्न व्यवस्थित गरेको छ। यी केटाहरू हुन् जसले, बोतलको उदाहरण प्रयोग गरेर, यो गर्नेछ: तपाईले देख्नुहुन्छ, जहाँ तल छ, गिलास झुक्छ। र यो पूर्ण रूपमा स्पष्ट छैन कि यो पारदर्शी हो वा होइन। त्यसपछि "ह्याकरहरू" ले यो तल काट्छन्, त्यहाँ एउटा जहाज घुसाउँछन्, त्यसपछि फेरि तल टाँस्छन्, र यो जस्तो हुनुपर्छ जस्तो छ।

समस्या सेटिङको दृष्टिकोणबाट, सबै कुरा सही देखिन्छ। तर उदाहरणको रूपमा जहाजहरू प्रयोग गर्दै: यो जहाज किन बनाउनुहोस्, जसलाई यो आवश्यक छ? यसले कुनै प्रकार्यता प्रदान गर्दैन। सामान्यतया त्यस्ता जहाजहरू धेरै उच्च-स्तरीय व्यक्तिहरूलाई उपहारहरू हुन्, जसले यसलाई आफ्नो माथिको शेल्फमा राख्छन्, कुनै प्रकारको प्रतीकको रूपमा, चिन्हको रूपमा। र यदि त्यस्तो व्यक्ति, ठूला व्यवसायको प्रमुख वा उच्च पदस्थ अधिकारी, त्यस्ता ह्याकको लागि झण्डा कसरी खडा हुनेछ, जसको घाँटी काटिएको छ? उसलाई थाहा नभएको भए राम्रो हुन्थ्यो। त्यसोभए, तिनीहरूले यी जहाजहरू कसरी बनाउँछन् जुन महत्त्वपूर्ण व्यक्तिलाई दिन सकिन्छ?

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

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

हाम्रो क्यासिङ सर्भर छनोट गर्ने कार्यमा फर्कदै, यो विधि कसरी लागू गर्न सकिन्छ? म अवस्थित सबै प्रणालीहरूबाट छनौट गर्ने यो विकल्प प्रस्ताव गर्दछु - बोतल नहल्लाउनुहोस्, छनौट नगर्नुहोस्, तर तिनीहरूसँग सिद्धान्तमा के छ हेर्नुहोस्, प्रणाली छनोट गर्दा के खोज्ने।

बोतल-नेक कहाँ खोज्ने

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

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

हामीलाई कोड तर्क (२) पनि चाहिन्छ, जुन वास्तवमा क्यासिङको बारेमा हो। ग्राहकहरूले यस कोडसँग केही API मार्फत अन्तरक्रिया गर्छन्। क्लाइन्ट कोड (2) कि त समान JVM भित्र हुन सक्छ वा नेटवर्कमा पहुँच गर्न सक्छ। भित्र लागू गरिएको तर्क भनेको क्यासमा कुन वस्तुहरू छोड्ने र कुन बाहिर फाल्ने भन्ने निर्णय हो। हामी क्यास भण्डारण गर्न मेमोरी (1) प्रयोग गर्छौं, तर आवश्यक भएमा, हामी डिस्कमा केही डाटा बचत गर्न सक्छौं (3)।

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

अर्को क्लस्टर संग अन्तरक्रिया छ। सम्भवतः, यो एउटै प्रणालीमा हुनेछ, तर यो अलग हुन सक्छ। यहाँ तपाईंले यसमा डाटाको स्थानान्तरण, डाटा क्रमिकरणको गति र क्लस्टर बीचको अन्तरक्रियालाई पनि ध्यानमा राख्न आवश्यक छ।

अब, एकातर्फ, हामी हाम्रो कोडबाट अनुरोधहरू प्रशोधन गर्दा क्यास प्रणालीमा "कस्ता गियरहरू घुम्नेछ" कल्पना गर्न सक्छौं, र अर्कोतर्फ, हामी हाम्रो कोडले यस प्रणालीमा के र कति अनुरोधहरू उत्पन्न गर्नेछ भनेर अनुमान गर्न सक्छौं। यो अधिक वा कम विवेकी छनौट गर्न पर्याप्त छ - हाम्रो प्रयोग केसको लागि प्रणाली छनौट गर्न।

हेजलकास्ट

हाम्रो सूचीमा यो विघटन कसरी लागू गर्ने हेरौं। उदाहरण को लागी, Hazelcast।

Hazelcast बाट डाटा राख्न / लिनको लागि, क्लाइन्ट कोडले (1) एपीआई पहुँच गर्दछ। Hz ले तपाईंलाई इम्बेडेड रूपमा सर्भर चलाउन अनुमति दिन्छ, र यस अवस्थामा, एपीआई पहुँच गर्नु JVM भित्रको एक विधि कल हो, जुन नि: शुल्क मान्न सकिन्छ।

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

भण्डारण (4) जडान गर्न सकिन्छ। महान। इम्बेडेडका लागि अन्तरक्रिया (5) तत्काल मान्न सकिन्छ। क्लस्टर (6) मा नोडहरू बीच डाटा विनिमय - हो, यो अवस्थित छ। यो गति को खर्च मा दोष सहिष्णुता मा एक लगानी हो। Hz सुविधा नजिकैको क्यासले तपाईंलाई मूल्य घटाउन अनुमति दिन्छ - क्लस्टरमा अन्य नोडहरूबाट प्राप्त डाटा क्यास गरिनेछ।

यस्तो अवस्थामा गति बढाउन के गर्न सकिन्छ?

उदाहरणका लागि, (2) मा कुञ्जीको क्रमबद्धताबाट बच्न - सबैभन्दा तातो डाटाको लागि, Hazelcast को शीर्षमा अर्को क्यास संलग्न गर्नुहोस्। स्पोर्टमास्टरले यस उद्देश्यका लागि क्याफिन रोजे।

स्तर (6) मा घुमाउनको लागि, Hz ले दुई प्रकारको भण्डारण प्रदान गर्दछ: IMap र ReplicatedMap।


हेजलकास्ट स्पोर्टमास्टर टेक्नोलोजी स्ट्याकमा कसरी आयो भनेर उल्लेख गर्न लायक छ।

2012 मा, जब हामीले भविष्यको साइटको पहिलो पाइलटमा काम गरिरहेका थियौं, यो Hazelcast थियो जुन खोज इन्जिनले फर्काएको पहिलो लिङ्क बन्यो। परिचितले "पहिलो पटक" सुरु गर्‍यो - हामी यस तथ्यबाट मोहित भयौं कि केवल दुई घण्टा पछि, जब हामीले प्रणालीमा Hz स्क्रू गर्‍यौं, यसले काम गर्‍यो। र यसले राम्रोसँग काम गर्यो। दिनको अन्त्यमा हामीले धेरै परीक्षणहरू पूरा गरेका थियौं र खुसी थियौं। र हर्ट्जले समयको साथमा फ्याँकेका आश्चर्यहरू हटाउनको लागि यो शक्तिको भण्डार पर्याप्त थियो। अब Sportmaster टोली Hazelcast त्याग्न कुनै कारण छैन।

तर "खोज इन्जिनमा पहिलो लिङ्क" र "HelloWorld चाँडै भेला भएको थियो" जस्ता तर्कहरू, अवश्य पनि, एक अपवाद र क्षणको विशेषता हो जुन छनोट भयो। छनौट गरिएको प्रणालीको लागि वास्तविक परीक्षणहरू उत्पादनमा रिलीजको साथ सुरु हुन्छ, र यो यस चरणमा हो कि तपाईंले क्यास सहित कुनै पनि प्रणाली छनौट गर्दा ध्यान दिनुपर्छ। वास्तवमा, हाम्रो केसमा हामी भन्न सक्छौं कि हामीले हाजेलकास्टलाई संयोगवश छनोट गर्‍यौं, तर त्यसपछि हामीले सहि छनोट गर्‍यौं।

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

यी सबै आवश्यकताहरूको लागि, Hazelcast निश्चित रूपमा बिल फिट हुन्छ।

फेरि जारी राखौंला

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

यस बीचमा... नयाँ कोडको शुभकामना!

स्रोत: www.habr.com