VKontakte च्या आर्किटेक्चर आणि कामावर वारंवार विचारले जाणारे प्रश्न

व्हीकॉन्टाक्टेच्या निर्मितीचा इतिहास विकिपीडियावर आहे; हे पावेलने स्वतः सांगितले होते. असे दिसते की प्रत्येकजण तिला आधीच ओळखतो. HighLoad++ Pavel वर साइटच्या अंतर्गत, आर्किटेक्चर आणि संरचनेबद्दल मला 2010 मध्ये परत सांगितले. तेव्हापासून बरेच सर्व्हर लीक झाले आहेत, म्हणून आम्ही माहिती अद्यतनित करू: आम्ही त्याचे विच्छेदन करू, आतील भाग बाहेर काढू, त्याचे वजन करू आणि तांत्रिक दृष्टिकोनातून व्हीके डिव्हाइसकडे पाहू.

अलेक्सी अकुलोविच (AterCattus) VKontakte संघातील बॅकएंड विकसक. या अहवालाचा उतारा हा प्लॅटफॉर्म, पायाभूत सुविधा, सर्व्हर आणि त्यांच्यामधील परस्परसंवादाच्या कार्याबद्दल वारंवार विचारल्या जाणार्‍या प्रश्नांची एकत्रित उत्तरे आहे, परंतु विकासाबद्दल नाही, म्हणजे लोह बद्दल. स्वतंत्रपणे, डेटाबेस आणि त्याऐवजी व्हीकेकडे काय आहे, लॉग गोळा करणे आणि संपूर्ण प्रकल्पाचे निरीक्षण करणे याबद्दल स्वतंत्रपणे. कट अंतर्गत तपशील.

चार वर्षांहून अधिक काळ मी बॅकएंडशी संबंधित सर्व प्रकारच्या कार्ये हाताळत आहे.

• अपलोड करणे, संचयित करणे, प्रक्रिया करणे, मीडियाचे वितरण करणे: व्हिडिओ, थेट प्रवाह, ऑडिओ, फोटो, दस्तऐवज.
• इन्फ्रास्ट्रक्चर, प्लॅटफॉर्म, डेव्हलपर मॉनिटरिंग, लॉग, प्रादेशिक कॅशे, CDN, प्रोप्रायटरी RPC प्रोटोकॉल.
• बाह्य सेवांसह एकत्रीकरण: पुश सूचना, बाह्य दुवा पार्सिंग, RSS फीड.
• विविध प्रश्नांसह सहकार्यांना मदत करणे, ज्याच्या उत्तरांसाठी अज्ञात कोडमध्ये डुबकी मारणे आवश्यक आहे.

या वेळी, साइटच्या अनेक घटकांमध्ये माझा हात होता. मला हा अनुभव शेअर करायचा आहे.

सामान्य आर्किटेक्चर

सर्व काही, नेहमीप्रमाणे, सर्व्हर किंवा सर्व्हरच्या गटाने सुरू होते जे विनंत्या स्वीकारतात.

समोर सर्व्हर

समोरचा सर्व्हर HTTPS, RTMP आणि WSS द्वारे विनंत्या स्वीकारतो.

HTTPS - या साइटच्या मुख्य आणि मोबाइल वेब आवृत्त्यांसाठी विनंत्या आहेत: vk.com आणि m.vk.com, आणि आमच्या API चे इतर अधिकृत आणि अनधिकृत क्लायंट: मोबाइल क्लायंट, मेसेंजर. आमच्याकडे रिसेप्शन आहे आरटीएमपी- वेगळ्या फ्रंट सर्व्हरसह थेट प्रसारणासाठी रहदारी आणि WSS- स्ट्रीमिंग API साठी कनेक्शन.

सर्व्हरवरील HTTPS आणि WSS साठी ते किमतीचे आहे nginx. RTMP प्रसारणासाठी, आम्ही अलीकडेच आमच्या स्वतःच्या सोल्यूशनवर स्विच केले kive, परंतु ते अहवालाच्या व्याप्तीच्या पलीकडे आहे. दोष सहिष्णुतेसाठी, हे सर्व्हर सामान्य IP पत्त्यांची जाहिरात करतात आणि गटांमध्ये कार्य करतात जेणेकरून एखाद्या सर्व्हरवर समस्या असल्यास, वापरकर्त्याच्या विनंत्या गमावल्या जाणार नाहीत. HTTPS आणि WSS साठी, हेच सर्व्हर CPU लोडचा भाग स्वतःवर घेण्यासाठी रहदारी एन्क्रिप्ट करतात.

आम्ही WSS आणि RTMP बद्दल पुढे बोलणार नाही, परंतु फक्त मानक HTTPS विनंत्यांबद्दल, जे सहसा वेब प्रोजेक्टशी संबंधित असतात.

बॅकएंड

समोरच्या मागे सहसा बॅकएंड सर्व्हर असतात. ते समोरच्या सर्व्हरला क्लायंटकडून प्राप्त झालेल्या विनंत्यांवर प्रक्रिया करतात.

या kPHP सर्व्हर, ज्यावर HTTP डिमन चालू आहे, कारण HTTPS आधीच डिक्रिप्ट केलेले आहे. kPHP एक सर्व्हर आहे जो चालतो प्रीफोर्क मॉडेल्स: एक मास्टर प्रक्रिया सुरू करते, मुलांच्या प्रक्रियेचा एक समूह, त्यांना ऐकण्याचे सॉकेट पास करते आणि ते त्यांच्या विनंतीवर प्रक्रिया करतात. या प्रकरणात, वापरकर्त्याच्या प्रत्येक विनंती दरम्यान प्रक्रिया रीस्टार्ट केल्या जात नाहीत, परंतु त्यांची स्थिती मूळ शून्य-मूल्य स्थितीवर रीसेट करा - विनंतीनंतर विनंती, रीस्टार्ट करण्याऐवजी.

