स्पोर्टमास्टर में हमने कैशिंग सिस्टम कैसे चुना। भाग ---- पहला

नमस्ते! मेरा नाम एलेक्सी पायनकोव है, मैं स्पोर्टमास्टर कंपनी में डेवलपर हूं। के कारण से पद मैंने बताया कि 2012 में स्पोर्टमास्टर वेबसाइट पर काम कैसे शुरू हुआ, हम किन पहलों को आगे बढ़ाने में कामयाब रहे और इसके विपरीत, हमने कौन सा रेक एकत्र किया।

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

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

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

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

लेकिन इस पोस्ट में मैं दूर से शुरुआत करूंगा, मैं कैशिंग के बारे में कुछ विचार प्रस्तुत करूंगा, जो एक बड़े प्रोजेक्ट से पहले स्क्रॉल करने के लिए एक अच्छा कदम होगा।

जब कोई कैशिंग कार्य होता है

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

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

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

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

कैशिंग सिस्टम के लिए बुनियादी आवश्यकताएँ

पहली चीज़ जो कैशिंग सिस्टम के लिए एक आवश्यकता बन सकती है वह है तेज़ पढ़ने की गति और, कुछ हद तक, लिखने की गति। यह सच है, लेकिन केवल तब तक जब तक हम सिस्टम को उत्पादन में नहीं लाते।

आइये इस केस को खेलते हैं.

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

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

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

शुरुआती भार के सापेक्ष, हमारा लौह भंडार 2-5 गुना था, और इस दौरान भार 10-100 गुना बढ़ गया। कैश का उपयोग करके, हमने भारी कार्यों के लिए कॉल को समाप्त कर दिया और इसलिए सब कुछ काम कर गया। और अब, कैश के बिना, हमारा सिस्टम कितनी बार धीमा होगा? हमारा क्या होगा? सिस्टम गिर जायेगा.

भले ही हमारा कैश क्रैश नहीं हुआ हो, लेकिन केवल थोड़ी देर के लिए साफ़ हो गया हो, इसे गर्म करने की आवश्यकता होगी, और इसमें कुछ समय लगेगा। और इस दौरान मुख्य बोझ कार्यक्षमता पर पड़ेगा।

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

पसंद का आटा

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

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

हमने क्या किया था:

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

लेकिन यह एक विकल्प है जब आपको एक ऐसी प्रणाली चुनने की आवश्यकता होती है जो पूर्व-तैयार परीक्षणों में "गति प्राप्त करेगी"। यदि अभी तक ऐसे कोई परीक्षण नहीं हुए हैं और आप जल्दी से चयन करना चाहते हैं तो क्या होगा?

आइए इस विकल्प को मॉडल करें (यह कल्पना करना कठिन है कि एक मध्य + डेवलपर शून्य में रहता है, और चयन के समय उसने अभी तक अपनी प्राथमिकता को औपचारिक रूप नहीं दिया है कि किस उत्पाद को पहले आज़माया जाए - इसलिए, आगे का तर्क एक सिद्धांतवादी/दर्शन/ से अधिक है एक जूनियर के बारे में)

आवश्यकताओं पर निर्णय लेने के बाद, हम बॉक्स से बाहर एक समाधान का चयन करना शुरू करेंगे। पहिए का पुनः आविष्कार क्यों करें: हम जाएंगे और एक तैयार कैशिंग सिस्टम लेंगे।

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

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

Redis

हम आधिकारिक वेबसाइट पर वही पढ़ते हैं जो वे लिखते हैं।
Redis - ओपनसोर्स प्रोजेक्ट। इन-मेमोरी डेटा स्टोरेज, ऑन-डिस्क को सहेजने की क्षमता, ऑटो-विभाजन, उच्च उपलब्धता और नेटवर्क आउटेज से पुनर्प्राप्ति प्रदान करता है।

ऐसा लगता है कि सब कुछ ठीक है, आप इसे ले सकते हैं और इसमें पेंच लगा सकते हैं - आपको जो कुछ भी चाहिए, वह करता है। लेकिन केवल मनोरंजन के लिए, आइए अन्य उम्मीदवारों पर नजर डालें।

