स्पोर्टमास्टरमध्ये आम्ही कॅशिंग सिस्टम कशी निवडली. भाग 1

नमस्कार! माझे नाव अलेक्सी प्यानकोव्ह आहे, मी स्पोर्टमास्टर कंपनीचा विकासक आहे. त्यात पोस्ट 2012 मध्ये स्पोर्टमास्टर वेबसाइटवर काम कसे सुरू झाले, आम्ही कोणत्या उपक्रमांना “पुश थ्रू” करण्यात व्यवस्थापित केले आणि त्याउलट, आम्ही कोणते रेक गोळा केले ते मी सांगितले.

आज मला दुसर्‍या विषयाचे अनुसरण करणारे विचार सामायिक करायचे आहेत - साइट ऍडमिन पॅनेलमध्ये जावा बॅकएंडसाठी कॅशिंग सिस्टम निवडणे. या कथानकाचा माझ्यासाठी एक विशेष अर्थ आहे - जरी कथा केवळ 2 महिने उलगडली असली तरी, या 60 दिवसांमध्ये आम्ही 12-16 तास काम केले आणि एकही दिवस सुट्टी न घेता. इतकं कष्ट करणं शक्य आहे, असा मी कधी विचार किंवा कल्पनाही केली नव्हती.

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

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

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

जरी आमची कॅशे क्रॅश झाली नाही, परंतु काही काळासाठी साफ केली गेली असली तरीही, ते गरम करणे आवश्यक आहे आणि यास थोडा वेळ लागेल. आणि या काळात, मुख्य भार कार्यक्षमतेवर पडेल.

निष्कर्ष: उच्च भारित उत्पादन प्रकल्पांना केवळ उच्च वाचन आणि लेखन गती नसून डेटा सुरक्षितता आणि अपयशास प्रतिकार सुनिश्चित करण्यासाठी कॅशिंग सिस्टमची आवश्यकता असते.

निवडीची व्यथा

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

स्पॉयलर: परिस्थिती नेमकी कशी विकसित झाली की आम्ही इतका मोठा करार चुकवला आणि एक तीव्र आणि तणावपूर्ण परिस्थिती संपली - मी तुम्हाला दुसऱ्या भागात सांगेन - आणि आम्ही कसे संपलो आणि आम्ही कसे बाहेर पडलो. पण आता - मी फक्त असे म्हणेन की तो खूप ताणतणाव होता आणि "विचार करणे - कसा तरी मी विचार करू शकत नाही, आम्ही बाटली हलवत आहोत." "बाटली हलवणे" देखील एक बिघडवणारा आहे, त्याबद्दल नंतर अधिक.

आम्ही काय केले:

1. आम्ही Google आणि StackOverflow सुचवलेल्या सर्व प्रणालींची सूची तयार करतो. 30 च्या वर थोडे
2. आम्ही उत्पादनासाठी वैशिष्ट्यपूर्ण लोडसह चाचण्या लिहितो. हे करण्यासाठी, आम्ही उत्पादन वातावरणात सिस्टममधून जाणारा डेटा रेकॉर्ड केला - नेटवर्कवर नसून सिस्टमच्या आत डेटासाठी एक प्रकारचा स्निफर. नेमका हा डेटा चाचण्यांमध्ये वापरला गेला.
3. संपूर्ण टीमसह, प्रत्येकजण सूचीमधून पुढील सिस्टम निवडतो, ती कॉन्फिगर करतो आणि चाचण्या चालवतो. ती चाचणी उत्तीर्ण होत नाही, भार उचलत नाही - आम्ही ते फेकून देतो आणि पुढच्या ओळीत जाऊ.
4. 17 व्या प्रणालीवर हे स्पष्ट झाले की सर्वकाही हताश आहे. बाटली हलवणे थांबवा, गांभीर्याने विचार करण्याची वेळ आली आहे.