लोड वितरण

आमचे सर्व बॅकएंड हे कोणत्याही विनंतीवर प्रक्रिया करू शकणार्‍या मशीन्सचा एक मोठा पूल नाही. आम्ही त्यांना स्वतंत्र गटांमध्ये विभागले गेले: सामान्य, मोबाइल, एपीआय, व्हिडिओ, स्टेजिंग... मशीनच्या वेगळ्या गटावरील समस्या इतर सर्वांवर परिणाम करणार नाही. व्हिडिओमध्ये समस्या असल्यास, संगीत ऐकणाऱ्या वापरकर्त्याला समस्यांबद्दल देखील माहिती नसते. कोणत्या बॅकएंडला विनंती पाठवायची हे कॉन्फिगरेशननुसार समोरील nginx द्वारे ठरवले जाते.

मेट्रिक संकलन आणि पुनर्संतुलन

प्रत्येक गटात किती कार असणे आवश्यक आहे हे समजून घेण्यासाठी, आम्ही QPS वर अवलंबून राहू नका. बॅकएंड भिन्न आहेत, त्यांच्या विनंत्या वेगळ्या आहेत, प्रत्येक विनंतीमध्ये QPS मोजण्याची भिन्न जटिलता आहे. म्हणूनच आम्ही आम्ही संपूर्णपणे सर्व्हरवर लोड या संकल्पनेसह कार्य करतो - CPU आणि perf वर.

आमच्याकडे असे हजारो सर्व्हर आहेत. प्रत्येक भौतिक सर्व्हर सर्व कोर रीसायकल करण्यासाठी kPHP गट चालवतो (कारण kPHP सिंगल थ्रेडेड आहे).

सामग्री सर्व्हर

CS किंवा सामग्री सर्व्हर एक स्टोरेज आहे. CS हा एक सर्व्हर आहे जो फायली संचयित करतो आणि अपलोड केलेल्या फायली आणि सर्व प्रकारच्या पार्श्वभूमी सिंक्रोनस कार्यांवर प्रक्रिया करतो जे मुख्य वेब फ्रंटएंड त्यास नियुक्त करते.

आमच्याकडे हजारो फिजिकल सर्व्हर आहेत जे फाइल्स साठवतात. वापरकर्त्यांना फाइल्स अपलोड करायला आवडतात आणि आम्हाला त्या संग्रहित आणि शेअर करायला आवडतात. यापैकी काही सर्व्हर विशेष pu/pp सर्व्हरद्वारे बंद केले जातात.

pu/pp

जर तुम्ही व्हीके मध्ये नेटवर्क टॅब उघडला, तर तुम्हाला pu/pp दिसला.

pu/pp म्हणजे काय? आम्ही एकामागून एक सर्व्हर बंद केल्यास, बंद केलेल्या सर्व्हरवर फाइल अपलोड आणि डाउनलोड करण्यासाठी दोन पर्याय आहेत: थेट माध्यमातून http://cs100500.userapi.com/path किंवा इंटरमीडिएट सर्व्हरद्वारे - http://pu.vk.com/c100500/path.

पु हे फोटो अपलोडचे ऐतिहासिक नाव आहे आणि pp फोटो प्रॉक्सी आहे. म्हणजेच, एक सर्व्हर फोटो अपलोड करण्यासाठी आहे आणि दुसरा अपलोड करण्यासाठी आहे. आता केवळ फोटोच लोड केले जात नाहीत, तर नावही जपले गेले आहे.

हे सर्व्हर HTTPS सत्रे बंद करास्टोरेजमधून प्रोसेसर लोड काढून टाकण्यासाठी. तसेच, वापरकर्त्याच्या फाइल्सवर या सर्व्हरवर प्रक्रिया केली जात असल्याने, या मशीनवर जितकी कमी संवेदनशील माहिती साठवली जाईल तितकी चांगली. उदाहरणार्थ, HTTPS एन्क्रिप्शन की.

आमच्या इतर मशिन्सद्वारे मशीन बंद असल्याने, आम्ही त्यांना "पांढरे" बाह्य IP देऊ शकत नाही आणि "राखाडी" द्या. अशा प्रकारे आम्ही आयपी पूलवर बचत केली आणि मशीन्सना बाहेरील प्रवेशापासून संरक्षित करण्याची हमी दिली - त्यात प्रवेश करण्यासाठी कोणताही आयपी नाही.

सामायिक केलेल्या IP वर लवचिकता. दोष सहिष्णुतेच्या बाबतीत, योजना समान कार्य करते - अनेक भौतिक सर्व्हरमध्ये सामान्य भौतिक IP असतो आणि त्यांच्या समोरील हार्डवेअर विनंती कुठे पाठवायची ते निवडते. मी नंतर इतर पर्यायांबद्दल बोलेन.

वादग्रस्त मुद्दा असा आहे की या प्रकरणात क्लायंट कमी कनेक्शन ठेवतो. अनेक मशीन्ससाठी समान आयपी असल्यास - समान होस्टसह: pu.vk.com किंवा pp.vk.com, क्लायंट ब्राउझरला एका होस्टला एकाचवेळी विनंत्या करण्याची मर्यादा असते. परंतु सर्वव्यापी HTTP/2 च्या काळात, माझा विश्वास आहे की हे आता इतके संबंधित नाही.

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