एहकैश

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

Redis भूल गया है, मैं EhCache चुनने के लिए तैयार हूं।

लेकिन देशभक्ति की भावना मुझे यह देखने के लिए प्रेरित करती है कि टारनटूल में क्या अच्छा है।

टारनटूल

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

आइए कार्यान्वयन देखें: Mail.ru कॉर्पोरेट हाईवे, एविटो, बीलाइन, मेगफॉन, अल्फ़ा-बैंक, गज़प्रोम...

यदि टारनटूल के बारे में अभी भी कोई संदेह था, तो मास्टरकार्ड में कार्यान्वयन का मामला मुझे खत्म कर देता है। मैं टारनटूल लेता हूं।

लेकिन वैसे भी…

आग लगना

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

कार्यान्वयन: सर्बैंक, अमेरिकन एयरलाइंस, याहू! जापान. और फिर मुझे पता चला कि इग्नाइट को सिर्फ Sberbank में लागू नहीं किया गया है, बल्कि SberTech टीम उत्पाद को परिष्कृत करने के लिए अपने लोगों को Ignite टीम में ही भेजती है। यह पूरी तरह से मनमोहक है और मैं इग्नाइट लेने के लिए तैयार हूं।

यह पूरी तरह से अस्पष्ट है कि क्यों, मैं पांचवें बिंदु पर देख रहा हूं।

हेज़लकास्ट

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

बस, मैं हेज़लकास्ट लेने के लिए तैयार हूं।

तुलना

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

हमें ऐसा ही एक मिल गया है अवलोकन, हमारे 5 सिस्टम चुनें।

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

लेकिन आइए देखें गणना विधि: वेबसाइटों के लिंक, सिस्टम में सामान्य रुचि, नौकरी की पेशकश - बढ़िया! यानी, जब मेरा सिस्टम विफल हो जाएगा, तो मैं कहूंगा: “नहीं, यह विश्वसनीय है! नौकरी के कई प्रस्ताव हैं..." इतनी सरल तुलना से काम नहीं चलेगा.

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

ठीक है, आइए हार न मानें, आइए सिस्टम की सीधी तुलना खोजें। आइए शीर्ष दो विकल्प लें - रेडिस और हेज़लकास्ट। हम गति में रुचि रखते हैं, और हम इस पैरामीटर के आधार पर उनकी तुलना करेंगे।

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

हमने यह पाया तुलना:


नीला रेडिस है, लाल हेज़लकास्ट है। हेज़लकास्ट हर जगह जीतता है, और इसके लिए एक तर्क है: यह बहु-थ्रेडेड है, अत्यधिक अनुकूलित है, प्रत्येक थ्रेड अपने स्वयं के विभाजन के साथ काम करता है, इसलिए कोई अवरोध नहीं है। और रेडिस सिंगल-थ्रेडेड है; यह आधुनिक मल्टी-कोर सीपीयू से लाभ नहीं उठाता है। हेज़लकास्ट में एसिंक्रोनस I/O है, रेडिस-जेडिस में ब्लॉकिंग सॉकेट हैं। आख़िरकार, हेज़लकास्ट एक बाइनरी प्रोटोकॉल का उपयोग करता है, और रेडिस टेक्स्ट-केंद्रित है, जिसका अर्थ है कि यह अक्षम है।

बस मामले में, आइए तुलना के दूसरे स्रोत की ओर मुड़ें। वह हमें क्या दिखाएगा?

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

एक और तुलना:


यहाँ, इसके विपरीत, लाल रेडिस है। यानी प्रदर्शन के मामले में रेडिस हेज़लकास्ट से बेहतर प्रदर्शन करता है। हेज़लकास्ट ने पहली तुलना जीती, रेडिस ने दूसरी। यहाँ बहुत सटीक ढंग से समझाया गया कि हेज़लकास्ट ने पिछली तुलना क्यों जीती।

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

बोतल हिलाना