परंतु जेव्हा तुम्हाला पूर्व-तयार चाचण्यांमध्ये "वेगाने मिळू शकेल" अशी प्रणाली निवडण्याची आवश्यकता असेल तेव्हा हा एक पर्याय आहे. अद्याप अशा कोणत्याही चाचण्या नसल्यास आणि आपण त्वरीत निवडू इच्छित असल्यास काय?

चला या पर्यायाचे मॉडेल बनवूया (मध्यम+ विकसक व्हॅक्यूममध्ये राहतो याची कल्पना करणे कठीण आहे आणि निवडीच्या वेळी कोणते उत्पादन प्रथम वापरायचे याविषयी त्याचे प्राधान्य अद्याप औपचारिक केले नाही - म्हणून, पुढील तर्क हा एक सिद्धांत/तत्त्वज्ञानाचा आहे/ कनिष्ठ बद्दल).

आवश्यकतांवर निर्णय घेतल्यानंतर, आम्ही बॉक्सच्या बाहेर एक उपाय निवडण्यास सुरवात करू. चाक पुन्हा का शोधायचे: आम्ही जाऊ आणि तयार कॅशिंग सिस्टम घेऊ.

तुम्ही आत्ताच सुरुवात करत असाल आणि गुगल करा, तर ऑर्डर द्या किंवा घ्या, पण सर्वसाधारणपणे, मार्गदर्शक तत्त्वे अशी असतील. सर्व प्रथम, आपण रेडीस भेटू शकाल, हे सर्वत्र ऐकले आहे. मग तुम्हाला कळेल की EhCache ही सर्वात जुनी आणि सर्वात सिद्ध प्रणाली आहे. पुढे आपण टॅरनटूल बद्दल लिहू, एक घरगुती विकास ज्यामध्ये समाधानाचा एक अद्वितीय पैलू आहे. आणि प्रज्वलित देखील, कारण ते आता लोकप्रियतेत वाढ होत आहे आणि SberTech चे समर्थन मिळवते. शेवटी हेझेलकास्ट देखील आहे, कारण एंटरप्राइझ जगामध्ये ते मोठ्या कंपन्यांमध्ये दिसून येते.

यादी संपूर्ण नाही; तेथे डझनभर प्रणाली आहेत. आणि आम्ही फक्त एक गोष्ट स्क्रू करू. चला "सौंदर्य स्पर्धेसाठी" निवडलेल्या 5 प्रणाली घेऊ आणि निवड करू. विजेता कोण असेल?

Redis

ते अधिकृत वेबसाइटवर काय लिहितात ते आम्ही वाचतो.
Redis - ओपनसोर्स प्रकल्प. इन-मेमरी डेटा स्टोरेज, ऑन-डिस्क जतन करण्याची क्षमता, स्वयं-विभाजन, उच्च उपलब्धता आणि नेटवर्क आउटेजमधून पुनर्प्राप्ती ऑफर करते.

असे दिसते की सर्व काही ठीक आहे, आपण ते घेऊ शकता आणि त्यावर स्क्रू करू शकता - आपल्याला आवश्यक असलेली प्रत्येक गोष्ट, ते करते. पण फक्त मनोरंजनासाठी, इतर उमेदवारांकडे पाहू.

EhCache

EhCache - "जावासाठी सर्वात मोठ्या प्रमाणावर वापरले जाणारे कॅशे" (अधिकृत वेबसाइटवरील घोषवाक्याचे भाषांतर). तसेच ओपनसोर्स. आणि मग आम्हाला समजले की रेडिस जावासाठी नाही, परंतु सामान्य आहे आणि त्याच्याशी संवाद साधण्यासाठी तुम्हाला रॅपरची आवश्यकता आहे. आणि EhCache अधिक सोयीस्कर होईल. सिस्टम आणखी काय वचन देते? विश्वसनीयता, सिद्ध, पूर्ण कार्यक्षमता. बरं, हे देखील सर्वात सामान्य आहे. आणि टेराबाइट्स डेटा कॅशे करतो.