काही काळापूर्वी आम्हाला प्रॉक्सीची सुधारित आवृत्ती मिळाली. आता मी तुम्हाला सांगेन की ते सामान्य लोकांपेक्षा कसे वेगळे आहेत आणि हे का आवश्यक आहे.

सूर्य

सप्टेंबर 2017 मध्ये, ओरॅकल, ज्याने यापूर्वी सन विकत घेतला होता, सन कर्मचाऱ्यांना मोठ्या संख्येने काढून टाकले. आम्ही असे म्हणू शकतो की या क्षणी कंपनीचे अस्तित्व संपले आहे. नवीन प्रणालीसाठी नाव निवडताना, आमच्या प्रशासकांनी या कंपनीच्या स्मृतीस श्रद्धांजली वाहण्याचे ठरवले आणि नवीन सिस्टमला सूर्य असे नाव दिले. आपापसात आम्ही तिला फक्त "सूर्य" म्हणतो.

pp ला काही समस्या होत्या. प्रति गट एक आयपी - अप्रभावी कॅशे. अनेक भौतिक सर्व्हर एक सामान्य IP पत्ता सामायिक करतात आणि विनंती कोणत्या सर्व्हरवर जाईल हे नियंत्रित करण्याचा कोणताही मार्ग नाही. म्हणून, जर एकाच फाइलसाठी भिन्न वापरकर्ते आले, तर या सर्व्हरवर कॅशे असल्यास, फाइल प्रत्येक सर्व्हरच्या कॅशेमध्ये संपते. ही अतिशय कुचकामी योजना आहे, परंतु काहीही करता आले नाही.

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

सूर्याबरोबर आम्ही निवड पद्धतीत बदल केला. आता आमच्याकडे आहे anycast राउटिंग: डायनॅमिक राउटिंग, anycast, सेल्फ-चेक डिमन. प्रत्येक सर्व्हरचा स्वतःचा वैयक्तिक IP असतो, परंतु एक सामान्य सबनेट असतो. सर्व काही अशा प्रकारे कॉन्फिगर केले आहे की एक सर्व्हर अयशस्वी झाल्यास, रहदारी त्याच गटाच्या इतर सर्व्हरवर आपोआप पसरते. आता विशिष्ट सर्व्हर निवडणे शक्य आहे, अनावश्यक कॅशिंग नाही, आणि विश्वसनीयता प्रभावित झाली नाही.

वजन आधार. आता आम्ही आवश्यकतेनुसार वेगवेगळ्या शक्तीची मशीन स्थापित करू शकतो आणि तात्पुरत्या समस्यांच्या बाबतीत, कार्यरत "सूर्य" चे वजन बदलून त्यांच्यावरील भार कमी करू शकतो, जेणेकरून ते "विश्रांती" घेतील आणि पुन्हा काम करण्यास सुरवात करतील.

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

आम्ही अलीकडेच “क्लोव्हर” ऍप्लिकेशन लाँच केले. ही थेट प्रक्षेपणातील ऑनलाइन क्विझ आहे, जिथे होस्ट प्रश्न विचारतो आणि वापरकर्ते रिअल टाइममध्ये पर्याय निवडून उत्तर देतात. अॅपमध्ये एक चॅट आहे जिथे वापरकर्ते चॅट करू शकतात. एकाच वेळी प्रसारणाशी कनेक्ट होऊ शकते 100 हजाराहून अधिक लोक. ते सर्व मेसेज लिहितात जे सर्व सहभागींना पाठवले जातात आणि संदेशासोबत अवतार येतो. जर 100 हजार लोक एका "सूर्य" मध्ये एका अवतारासाठी येतात, तर ते कधीकधी ढगाच्या मागे फिरू शकतात.

एकाच फाईलच्या विनंत्यांचा सामना करण्यासाठी, विशिष्ट प्रकारच्या सामग्रीसाठी आम्ही एक मूर्ख योजना चालू करतो जी फायली सर्व उपलब्ध "सूर्य" मध्ये पसरवते.

आतून सूर्य

nginx वर रिव्हर्स प्रॉक्सी, कॅशे एकतर RAM मध्ये किंवा फास्ट Optane/NVMe डिस्कवर. उदाहरण: http://sun4-2.userapi.com/c100500/path — “सूर्य” चा दुवा, जो चौथ्या प्रदेशात स्थित आहे, दुसरा सर्व्हर गट. हे पाथ फाइल बंद करते, जी भौतिकरित्या सर्व्हर 100500 वर असते.

कव्हर

आम्ही आमच्या आर्किटेक्चरल स्कीममध्ये आणखी एक नोड जोडतो - कॅशिंग वातावरण.

खाली लेआउट आकृती आहे प्रादेशिक कॅशे, त्यापैकी सुमारे 20 आहेत. ही अशी ठिकाणे आहेत जिथे कॅशे आणि "सूर्य" आहेत, जे स्वतःहून रहदारी कॅशे करू शकतात.

हे मल्टीमीडिया सामग्रीचे कॅशिंग आहे; येथे कोणताही वापरकर्ता डेटा संग्रहित नाही - फक्त संगीत, व्हिडिओ, फोटो.

वापरकर्त्याचा प्रदेश निश्चित करण्यासाठी, आम्ही आम्ही प्रदेशांमध्ये घोषित केलेले BGP नेटवर्क उपसर्ग गोळा करतो. फॉलबॅकच्या बाबतीत, जर आम्हाला उपसर्गांद्वारे IP सापडला नाही तर आम्हाला geoip डेटाबेसचे विश्लेषण देखील करावे लागेल. आम्ही वापरकर्त्याच्या IP द्वारे प्रदेश निर्धारित करतो. कोडमध्ये, आम्ही वापरकर्त्याचे एक किंवा अधिक क्षेत्र पाहू शकतो - ते बिंदू ज्याच्या भौगोलिकदृष्ट्या तो सर्वात जवळ आहे.

