🛣️ 🖖🏾 🌍 कैसे हम स्पोर्टमास्टर ने एक कैशिंग प्रणाली को चुना। भाग 1 💇🏿 🧘🏾 🧙🏽

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

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

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

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

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

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

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

पसंद का आटा

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

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

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

हम Google और StackOverflow द्वारा संकेतित सभी प्रणालियों की एक सूची बनाते हैं। 30 से थोड़ा अधिक
, . , - — , .
, , , . , – , .
17- , . « », .

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

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

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

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

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

Redis

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

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

ehcache

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

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

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

Tarantool

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

आइए कार्यान्वयन को देखें: Mail.ru कॉर्पोरेट हाईवे, Avito, Beeline, Megafon, Alfa-Bank, Gazprom ...

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

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

प्रज्वलित

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

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

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

Hazelcast

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

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

तुलना

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

हमें ऐसी समीक्षा मिलती है , हमारे 5 सिस्टम चुनें।

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

लेकिन चलो गणना पद्धति को देखें : वेबसाइटों के लिंक, सिस्टम में सामान्य रुचि, नौकरी की पेशकश - महान! यही है, जब मेरा सिस्टम गिरता है, तो मैं कहूंगा: “नहीं, यह विश्वसनीय है! यहाँ बहुत सारे जॉब ऑफर हैं… ”। ऐसी सरल तुलना काम नहीं करेगी।

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

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

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

हम इस तरह की तुलना पाते हैं :

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

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

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

एक और तुलना :

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

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

बोतल को हिलाना

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

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

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

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

ऐसी एक विधि है, बहुत तेज और बहुत प्रभावी है।

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

हम इसे किसी को दिखा रहे हैं: "सर्ज, देखें!"। और वास्तव में, दूर से - जैसे कि एक जहाज। लेकिन तब आप इसे जाने नहीं दे सकते।

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

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

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

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

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

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

बोतल-गर्दन की तलाश कहाँ

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

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

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

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

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

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

हेज़ेलकास्ट

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

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

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

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

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

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

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

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

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

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

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

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

जारी रहती है

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

इस बीच ... हैप्पी न्यू कोड!

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