रेडिस विसरला आहे, मी EhCache निवडण्यास तयार आहे.

पण देशभक्तीची भावना मला टारंटूलमध्ये काय चांगले आहे हे पाहण्यास प्रवृत्त करते.

टारनटूल

टारनटूल - पदनाम “रिअल-टाइम डेटा इंटिग्रेशन प्लॅटफॉर्म” पूर्ण करते. हे खूप क्लिष्ट वाटते, म्हणून आम्ही पृष्ठ तपशीलवार वाचतो आणि एक मोठा विधान शोधतो: "RAM मध्ये 100% डेटा कॅश करतो." यामुळे प्रश्न निर्माण झाले पाहिजेत - शेवटी, मेमरीपेक्षा खूप जास्त डेटा असू शकतो. स्पष्टीकरण असे आहे की याचा अर्थ असा आहे की मेमरीमधून डिस्कवर डेटा लिहिण्यासाठी टॅरनटूल सीरियलायझेशन चालवत नाही. त्याऐवजी, ते सिस्टमच्या निम्न-स्तरीय वैशिष्ट्यांचा वापर करते, जेव्हा मेमरी अगदी चांगल्या I/O कार्यक्षमतेसह फाइल सिस्टममध्ये मॅप केली जाते. सर्वसाधारणपणे, त्यांनी काहीतरी अद्भुत आणि छान केले.

चला अंमलबजावणी पाहू: Mail.ru कॉर्पोरेट महामार्ग, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...

टॅरनटूलबद्दल अजूनही काही शंका असल्यास, मास्टरकार्डवरील अंमलबजावणी प्रकरणाने मला पूर्ण केले. मी टारंटूल घेतो.

पण तरीही…

आग्रही

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

अंमलबजावणी: Sberbank, American Airlines, Yahoo! जपान. आणि मग मला कळले की इग्नाइटची अंमलबजावणी फक्त Sberbank मध्येच केली जात नाही, तर SberTech टीम आपल्या लोकांना इग्नाइट टीमकडे उत्पादन परिष्कृत करण्यासाठी पाठवते. हे पूर्णपणे मोहक आहे आणि मी इग्नाइट घेण्यास तयार आहे.

हे का पूर्णपणे अस्पष्ट आहे, मी पाचव्या बिंदूकडे पहात आहे.

हेझेलकास्ट

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

बस्स, मी हेझेलकास्ट घ्यायला तयार आहे.

तुलना

पण बघितले तर पाचही उमेदवारांचे वर्णन अशा प्रकारे केले आहे की त्यातील प्रत्येक उमेदवार सर्वोत्कृष्ट आहे. कसे निवडायचे? कोणता सर्वात लोकप्रिय आहे ते आपण पाहू शकतो, तुलना पहा आणि डोकेदुखी दूर होईल.

आम्हाला असे एक सापडते पुनरावलोकन, आमच्या 5 प्रणाली निवडा.

येथे त्यांची क्रमवारी लावली आहे: रेडिस शीर्षस्थानी आहे, हेझेलकास्ट दुसर्‍या स्थानावर आहे, टारंटूल आणि इग्नाइट लोकप्रियता मिळवत आहेत, EhCache आहे आणि तशीच आहे.

पण बघूया गणना पद्धत: वेबसाइट्सच्या लिंक्स, सिस्टममध्ये सामान्य स्वारस्य, नोकरीच्या ऑफर - उत्तम! म्हणजेच, जेव्हा माझी प्रणाली अयशस्वी होईल, तेव्हा मी म्हणेन: “नाही, ते विश्वसनीय आहे! नोकरीच्या अनेक ऑफर आहेत..." अशी साधी तुलना करून चालणार नाही.

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