ते कसे कार्य करते?

आम्ही प्रदेशानुसार फायलींची लोकप्रियता मोजतो. वापरकर्ता जेथे स्थित आहे तेथे अनेक प्रादेशिक कॅशे आणि फाइल आयडेंटिफायर आहे - आम्ही ही जोडी घेतो आणि प्रत्येक डाउनलोडसह रेटिंग वाढवतो.

त्याच वेळी, भुते - क्षेत्रांमधील सेवा - वेळोवेळी API वर येतात आणि म्हणतात: “मी असा आणि असा कॅशे आहे, मला माझ्या प्रदेशातील सर्वात लोकप्रिय फायलींची यादी द्या ज्या अद्याप माझ्यावर नाहीत. " API रेटिंगनुसार क्रमवारी लावलेल्या फायलींचा समूह वितरीत करतो, डिमन त्यांना डाउनलोड करतो, प्रदेशात घेऊन जातो आणि तेथून फायली वितरीत करतो. pu/pp आणि सन मधील कॅशेमधला हा मूलभूत फरक आहे: ही फाइल कॅशेमध्ये नसली तरीही ते लगेच स्वतःद्वारे फाइल देतात आणि कॅशे प्रथम फाइल स्वतः डाउनलोड करते आणि नंतर ती परत देण्यास सुरुवात करते.

या प्रकरणात आम्हाला मिळते वापरकर्त्यांच्या जवळची सामग्री आणि नेटवर्क लोड पसरवणे. उदाहरणार्थ, केवळ मॉस्को कॅशेमधून आम्ही पीक अवर्समध्ये 1 Tbit/s पेक्षा जास्त वितरित करतो.

पण समस्या आहेत - कॅशे सर्व्हर रबर नाहीत. सुपर लोकप्रिय सामग्रीसाठी, कधीकधी वेगळ्या सर्व्हरसाठी पुरेसे नेटवर्क नसते. आमचे कॅशे सर्व्हर 40-50 Gbit/s आहेत, परंतु अशी सामग्री आहे जी अशा चॅनेलला पूर्णपणे बंद करते. आम्ही या प्रदेशातील लोकप्रिय फायलींच्या एकापेक्षा जास्त प्रतींचे संचयन लागू करण्याच्या दिशेने वाटचाल करत आहोत. मला आशा आहे की आम्ही वर्षाच्या अखेरीस त्याची अंमलबजावणी करू.

आम्ही सामान्य वास्तुकला पाहिली.

• विनंत्या स्वीकारणारे फ्रंट सर्व्हर.
• विनंत्यांची प्रक्रिया करणारे बॅकएंड.
• दोन प्रकारच्या प्रॉक्सीद्वारे बंद केलेले स्टोरेज.
• प्रादेशिक कॅशे.

या चित्रात काय गहाळ आहे? अर्थात ज्या डेटाबेसमध्ये आपण डेटा साठवतो.

डेटाबेस किंवा इंजिन

आम्ही त्यांना डेटाबेस नाही, परंतु इंजिन - इंजिन म्हणतो, कारण आमच्याकडे सामान्यतः स्वीकारल्या जाणार्‍या अर्थाने डेटाबेस नसतात.

हा एक आवश्यक उपाय आहे. हे घडले कारण 2008-2009 मध्ये, जेव्हा व्हीकेच्या लोकप्रियतेत स्फोटक वाढ झाली होती, तेव्हा प्रकल्प पूर्णपणे MySQL आणि Memcache वर काम करत होता आणि काही समस्या होत्या. MySQL ला फाईल्स क्रॅश करणे आणि दूषित करणे आवडते, त्यानंतर ते पुनर्प्राप्त होणार नाही, आणि Memcache हळूहळू कार्यक्षमतेत खराब झाले आणि पुन्हा सुरू करावे लागले.

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

तोडगा यशस्वी झाला. हे करण्याची संधी होती, तसेच एक अत्यंत आवश्यकता होती, कारण त्या वेळी स्केलिंगचे इतर मार्ग अस्तित्वात नव्हते. तेथे डेटाबेसचा एक समूह नव्हता, NoSQL अद्याप अस्तित्वात नव्हते, फक्त MySQL, Memcache, PostrgreSQL होते - आणि तेच.

युनिव्हर्सल ऑपरेशन. विकासाचे नेतृत्व आमच्या C विकासकांच्या टीमने केले आणि सर्व काही सुसंगतपणे केले गेले. इंजिनची पर्वा न करता, त्या सर्वांचे डिस्कवर अंदाजे समान फाइल स्वरूप लिहिलेले होते, समान लॉन्च पॅरामीटर्स, त्याच प्रकारे प्रक्रिया केलेले सिग्नल आणि किनारी परिस्थिती आणि समस्यांच्या बाबतीत अंदाजे समान वर्तन होते. इंजिनच्या वाढीसह, प्रशासकांना सिस्टम ऑपरेट करणे सोयीचे आहे - तेथे कोणतेही प्राणीसंग्रहालय नाही ज्याची देखभाल करणे आवश्यक आहे आणि त्यांना प्रत्येक नवीन तृतीय-पक्ष डेटाबेस कसा ऑपरेट करायचा हे पुन्हा शिकावे लागेल, ज्यामुळे ते जलद आणि सोयीस्करपणे वाढवणे शक्य झाले. त्यांची संख्या.

इंजिनचे प्रकार