और मैं उस पूरी प्रक्रिया को समझा सकता हूं जो हमने अब निम्नलिखित रूपक के साथ की है: "बोतल को हिलाना।" यानी अब आपको प्रोग्राम करने की जरूरत नहीं है, अब मुख्य बात स्टैकओवरफ्लो को पढ़ने में सक्षम होना है। और मेरी टीम में एक व्यक्ति है, पेशेवर, जो महत्वपूर्ण क्षणों में बिल्कुल इसी तरह काम करता है।

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

इस विधि को इस उदाहरण से बहुत अच्छे से समझाया गया है।

किसी समय सेलबोट को बोतल में इकट्ठा करना बहुत लोकप्रिय था। साथ ही, सेलबोट बड़ी और नाजुक है, और बोतल की गर्दन बहुत संकीर्ण है, इसे अंदर धकेलना असंभव है। इसे कैसे असेंबल करें?

एक ऐसा तरीका है, बहुत तेज़ और बहुत असरदार.

जहाज में छोटी-छोटी चीजों का एक समूह होता है: छड़ें, रस्सियाँ, पाल, गोंद। हमने यह सब एक बोतल में डाल दिया।
हम बोतल को दोनों हाथों से लेते हैं और हिलाना शुरू करते हैं। हम उसे हिलाते-डुलाते हैं। और निःसंदेह, आमतौर पर यह पूरा कचरा ही साबित होता है। लेकिन कभी कभी। कभी-कभी यह एक जहाज बन जाता है! अधिक सटीक रूप से, जहाज के समान कुछ।

हम इसे किसी को कुछ दिखाते हैं: "सरयोगा, क्या आप देखते हैं!" और सचमुच, दूर से यह एक जहाज जैसा दिखता है। लेकिन इसे जारी रखने की इजाजत नहीं दी जा सकती.

एक और तरीका है. इनका उपयोग हैकर्स जैसे अधिक उन्नत लोगों द्वारा किया जाता है।

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

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

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

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

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

बॉटल-नेक कहां देखें

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

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

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

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

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

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

हेज़लकास्ट

आइए देखें कि इस अपघटन को हमारी सूची में कैसे लागू किया जाए। उदाहरण के लिए, हेज़लकास्ट।

हेज़लकास्ट से डेटा डालने/लेने के लिए, क्लाइंट कोड (1) एपीआई तक पहुंचता है। हर्ट्ज आपको सर्वर को एम्बेडेड के रूप में चलाने की अनुमति देता है, और इस मामले में, एपीआई तक पहुंच जेवीएम के अंदर एक विधि कॉल है, जिसे मुफ़्त माना जा सकता है।

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

स्टोरेज (4) को जोड़ा जा सकता है। महान। एंबेडेड के लिए इंटरैक्शन (5) को तत्काल माना जा सकता है। क्लस्टर में नोड्स के बीच डेटा विनिमय (6) - हाँ, यह मौजूद है। यह गति की कीमत पर दोष सहनशीलता में निवेश है। हर्ट्ज सुविधा नियर-कैश आपको कीमत कम करने की अनुमति देती है - क्लस्टर में अन्य नोड्स से प्राप्त डेटा कैश किया जाएगा।

ऐसी स्थिति में गति बढ़ाने के लिए क्या किया जा सकता है?

उदाहरण के लिए, (2) में कुंजी के क्रमांकन से बचने के लिए - सबसे हॉट डेटा के लिए, हेज़लकास्ट के शीर्ष पर एक और कैश संलग्न करें। स्पोर्टमास्टर ने इस उद्देश्य के लिए कैफीन को चुना।

स्तर (6) पर घुमाव के लिए, हर्ट्ज दो प्रकार के भंडारण प्रदान करता है: आईमैप और रेप्लिकेटेडमैप।


यह उल्लेख करने योग्य है कि हेज़लकास्ट स्पोर्टमास्टर प्रौद्योगिकी स्टैक में कैसे आया।

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

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

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

इन सभी आवश्यकताओं के लिए, हेज़लकास्ट निश्चित रूप से बिल में फिट बैठता है।

जारी

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

इस बीच... नया कोड मुबारक!

स्रोत: www.habr.com