ठीक आहे, चला हार मानू नका, चला सिस्टमची थेट तुलना शोधूया. चला शीर्ष दोन पर्याय घेऊ - रेडिस आणि हेझेलकास्ट. आम्हाला वेगात स्वारस्य आहे आणि आम्ही या पॅरामीटरवर आधारित त्यांची तुलना करू.

Hz वि रेडिस

आम्हाला हे सापडते तुलना:


निळा रेडिस आहे, लाल हेझेलकास्ट आहे. Hazelcast सर्वत्र जिंकतो, आणि यासाठी एक तर्क आहे: तो मल्टी-थ्रेडेड, अत्यंत ऑप्टिमाइझ केलेला आहे, प्रत्येक थ्रेड त्याच्या स्वतःच्या विभाजनासह कार्य करतो, म्हणून कोणतेही अवरोधित नाहीत. आणि रेडिस सिंगल-थ्रेडेड आहे; आधुनिक मल्टी-कोर CPU चा फायदा होत नाही. Hazelcast मध्ये असिंक्रोनस I/O आहे, Redis-Jedis मध्ये ब्लॉकिंग सॉकेट आहेत. शेवटी, हेझेलकास्ट बायनरी प्रोटोकॉल वापरते आणि रेडिस मजकूर-केंद्रित आहे, याचा अर्थ ते अकार्यक्षम आहे.

फक्त बाबतीत, तुलनाच्या दुसर्या स्त्रोताकडे वळूया. तो आम्हाला काय दाखवेल?

रेडिस वि Hz

दुसरा तुलना:


येथे, त्याउलट, लाल म्हणजे रेडिस. म्हणजेच कामगिरीच्या बाबतीत रेडिसने हेजलकास्टला मागे टाकले आहे. हेझेलकास्टने पहिली तुलना जिंकली, रेडिसने दुसरी जिंकली. इथे हेझेलकास्टने मागील तुलना का जिंकली हे अगदी अचूकपणे स्पष्ट केले.

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

बाटली हलवत

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

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

ही पद्धत या उदाहरणासह अतिशय चांगल्या प्रकारे स्पष्ट केली आहे.

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

अशी एक पद्धत आहे, अतिशय जलद आणि अतिशय प्रभावी.

जहाजात छोट्या छोट्या गोष्टींचा समूह असतो: काठ्या, दोरी, पाल, गोंद. आम्ही हे सर्व एका बाटलीत ठेवतो.
आम्ही दोन्ही हातांनी बाटली घेतो आणि थरथरायला लागतो. आम्ही तिला झटकून टाकतो. आणि सहसा तो संपूर्ण कचरा निघतो, अर्थातच. पण कधी कधी. कधी ते जहाज निघाले! अधिक स्पष्टपणे, जहाजासारखे काहीतरी.

आम्ही हे एखाद्याला काहीतरी दाखवतो: "सरयोगा, तुला दिसतो का!" आणि खरंच, दुरून ते जहाजासारखे दिसते. पण हे चालू ठेवता येणार नाही.

दुसरा मार्ग आहे. ते हॅकर्ससारख्या अधिक प्रगत मुलांद्वारे वापरले जातात.

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

समस्या सेट करण्याच्या दृष्टिकोनातून, सर्वकाही योग्य असल्याचे दिसते. पण उदाहरण म्हणून जहाजे वापरणे: हे जहाज अजिबात का बनवायचे, तरीही त्याची कोणाला गरज आहे? हे कोणतीही कार्यक्षमता प्रदान करत नाही. सहसा अशी जहाजे खूप उच्च पदावरील लोकांसाठी भेटवस्तू असतात, जे ते त्यांच्या वरच्या शेल्फवर ठेवतात, काही प्रकारचे प्रतीक म्हणून, चिन्ह म्हणून. आणि जर असा माणूस, एखाद्या मोठ्या उद्योगाचा प्रमुख किंवा उच्चपदस्थ अधिकारी असेल तर, ज्याची मान कापली गेली आहे, अशा खाचखळग्यासाठी ध्वज कसा उभा राहणार? त्याला याबद्दल कधीच कळले नाही तर बरे होईल. मग, एखाद्या महत्त्वाच्या व्यक्तीला देऊ शकणारी ही जहाजे कशी बनवायची?

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

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