संघाने बरीच इंजिने लिहिली. त्यापैकी काही येथे आहेत: मित्र, इशारे, प्रतिमा, ipdb, अक्षरे, याद्या, लॉग, memcached, meowdb, बातम्या, nostradamus, फोटो, प्लेलिस्ट, pmemcached, सँडबॉक्स, शोध, संचयन, आवडी, कार्ये, …

प्रत्येक कार्यासाठी ज्यासाठी विशिष्ट डेटा संरचना आवश्यक आहे किंवा विशिष्ट विनंत्यांवर प्रक्रिया केली जाते, C कार्यसंघ नवीन इंजिन लिहितो. का नाही.

आमच्याकडे स्वतंत्र इंजिन आहे memcached, जे नियमित सारखेच आहे, परंतु गुडीच्या गुच्छांसह, आणि जे कमी होत नाही. क्लिकहाऊस नाही, परंतु ते देखील कार्य करते. स्वतंत्रपणे उपलब्ध pmemcached - हे आहे सतत memcached, जे डिस्कवर डेटा देखील संचयित करू शकते, शिवाय, RAM मध्ये बसण्यापेक्षा, रीस्टार्ट करताना डेटा गमावू नये म्हणून. वैयक्तिक कार्यांसाठी विविध इंजिन आहेत: रांगा, याद्या, संच - आमच्या प्रकल्पासाठी आवश्यक असलेली प्रत्येक गोष्ट.

क्लस्टर्स

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

कोडला भौतिक स्थान, आकार किंवा सर्व्हरची संख्या अजिबात माहित असणे आवश्यक नाही. तो विशिष्ट अभिज्ञापक वापरून क्लस्टरमध्ये जातो.

हे कार्य करण्यासाठी, तुम्हाला आणखी एक घटक जोडण्याची आवश्यकता आहे जी कोड आणि इंजिन दरम्यान स्थित आहे - प्रॉक्सी.

RPC प्रॉक्सी

प्रॉक्सी जोडणारी बस, ज्यावर जवळजवळ संपूर्ण साइट चालते. त्याच वेळी आमच्याकडे आहे सेवा शोध नाही — त्याऐवजी, या प्रॉक्सीसाठी एक कॉन्फिगरेशन आहे, ज्याला या क्लस्टरचे सर्व क्लस्टर आणि सर्व शार्ड्सचे स्थान माहित आहे. अ‍ॅडमिन्स हेच करतात.

प्रोग्रामर किती, कुठे आणि काय खर्च करतात याची अजिबात काळजी घेत नाहीत - ते फक्त क्लस्टरमध्ये जातात. हे आम्हाला खूप अनुमती देते. विनंती प्राप्त करताना, प्रॉक्सी विनंती पुनर्निर्देशित करते, कोठे हे जाणून घेते - हे स्वतःच ठरवते.

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

विशिष्ट अंमलबजावणी

कधीकधी आम्हाला इंजिन म्हणून काही प्रकारचे गैर-मानक समाधान हवे असते. त्याच वेळी, आमच्या इंजिनसाठी विशेषतः तयार केलेली आमची रेडीमेड आरपीसी-प्रॉक्सी न वापरण्याचा निर्णय घेण्यात आला, परंतु कार्यासाठी स्वतंत्र प्रॉक्सी बनवण्याचा निर्णय घेण्यात आला.

MySQL साठी, जे आमच्याकडे अजूनही इथे आणि तिथे आहे, आम्ही db-proxy वापरतो, आणि ClickHouse साठी - किटनहाऊस.

हे सर्वसाधारणपणे असे कार्य करते. एक विशिष्ट सर्व्हर आहे, तो kPHP, Go, Python चालवतो - सर्वसाधारणपणे, कोणताही कोड जो आमचा RPC प्रोटोकॉल वापरू शकतो. कोड स्थानिकरीत्या RPC प्रॉक्सीवर चालतो - प्रत्येक सर्व्हर जिथे कोड स्थित आहे त्याची स्वतःची स्थानिक प्रॉक्सी चालवते. विनंती केल्यावर, प्रॉक्सी कुठे जायचे हे समजते.

एका इंजिनला दुसर्‍याकडे जायचे असेल, जरी ते शेजारी असले तरी ते प्रॉक्सीद्वारे जाते, कारण शेजारी दुसर्‍या डेटा सेंटरमध्ये असू शकतो. इंजिनने स्वतःशिवाय इतर कोणत्याही गोष्टीचे स्थान जाणून घेण्यावर अवलंबून राहू नये - हे आमचे मानक उपाय आहे. पण अपवाद नक्कीच आहेत :)

TL-योजनेचे उदाहरण ज्यानुसार सर्व इंजिन चालतात.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

हा एक बायनरी प्रोटोकॉल आहे, ज्याचा सर्वात जवळचा अॅनालॉग आहे प्रोटोबफ स्कीमा पर्यायी फील्ड, जटिल प्रकार - बिल्ट-इन स्केलरचे विस्तार आणि क्वेरीचे वर्णन करते. सर्व काही या प्रोटोकॉलनुसार कार्य करते.

TCP/UDP वर TL वर RPC… UDP?

आमच्याकडे इंजिन विनंत्या अंमलात आणण्यासाठी एक RPC प्रोटोकॉल आहे जो TL योजनेच्या वर चालतो. हे सर्व TCP/UDP कनेक्शनवर कार्य करते. टीसीपी समजण्यासारखा आहे, परंतु आम्हाला वारंवार यूडीपी का आवश्यक आहे?