आमचा कॅशिंग सर्व्हर निवडण्याच्या कार्याकडे परत येत आहे, ही पद्धत कशी लागू केली जाऊ शकते? मी अस्तित्वात असलेल्या सर्व सिस्टममधून निवडण्याचा हा पर्याय ऑफर करतो - बाटली हलवू नका, निवडू नका, परंतु त्यांच्याकडे तत्त्वतः काय आहे ते पहा, सिस्टम निवडताना काय पहावे.

बाटली-मान कुठे शोधायचे

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

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

आम्हाला कोड लॉजिक (2) देखील आवश्यक आहे, जे प्रत्यक्षात कॅशिंगबद्दल आहे. क्लायंट काही API द्वारे या कोडशी संवाद साधतात. क्लायंट कोड (1) एकतर समान JVM मध्ये असू शकतो किंवा नेटवर्कवर प्रवेश करू शकतो. कॅशेमध्ये कोणत्या वस्तू सोडायच्या आणि कोणत्या बाहेर टाकायच्या याचा निर्णय आत लागू केलेले तर्कशास्त्र आहे. आम्ही कॅशे संचयित करण्यासाठी मेमरी (3) वापरतो, परंतु आवश्यक असल्यास, आम्ही डिस्कवर (4) काही डेटा जतन करू शकतो.

कोणत्या भागांमध्ये लोड होईल ते पाहूया. वास्तविक, प्रत्येक बाण आणि प्रत्येक नोड लोड केला जाईल. प्रथम, क्लायंट कोड आणि एपीआय दरम्यान, जर हे नेटवर्क संप्रेषण असेल, तर घट लक्षणीय असू शकते. दुसरे म्हणजे, एपीआयच्या चौकटीतच - जर आपण जटिल तर्काने ते जास्त केले तर आपल्याला सीपीयूमध्ये समस्या येऊ शकतात. आणि तर्काने स्मृतीवर वेळ वाया घालवला नाही तर छान होईल. आणि फाइल सिस्टमसह परस्परसंवाद कायम आहे - नेहमीच्या आवृत्तीमध्ये हे अनुक्रमांक / पुनर्संचयित आणि लिहा / वाचले जाते.

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

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

हेझेलकास्ट

हे विघटन आमच्या यादीत कसे लागू करायचे ते पाहू. उदाहरणार्थ, हेझेलकास्ट.

Hazelcast वरून डेटा ठेवण्यासाठी/घेण्यासाठी, क्लायंट कोड (1) api मध्ये प्रवेश करतो. Hz तुम्हाला एम्बेडेड म्हणून सर्व्हर चालवण्याची परवानगी देतो आणि या प्रकरणात, एपीआयमध्ये प्रवेश करणे हे JVM मध्ये एक पद्धत कॉल आहे, जे विनामूल्य मानले जाऊ शकते.

(2) मधील तर्क कार्य करण्यासाठी, Hz अनुक्रमित कीच्या बाइट अॅरेच्या हॅशवर अवलंबून असते - म्हणजेच की कोणत्याही परिस्थितीत अनुक्रमित केली जाईल. Hz साठी हे अपरिहार्य ओव्हरहेड आहे.
बेदखल करण्याच्या धोरणांची अंमलबजावणी चांगली केली जाते, परंतु विशेष प्रकरणांसाठी तुम्ही तुमची स्वतःची जोडू शकता. तुम्हाला या भागाची काळजी करण्याची गरज नाही.