UDP मदत करते सर्व्हर दरम्यान मोठ्या संख्येने कनेक्शनची समस्या टाळा. जर प्रत्येक सर्व्हरमध्ये RPC प्रॉक्सी असेल आणि सर्वसाधारणपणे, ते कोणत्याही इंजिनवर जाऊ शकते, तर प्रत्येक सर्व्हरवर हजारो TCP कनेक्शन आहेत. एक भार आहे, परंतु ते निरुपयोगी आहे. UDP च्या बाबतीत ही समस्या अस्तित्वात नाही.

अनावश्यक TCP हँडशेक नाही. ही एक सामान्य समस्या आहे: जेव्हा नवीन इंजिन किंवा नवीन सर्व्हर लॉन्च केला जातो, तेव्हा अनेक TCP कनेक्शन एकाच वेळी स्थापित केले जातात. लहान लाइटवेट विनंत्यांसाठी, उदाहरणार्थ, UDP पेलोड, कोड आणि इंजिनमधील सर्व संप्रेषण आहे दोन UDP पॅकेट: एक एका दिशेने उडतो, दुसरा दुसऱ्या दिशेने. एक फेरी - आणि कोडला हँडशेकशिवाय इंजिनकडून प्रतिसाद मिळाला.

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

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

सतत डेटा स्टोरेज

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

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

मी त्वरीत ऑपरेशनच्या तत्त्वाचे वर्णन करेन. एक सर्व्हर आहे ज्यावर इंजिन चालते. तो लिहिण्यासाठी एक नवीन रिकामा बिनलॉग उघडतो आणि त्यात बदल करण्यासाठी इव्हेंट लिहितो.

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

काही क्षणी, जेव्हा इंजिन रीस्टार्ट होईल, तेव्हा डिस्कवर बिनलॉग आणि स्नॅपशॉट दोन्ही असतील. इंजिन संपूर्ण स्नॅपशॉट वाचते आणि एका विशिष्ट टप्प्यावर त्याची स्थिती वाढवते.

स्नॅपशॉट तयार करतानाची स्थिती आणि बिनलॉगचा आकार वाचतो.

सद्यस्थिती जाणून घेण्यासाठी बिनलॉगचा शेवट वाचतो आणि पुढील घटना लिहिणे सुरू ठेवतो. ही एक सोपी योजना आहे; आमची सर्व इंजिने त्यानुसार कार्य करतात.

डेटा प्रतिकृती

परिणामी, आमच्या मध्ये डेटा प्रतिकृती विधान-आधारित - आम्ही बिनलॉगमध्ये कोणतेही पृष्ठ बदलत नाही, परंतु नावाने लिहितो विनंत्या बदला. नेटवर्कवर जे येते त्यासारखेच, फक्त थोडे सुधारित.

समान योजना केवळ प्रतिकृतीसाठीच नव्हे तर वापरली जाते बॅकअप तयार करण्यासाठी. आमच्याकडे एक इंजिन आहे - एक लेखन मास्टर जो बिनलॉगवर लिहितो. इतर कोणत्याही ठिकाणी जेथे प्रशासकांनी ते सेट केले आहे, हा बिनलॉग कॉपी केला जातो आणि तेच - आमच्याकडे बॅकअप आहे.

गरज असल्यास वाचन प्रतिकृतीCPU वाचन भार कमी करण्यासाठी, रीडिंग इंजिन फक्त लाँच केले जाते, जे बिनलॉगचा शेवट वाचते आणि या कमांडस स्थानिक पातळीवर कार्यान्वित करते.

येथे अंतर खूपच लहान आहे आणि प्रतिकृती मास्टरच्या मागे किती आहे हे शोधणे शक्य आहे.

RPC प्रॉक्सीमध्ये डेटा शार्डिंग

शार्डिंग कसे कार्य करते? कोणत्या क्लस्टर शार्डला पाठवायचे हे प्रॉक्सीला कसे समजते? कोड असे म्हणत नाही: "15 शार्ड्ससाठी पाठवा!" - नाही, हे प्रॉक्सीद्वारे केले जाते.

सर्वात सोपी योजना प्रथम आहे - विनंतीमधील पहिला क्रमांक.

get(photo100_500) => 100 % N.

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

जेव्हा आम्हाला एकाच घटकाची डेटा लोकॅलिटी हवी असते तेव्हा हे उपयुक्त ठरते. समजा 100 हा वापरकर्ता किंवा गट आयडी आहे आणि आम्हाला जटिल प्रश्नांसाठी एका घटकाचा सर्व डेटा एका शार्डवर हवा आहे.

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

hash(photo100_500) => 3539886280 % N

आम्हाला हॅश, विभागाचा उर्वरित भाग आणि शार्ड क्रमांक देखील मिळतो.

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

आम्हाला अनियंत्रित सर्व्हर जोडण्याची किंवा काढून टाकण्याची आवश्यकता असल्यास, आम्ही वापरतो रिंग अ ला केटामा वर सातत्यपूर्ण हॅशिंग. परंतु त्याच वेळी, आम्ही डेटाचे स्थान पूर्णपणे गमावतो; आम्हाला क्लस्टरमध्ये विनंती विलीन करावी लागेल जेणेकरून प्रत्येक तुकडा स्वतःचा छोटा प्रतिसाद देईल आणि नंतर प्रॉक्सीमध्ये प्रतिसाद विलीन करेल.

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

नोंदी

आम्ही अनेक प्रकारे लॉग लिहितो. सर्वात स्पष्ट आणि सोपे आहे memcache वर लॉग लिहा.

ring-buffer: prefix.idx = line

एक प्रमुख उपसर्ग आहे - लॉगचे नाव, एक ओळ आणि या लॉगचा आकार आहे - ओळींची संख्या. आम्ही 0 पासून ओळींच्या संख्येत वजा 1 पर्यंत एक यादृच्छिक संख्या घेतो. मेमकॅशेमधील की हा यादृच्छिक संख्येसह जोडलेला एक उपसर्ग आहे. आम्ही लॉग लाइन आणि वर्तमान वेळ मूल्यामध्ये जतन करतो.

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

लॉगच्या विश्वसनीय स्टोरेजसाठी आमच्याकडे इंजिन आहे लॉग-इंजिन. म्हणूनच ते तयार केले गेले आणि मोठ्या प्रमाणात क्लस्टर्समध्ये वापरले जाते. मला माहीत असलेला सर्वात मोठा क्लस्टर 600 TB पॅक लॉग स्टोअर करतो.

इंजिन खूप जुने आहे, तेथे क्लस्टर आहेत जे आधीच 6-7 वर्षे जुने आहेत. त्यात काही समस्या आहेत ज्यांचे निराकरण करण्याचा आम्ही प्रयत्न करीत आहोत, उदाहरणार्थ, आम्ही लॉग संग्रहित करण्यासाठी क्लिकहाऊस सक्रियपणे वापरण्यास सुरुवात केली.

क्लिकहाऊसमध्ये नोंदी गोळा करणे

हे आकृती दाखवते की आपण आपल्या इंजिनमध्ये कसे फिरतो.

असा कोड आहे जो स्थानिकरित्या RPC द्वारे RPC-प्रॉक्सीकडे जातो आणि इंजिनला कुठे जायचे ते समजते. जर आम्हाला क्लिकहाऊसमध्ये लॉग लिहायचे असतील, तर आम्हाला या योजनेत दोन भाग बदलावे लागतील:

• क्लिकहाऊससह काही इंजिन पुनर्स्थित करा;
• RPC प्रॉक्सी पुनर्स्थित करा, जे क्लिकहाऊसमध्ये प्रवेश करू शकत नाही, काही उपायांसह आणि RPC द्वारे.

इंजिन सोपे आहे - आम्ही त्यास सर्व्हर किंवा क्लिकहाऊससह सर्व्हरच्या क्लस्टरने बदलतो.

आणि क्लिकहाऊसवर जाण्यासाठी, आम्ही केले किटनहाऊस. आम्ही थेट KittenHouse वरून ClickHouse वर गेलो, तर त्याचा सामना होणार नाही. विनंत्या नसतानाही, ते मोठ्या संख्येने मशीनच्या HTTP कनेक्शनमधून जोडते. योजना कार्य करण्यासाठी, क्लिकहाऊससह सर्व्हरवर स्थानिक रिव्हर्स प्रॉक्सी वाढवली आहे, जे अशा प्रकारे लिहिलेले आहे की ते कनेक्शनच्या आवश्यक खंडांचा सामना करू शकेल. ते तुलनेने विश्वासार्हपणे स्वतःमधील डेटा बफर देखील करू शकते.

काहीवेळा आम्ही आरपीसी योजना नॉन-स्टँडर्ड सोल्यूशन्समध्ये लागू करू इच्छित नाही, उदाहरणार्थ, nginx मध्ये. म्हणून, KittenHouse मध्ये UDP द्वारे लॉग प्राप्त करण्याची क्षमता आहे.

लॉग प्रेषक आणि प्राप्तकर्ता एकाच मशीनवर काम करत असल्यास, स्थानिक होस्टमध्ये UDP पॅकेट गमावण्याची शक्यता खूपच कमी आहे. तृतीय-पक्ष समाधान आणि विश्वासार्हतेमध्ये RPC लागू करण्याची गरज यांच्यातील तडजोड म्हणून, आम्ही फक्त UDP पाठवणे वापरतो. आम्ही नंतर या योजनेकडे परत येऊ.

देखरेख

आमच्याकडे दोन प्रकारचे लॉग आहेत: प्रशासकांनी त्यांच्या सर्व्हरवर गोळा केलेले आणि कोडमधून विकसकांनी लिहिलेले. ते दोन प्रकारच्या मेट्रिक्सशी संबंधित आहेत: प्रणाली आणि उत्पादन.

सिस्टम मेट्रिक्स

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

उत्पादन मेट्रिक्स

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

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

त्यानंतर, आम्ही सॉर्टिंग आणि ग्रुपिंग फिल्टर्स वापरू शकतो आणि आकडेवारीवरून आम्हाला हवे ते सर्व करू शकतो - आलेख तयार करा, वॉचडॉग कॉन्फिगर करा.

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

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

आवश्यक असल्यास, आम्ही लॉग-कलेक्टरला थेट लिहू शकतो.

परंतु कोडमधून थेट संग्राहकांपर्यंत लिहिणे, स्टॅस-डेमॉमला मागे टाकून, एक खराब प्रमाणात मोजता येण्याजोगा उपाय आहे कारण यामुळे कलेक्टरवरील भार वाढतो. जर काही कारणास्तव आम्ही मशीनवर मेमकॅशे स्टॅट्स-डिमन वाढवू शकत नाही किंवा तो क्रॅश झाला आणि आम्ही थेट गेलो तरच उपाय योग्य आहे.

पुढे, लॉग-कलेक्टर आकडेवारी यात विलीन करतात meowDB - हा आमचा डेटाबेस आहे, जो मेट्रिक्स देखील संग्रहित करू शकतो.

मग आपण कोडमधून बायनरी "जवळ-एसक्यूएल" निवडू शकतो.

प्रयोग

2018 च्या उन्हाळ्यात, आमच्याकडे अंतर्गत हॅकाथॉन होते, आणि आकृतीचा लाल भाग क्लिकहाऊसमध्ये मेट्रिक्स संचयित करू शकतील अशा गोष्टीसह बदलण्याचा प्रयत्न करण्याची कल्पना आली. आमच्याकडे क्लिकहाऊसवर लॉग आहेत - ते वापरून का पाहू नये?