स्टोरेज (4) कनेक्ट केले जाऊ शकते. मस्त. एम्बेडेडसाठी परस्परसंवाद (5) त्वरित मानले जाऊ शकते. क्लस्टर (6) मधील नोड्स दरम्यान डेटा एक्सचेंज - होय, ते अस्तित्वात आहे. गतीच्या खर्चावर फॉल्ट टॉलरन्समध्ये ही गुंतवणूक आहे. Hz वैशिष्ट्य Near-cache तुम्हाला किंमत कमी करण्यास अनुमती देते - क्लस्टरमधील इतर नोड्समधून प्राप्त केलेला डेटा कॅशे केला जाईल.

अशा परिस्थितीत वेग वाढवण्यासाठी काय करता येईल?

उदाहरणार्थ, (2) मधील कीचे अनुक्रमिकरण टाळण्यासाठी - सर्वात लोकप्रिय डेटासाठी, Hazelcast च्या वर दुसरी कॅशे संलग्न करा. स्पोर्टमास्टरने यासाठी कॅफिनची निवड केली.

लेव्हल (6) वर ट्विस्ट करण्यासाठी, Hz दोन प्रकारचे स्टोरेज ऑफर करते: IMap आणि ReplicatedMap.


हेझलकास्ट स्पोर्टमास्टर टेक्नॉलॉजी स्टॅकमध्ये कसे आले हे नमूद करण्यासारखे आहे.

2012 मध्ये, जेव्हा आम्ही भविष्यातील साइटच्या पहिल्या पायलटवर काम करत होतो, तेव्हा हेझलकास्ट शोध इंजिनने परत आलेला पहिला दुवा होता. ओळखीने “पहिल्यांदा” सुरुवात केली - फक्त दोन तासांनंतर जेव्हा आम्ही हर्ट्झला सिस्टममध्ये स्क्रू केले तेव्हा ते कार्य करते हे पाहून आम्ही मोहित झालो. आणि ते चांगले काम केले. दिवसाच्या अखेरीस आम्ही अनेक चाचण्या पूर्ण केल्या होत्या आणि आनंदी होतो. आणि हर्ट्झने कालांतराने फेकलेल्या आश्चर्यांवर मात करण्यासाठी जोमचा हा साठा पुरेसा होता. आता स्पोर्टमास्टर संघाकडे हेझेलकास्ट सोडण्याचे कोणतेही कारण नाही.

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

उत्पादनासाठी, अधिक महत्त्वाचे: निरीक्षण, वैयक्तिक नोड्सवरील अपयश हाताळणे, डेटा प्रतिकृती, स्केलिंगची किंमत. म्हणजेच, सिस्टमच्या देखरेखीदरम्यान उद्भवणार्या कार्यांकडे लक्ष देणे योग्य आहे - जेव्हा लोड नियोजितपेक्षा दहापट जास्त असेल, जेव्हा आम्ही चुकीच्या ठिकाणी काहीतरी अपलोड करतो, जेव्हा आम्हाला नवीन आवृत्ती रोल आउट करण्याची आवश्यकता असते. कोडचा, डेटा पुनर्स्थित करा आणि क्लायंटच्या लक्षात न आल्याने करा.

या सर्व आवश्यकतांसाठी, हेझेलकास्ट नक्कीच बिलात बसते.

पुढे चालू

पण हेझेलकास्ट हा रामबाण उपाय नाही. 2017 मध्ये, आम्ही प्रशासक कॅशेसाठी Hazelcast निवडले, फक्त मागील अनुभवातील चांगल्या छापांवर आधारित. याने अत्यंत क्रूर विनोदात महत्त्वाची भूमिका बजावली, ज्यामुळे आम्ही स्वतःला कठीण परिस्थितीत सापडलो आणि 60 दिवसांसाठी "वीरपणे" त्यातून बाहेर पडलो. पण त्याबद्दल अधिक पुढच्या भागात.

दरम्यान... नवीन कोडच्या शुभेच्छा!

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