आमच्याकडे KittenHouse द्वारे नोंदी लिहिणारी योजना होती.

आम्ही ठरवलं आकृतीमध्ये दुसरे "*घर" जोडा, ज्याला आमचा कोड UDP द्वारे लिहिल्याप्रमाणे मॅट्रिक्स फॉरमॅटमध्ये प्राप्त होईल. मग हे *हाउस त्यांना इन्सर्टमध्ये बदलते, जसे की लॉग, जे KittenHouse ला समजते. तो क्लिकहाऊसवर हे लॉग उत्तम प्रकारे वितरीत करू शकतो, जे त्यांना वाचण्यास सक्षम असावे.

memcache, stats-deemon आणि logs-collectors डेटाबेस असलेली योजना यासह बदलली आहे.

memcache, stats-deemon आणि logs-collectors डेटाबेस असलेली योजना यासह बदलली आहे.

• येथे कोडमधून एक डिस्पॅच आहे, जो स्थानिक पातळीवर StatsHouse मध्ये लिहिलेला आहे.
• StatsHouse UDP मेट्रिक्स लिहिते, जे आधीपासून SQL इन्सर्टमध्ये रूपांतरित झाले आहे, KittenHouse मध्ये बॅचमध्ये.
• KittenHouse त्यांना ClickHouse वर पाठवते.
• जर आम्हाला ते वाचायचे असतील, तर आम्ही ते StatsHouse ला बायपास करून वाचतो - नियमित SQL वापरून थेट ClickHouse वरून.

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

योजना लोह वाचवत नाही. कमी सर्व्हरची आवश्यकता आहे, स्थानिक आकडेवारी-डेमन आणि लॉग-कलेक्टरची आवश्यकता नाही, परंतु ClickHouse ला सध्याच्या योजनेतील सर्व्हरपेक्षा मोठ्या सर्व्हरची आवश्यकता आहे. कमी सर्व्हर आवश्यक आहेत, परंतु ते अधिक महाग आणि अधिक शक्तिशाली असले पाहिजेत.

तैनात करणे

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

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

आम्ही kPHP देखील खूप उपयोजित करतो आणि त्याचा स्वतःचा विकास देखील चालू आहे जा वरील आकृतीनुसार. या पासून HTTP सर्व्हर बायनरी, तर आपण भिन्नता निर्माण करू शकत नाही - रिलीझ बायनरीचे वजन शेकडो MB असते. म्हणून, येथे दुसरा पर्याय आहे - आवृत्ती वर लिहिलेली आहे binlog कॉपीफास्ट. प्रत्येक बिल्डसह ते वाढते आणि रोलबॅक दरम्यान ते देखील वाढते. आवृत्ती सर्व्हरवर प्रतिकृती तयार केली. स्थानिक कॉपीफास्ट्स पाहतात की बिनलॉगमध्ये नवीन आवृत्ती आली आहे आणि त्याच गॉसिप प्रतिकृतीद्वारे ते आमच्या मास्टर सर्व्हरला न थकवता, परंतु संपूर्ण नेटवर्कवर भार काळजीपूर्वक पसरवत, स्वतःसाठी बायनरीची नवीनतम आवृत्ती घेतात. काय खालील सुंदर पुन्हा लाँच नवीन आवृत्तीसाठी.

आमच्या इंजिनसाठी, जे मूलत: बायनरी देखील आहेत, योजना अगदी समान आहे:

• git मास्टर शाखा;
• मध्ये बायनरी .deb;
• आवृत्ती binlog copyfast वर लिहिली आहे;
• सर्व्हरवर प्रतिकृती;
• सर्व्हर ताजे .dep बाहेर काढतो;
• डीपीकेजी -आय;
• नवीन आवृत्तीवर सुंदर पुन्हा लाँच.

फरक असा आहे की आमची बायनरी आर्काइव्हमध्ये पॅकेज केलेली आहे .deb, आणि ते बाहेर पंप करताना डीपीकेजी -आय प्रणालीवर ठेवल्या जातात. kPHP बायनरी म्हणून का उपयोजित केले जाते आणि इंजिन dpkg म्हणून का तैनात केले जातात? तसे घडले. हे कार्य करते - त्याला स्पर्श करू नका.

उपयुक्त दुवे:

• अँटोन किरयुश्किन यांनी अहवाल दिला "Vkontakte सिस्टम प्रशासक. कसे?" कॉपीफास्ट आणि गॉसिप बद्दल तपशीलांसह.
• युरी नसरेटिनोव्ह यांनी अहवाल दिला "व्हीके हजारो सर्व्हरमधून क्लिकहाऊसमध्ये डेटा कसा घालतो".
• माझा अहवाल "VKontakte चे उदाहरण वापरून वाढत्या प्रकल्पाचे आर्किटेक्चर", परंतु विकासाच्या दृष्टिकोनातून, हार्डवेअर नाही.

अलेक्सी अकुलोविच हे त्यांच्यापैकी एक आहेत जे कार्यक्रम समितीचा एक भाग म्हणून मदत करतात PHP रशिया 17 मे रोजी PHP विकसकांसाठी अलीकडच्या काळातील सर्वात मोठा कार्यक्रम होईल. आमच्याकडे काय मस्त पीसी आहे ते पहा स्पीकर्स (त्यापैकी दोन PHP कोर विकसित करत आहेत!) - आपण PHP लिहिल्यास आपण गमावू शकणार नाही असे दिसते.

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