VKontakte की वास्तुकला और कार्य पर अक्सर पूछे जाने वाले प्रश्न

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

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

चार वर्षों से अधिक समय से मैं बैकएंड से संबंधित सभी प्रकार के कार्यों से निपट रहा हूं।

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

इस दौरान साइट के कई घटकों में मेरा हाथ रहा। मैं यह अनुभव साझा करना चाहता हूं.

सामान्य वास्तुकला

सब कुछ, हमेशा की तरह, एक सर्वर या सर्वरों के समूह से शुरू होता है जो अनुरोध स्वीकार करते हैं।

फ्रंट सर्वर

फ्रंट सर्वर HTTPS, RTMP और WSS के माध्यम से अनुरोध स्वीकार करता है।

HTTPS - ये साइट के मुख्य और मोबाइल वेब संस्करणों के लिए अनुरोध हैं: vk.com और m.vk.com, और हमारे एपीआई के अन्य आधिकारिक और अनौपचारिक ग्राहक: मोबाइल क्लाइंट, मैसेंजर। हमारा एक रिसेप्शन है RTMP- अलग फ्रंट सर्वर के साथ लाइव प्रसारण के लिए ट्रैफ़िक और WSS- स्ट्रीमिंग एपीआई के लिए कनेक्शन।

सर्वर पर HTTPS और WSS के लिए यह उपयुक्त है nginx. आरटीएमपी प्रसारण के लिए, हमने हाल ही में अपने स्वयं के समाधान पर स्विच किया है किव, लेकिन यह रिपोर्ट के दायरे से बाहर है। दोष सहनशीलता के लिए, ये सर्वर सामान्य आईपी पते का विज्ञापन करते हैं और समूहों में कार्य करते हैं ताकि यदि किसी सर्वर पर कोई समस्या हो, तो उपयोगकर्ता के अनुरोध खो न जाएं। HTTPS और WSS के लिए, ये वही सर्वर CPU लोड का हिस्सा अपने ऊपर लेने के लिए ट्रैफ़िक को एन्क्रिप्ट करते हैं।

हम आगे WSS और RTMP के बारे में बात नहीं करेंगे, बल्कि केवल मानक HTTPS अनुरोधों के बारे में बात करेंगे, जो आमतौर पर एक वेब प्रोजेक्ट से जुड़े होते हैं।

बैकएण्ड

सामने के पीछे आमतौर पर बैकएंड सर्वर होते हैं। वे उन अनुरोधों को संसाधित करते हैं जो फ्रंट सर्वर क्लाइंट से प्राप्त करता है।

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

लोड वितरण

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

मीट्रिक संग्रह और पुनर्संतुलन

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

हमारे पास ऐसे हजारों सर्वर हैं। प्रत्येक भौतिक सर्वर सभी कोर को रीसायकल करने के लिए एक kPHP समूह चलाता है (क्योंकि kPHP एकल थ्रेडेड है)।

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

सीएस या कंटेंट सर्वर एक स्टोरेज है. सीएस एक सर्वर है जो फाइलों को संग्रहीत करता है और अपलोड की गई फाइलों और सभी प्रकार के पृष्ठभूमि तुल्यकालिक कार्यों को भी संसाधित करता है जो मुख्य वेब फ्रंटएंड इसे सौंपता है।

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

पु/प.प

यदि आपने वीके में नेटवर्क टैब खोला, तो आपको पीयू/पीपी दिखाई दिया।

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

पु फोटो अपलोड का ऐतिहासिक नाम है, और पीपी फोटो प्रॉक्सी है. यानी एक सर्वर फोटो अपलोड करने के लिए है और दूसरा अपलोड करने के लिए है. अब न केवल तस्वीरें लोड की गई हैं, बल्कि नाम भी संरक्षित किया गया है।

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

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

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

इस मामले में विवादास्पद बात यह है कि क्लाइंट कम कनेक्शन रखता है. यदि कई मशीनों के लिए एक ही आईपी है - एक ही होस्ट के साथ: pu.vk.com या pp.vk.com, तो क्लाइंट ब्राउज़र के पास एक होस्ट के लिए एक साथ अनुरोधों की संख्या की सीमा होती है। लेकिन सर्वव्यापी HTTP/2 के समय में, मेरा मानना ​​है कि यह अब उतना प्रासंगिक नहीं रह गया है।

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

अभी कुछ समय पहले ही हमें प्रॉक्सी का एक उन्नत संस्करण मिला था। अब मैं आपको बताऊंगा कि वे सामान्य लोगों से कैसे भिन्न हैं और यह क्यों आवश्यक है।

रवि

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

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

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

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

वजन का समर्थन. अब हम आवश्यकतानुसार विभिन्न शक्ति की मशीनें स्थापित कर सकते हैं, और साथ ही, अस्थायी समस्याओं के मामले में, उन पर भार कम करने के लिए काम कर रहे "सूरजों" का वजन बदल सकते हैं, ताकि वे "आराम" करें और फिर से काम करना शुरू कर दें।

सामग्री आईडी द्वारा साझाकरण. शार्डिंग के बारे में एक मजेदार बात: हम आम तौर पर सामग्री को शार्ड करते हैं ताकि विभिन्न उपयोगकर्ता एक ही "सन" के माध्यम से एक ही फाइल पर जाएं ताकि उनके पास एक सामान्य कैश हो।

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

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

अंदर से सूरज

nginx पर रिवर्स प्रॉक्सी, RAM में या तेज़ Optane/NVMe डिस्क पर कैश करें। उदाहरण: http://sun4-2.userapi.com/c100500/path — "सूर्य" के लिए एक लिंक, जो चौथे क्षेत्र, दूसरे सर्वर समूह में स्थित है। यह पथ फ़ाइल को बंद कर देता है, जो भौतिक रूप से सर्वर 100500 पर स्थित है।

कैश

हम अपनी वास्तुशिल्प योजना में एक और नोड जोड़ते हैं - कैशिंग वातावरण।

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

यह मल्टीमीडिया सामग्री की कैशिंग है; यहां कोई उपयोगकर्ता डेटा संग्रहीत नहीं है - केवल संगीत, वीडियो, फ़ोटो।

उपयोगकर्ता का क्षेत्र निर्धारित करने के लिए, हम हम क्षेत्रों में घोषित बीजीपी नेटवर्क उपसर्ग एकत्र करते हैं. फ़ॉलबैक के मामले में, यदि हम उपसर्गों द्वारा आईपी नहीं ढूंढ पाते हैं तो हमें जियोआईपी डेटाबेस को भी पार्स करना होगा। हम उपयोगकर्ता के आईपी द्वारा क्षेत्र निर्धारित करते हैं. कोड में, हम उपयोगकर्ता के एक या अधिक क्षेत्रों को देख सकते हैं - वे बिंदु जिनसे वह भौगोलिक रूप से निकटतम है।

यह कैसे काम करता है?

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

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

इस मामले में हमें मिलता है सामग्री उपयोगकर्ताओं के करीब और नेटवर्क लोड फैलाना। उदाहरण के लिए, केवल मॉस्को कैश से हम पीक आवर्स के दौरान 1 Tbit/s से अधिक वितरित करते हैं।

लेकिन समस्याएँ भी हैं - कैश सर्वर रबर नहीं हैं. अत्यधिक लोकप्रिय सामग्री के लिए, कभी-कभी एक अलग सर्वर के लिए पर्याप्त नेटवर्क नहीं होता है। हमारे कैश सर्वर 40-50 Gbit/s हैं, लेकिन ऐसी सामग्री है जो ऐसे चैनल को पूरी तरह से अवरुद्ध कर देती है। हम क्षेत्र में लोकप्रिय फ़ाइलों की एक से अधिक प्रतियों के भंडारण को लागू करने की दिशा में आगे बढ़ रहे हैं। मुझे उम्मीद है कि हम इसे साल के अंत तक लागू कर देंगे.

हमने सामान्य वास्तुकला को देखा।

• फ्रंट सर्वर जो अनुरोध स्वीकार करते हैं।
• उस प्रक्रिया अनुरोध को बैकएंड करता है।
• वे भंडार जो दो प्रकार के प्रॉक्सी द्वारा बंद किए जाते हैं।
• क्षेत्रीय कैश.

इस आरेख में क्या कमी है? बेशक, जिन डेटाबेस में हम डेटा संग्रहीत करते हैं।

डेटाबेस या इंजन

हम उन्हें डेटाबेस नहीं, बल्कि इंजन - इंजन कहते हैं, क्योंकि व्यावहारिक रूप से हमारे पास आम तौर पर स्वीकृत अर्थों में डेटाबेस नहीं हैं।

यह एक आवश्यक उपाय है।. ऐसा इसलिए हुआ क्योंकि 2008-2009 में, जब वीके की लोकप्रियता में विस्फोटक वृद्धि हुई थी, परियोजना पूरी तरह से MySQL और Memcache पर काम करती थी और समस्याएं थीं। MySQL को फ़ाइलों को क्रैश और भ्रष्ट करना पसंद था, जिसके बाद यह ठीक नहीं होता था, और मेमकेचे का प्रदर्शन धीरे-धीरे खराब हो गया और उसे फिर से शुरू करना पड़ा।

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

समाधान सफल रहा. ऐसा करने का अवसर भी था और अत्यधिक आवश्यकता भी, क्योंकि उस समय स्केलिंग के अन्य तरीके मौजूद नहीं थे। डेटाबेस का एक समूह नहीं था, NoSQL अभी तक मौजूद नहीं था, केवल MySQL, Memcache, PostrgreSQL थे - और बस इतना ही।

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

इंजनों के प्रकार

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

प्रत्येक कार्य के लिए जिसके लिए एक विशिष्ट डेटा संरचना की आवश्यकता होती है या असामान्य अनुरोधों को संसाधित किया जाता है, सी टीम एक नया इंजन लिखती है। क्यों नहीं।

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

समूहों

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

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

इसे काम करने के लिए, आपको एक और इकाई जोड़ने की ज़रूरत है जो कोड और इंजन के बीच स्थित है - प्रतिनिधि.

आरपीसी प्रॉक्सी

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

प्रोग्रामर को इसकी बिल्कुल भी परवाह नहीं है कि इसकी लागत कितनी, कहाँ और क्या है - वे बस क्लस्टर में जाते हैं। इससे हमें बहुत कुछ मिलता है. अनुरोध प्राप्त करते समय, प्रॉक्सी अनुरोध को पुनर्निर्देशित करता है, यह जानते हुए कि कहां - यह स्वयं निर्धारित करता है।

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

विशिष्ट कार्यान्वयन

कभी-कभी हम वास्तव में एक इंजन के रूप में किसी प्रकार का गैर-मानक समाधान चाहते हैं। उसी समय, हमारे इंजनों के लिए विशेष रूप से बनाई गई हमारी तैयार आरपीसी-प्रॉक्सी का उपयोग नहीं करने, बल्कि कार्य के लिए एक अलग प्रॉक्सी बनाने का निर्णय लिया गया।

MySQL के लिए, जो अभी भी हमारे यहां और वहां मौजूद है, हम db-प्रॉक्सी का उपयोग करते हैं, और ClickHouse के लिए - बिल्ली का बच्चाघर.

यह आम तौर पर इसी तरह काम करता है. एक निश्चित सर्वर है, यह kPHP, Go, Python चलाता है - सामान्य तौर पर, कोई भी कोड जो हमारे RPC प्रोटोकॉल का उपयोग कर सकता है। कोड स्थानीय रूप से RPC प्रॉक्सी पर चलता है - प्रत्येक सर्वर जहां कोड स्थित है, अपना स्वयं का स्थानीय प्रॉक्सी चलाता है। अनुरोध पर, प्रॉक्सी समझता है कि कहाँ जाना है।

यदि एक इंजन दूसरे के पास जाना चाहता है, भले ही वह पड़ोसी ही क्यों न हो, तो वह प्रॉक्सी के माध्यम से जाता है, क्योंकि पड़ोसी दूसरे डेटा सेंटर में हो सकता है। इंजन को अपने अलावा किसी अन्य चीज़ का स्थान जानने पर निर्भर नहीं रहना चाहिए - यह हमारा मानक समाधान है। लेकिन निश्चित रूप से कुछ अपवाद भी हैं :)

टीएल-योजना का एक उदाहरण जिसके अनुसार सभी इंजन संचालित होते हैं।

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;

यह एक बाइनरी प्रोटोकॉल है, जिसका निकटतम एनालॉग है प्रोटोबफ़. स्कीमा वैकल्पिक फ़ील्ड, जटिल प्रकार - अंतर्निहित स्केलर के विस्तार और प्रश्नों का पूर्ववर्णन करती है। सब कुछ इसी प्रोटोकॉल के तहत काम करता है.

टीसीपी/यूडीपी पर टीएल पर आरपीसी...यूडीपी?

हमारे पास इंजन अनुरोधों को निष्पादित करने के लिए एक आरपीसी प्रोटोकॉल है जो टीएल योजना के शीर्ष पर चलता है। यह सब टीसीपी/यूडीपी कनेक्शन पर काम करता है। टीसीपी समझ में आता है, लेकिन हमें अक्सर यूडीपी की आवश्यकता क्यों होती है?

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

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

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

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

लगातार डेटा भंडारण

इंजन बिनलॉग लिखते हैं. बिनलॉग एक फ़ाइल है जिसके अंत में स्थिति या डेटा में बदलाव के लिए एक ईवेंट जोड़ा जाता है। विभिन्न समाधानों में इसे अलग-अलग कहा जाता है: बाइनरी लॉग, वाल, AOF, लेकिन सिद्धांत वही है.

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

मैं शीघ्रता से ऑपरेशन के सिद्धांत का वर्णन करूंगा। एक सर्वर है जिस पर इंजन चलता है। वह लिखने के लिए एक नया खाली बिनलॉग खोलता है और उसमें बदलाव के लिए एक ईवेंट लिखता है।

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

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

स्नैपशॉट बनाए जाने के समय की स्थिति और बिनलॉग का आकार पढ़ता है।

वर्तमान स्थिति जानने के लिए बिनलॉग का अंत पढ़ता है और आगे की घटनाएं लिखना जारी रखता है। यह एक सरल योजना है; हमारे सभी इंजन इसके अनुसार काम करते हैं।

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

परिणामस्वरूप, हमारे में डेटा प्रतिकृति कथन आधारित - हम बिनलॉग में लिखते हैं कि कोई पृष्ठ परिवर्तन नहीं, बल्कि अर्थात् परिवर्तन अनुरोध. नेटवर्क पर जो आता है उसके समान, केवल थोड़ा संशोधित।

उसी योजना का उपयोग न केवल प्रतिकृति के लिए भी किया जाता है बैकअप बनाने के लिए. हमारे पास एक इंजन है - एक राइटिंग मास्टर जो बिनलॉग को लिखता है। किसी भी अन्य स्थान पर जहां व्यवस्थापक इसे सेट करते हैं, यह बिनलॉग कॉपी किया जाता है, और बस इतना ही - हमारे पास एक बैकअप है।

यदि ज़रूरत हो तो प्रतिकृति पढ़नासीपीयू रीडिंग लोड को कम करने के लिए, रीडिंग इंजन को बस लॉन्च किया जाता है, जो बिनलॉग के अंत को पढ़ता है और इन कमांड को स्थानीय रूप से निष्पादित करता है।

यहां अंतराल बहुत छोटा है, और यह पता लगाना संभव है कि प्रतिकृति मास्टर से कितना पीछे है।

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

शेयरिंग कैसे काम करती है? प्रॉक्सी कैसे समझती है कि किस क्लस्टर शार्ड को भेजना है? कोड यह नहीं कहता: "15 टुकड़े के लिए भेजें!" - नहीं, यह प्रॉक्सी द्वारा किया जाता है।

सबसे सरल योजना फर्स्टइंट है - अनुरोध में पहला नंबर.

get(photo100_500) => 100 % N.

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

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

यदि हमें इसकी परवाह नहीं है कि अनुरोध पूरे क्लस्टर में कैसे फैले हैं, तो एक और विकल्प है - संपूर्ण शार्ड को हैश करना.

hash(photo100_500) => 3539886280 % N

हमें हैश, विभाजन का शेष भाग और शार्ड संख्या भी मिलती है।

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

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

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

लॉग

हम कई तरीकों से लॉग लिखते हैं। सबसे स्पष्ट और सरल है memcache पर लॉग लिखें.

ring-buffer: prefix.idx = line

एक कुंजी उपसर्ग है - लॉग का नाम, एक पंक्ति, और इस लॉग का आकार है - पंक्तियों की संख्या। हम 0 से लेकर लाइनों की संख्या माइनस 1 तक एक यादृच्छिक संख्या लेते हैं। मेम्कैश में कुंजी इस यादृच्छिक संख्या के साथ संयोजित एक उपसर्ग है। हम लॉग लाइन और वर्तमान समय को मान में सहेजते हैं।

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

लॉग के विश्वसनीय भंडारण के लिए हमारे पास एक इंजन है लॉग-इंजन. ठीक इसी कारण से इसे बनाया गया था और बड़ी संख्या में समूहों में इसका व्यापक रूप से उपयोग किया जाता है। मुझे पता है कि सबसे बड़े क्लस्टर में 600 टीबी पैक्ड लॉग संग्रहीत हैं।

इंजन बहुत पुराना है, ऐसे क्लस्टर हैं जो पहले से ही 6-7 साल पुराने हैं। इसमें कुछ समस्याएं हैं जिन्हें हम हल करने का प्रयास कर रहे हैं, उदाहरण के लिए, हमने लॉग स्टोर करने के लिए ClickHouse का सक्रिय रूप से उपयोग करना शुरू कर दिया है।

ClickHouse में लॉग एकत्रित करना

यह चित्र दिखाता है कि हम अपने इंजनों में कैसे चलते हैं।

एक कोड है जो स्थानीय रूप से आरपीसी के माध्यम से आरपीसी-प्रॉक्सी तक जाता है, और यह समझता है कि इंजन में कहां जाना है। यदि हम ClickHouse में लॉग लिखना चाहते हैं, तो हमें इस योजना में दो भागों को बदलना होगा:

• कुछ इंजन को ClickHouse से बदलें;
• RPC प्रॉक्सी को, जो ClickHouse तक नहीं पहुँच सकता है, किसी ऐसे समाधान से बदलें जो RPC के माध्यम से हो सके।

इंजन सरल है - हम इसे क्लिकहाउस वाले सर्वर या सर्वर के क्लस्टर से बदल देते हैं।

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

कभी-कभी हम RPC योजना को गैर-मानक समाधानों में लागू नहीं करना चाहते हैं, उदाहरण के लिए, nginx में। इसलिए, किटनहाउस में यूडीपी के माध्यम से लॉग प्राप्त करने की क्षमता है।

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

निगरानी

हमारे पास दो प्रकार के लॉग हैं: वे जो प्रशासकों द्वारा अपने सर्वर पर एकत्र किए जाते हैं और वे जो डेवलपर्स द्वारा कोड से लिखे जाते हैं। वे दो प्रकार के मेट्रिक्स से मेल खाते हैं: प्रणाली और उत्पाद.

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

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

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

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

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

$stats = statlogsStatData($params)

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

हम बहुत लिखते हैं कई मेट्रिक्स घटनाओं की संख्या प्रतिदिन 600 अरब से 1 ट्रिलियन तक है। हालाँकि, हम उन्हें रखना चाहते हैं कम से कम कुछ सालमेट्रिक्स में रुझान को समझने के लिए। इन सबको एक साथ रखना एक बड़ी समस्या है जिसे हम अभी तक हल नहीं कर पाए हैं। मैं आपको बताऊंगा कि पिछले कुछ वर्षों से यह कैसे काम कर रहा है।

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

यदि आवश्यक हो, तो हम सीधे लॉग-कलेक्टरों को लिख सकते हैं।

लेकिन स्टैस-डेमॉम को दरकिनार करते हुए कोड से सीधे कलेक्टरों को लिखना एक खराब स्केलेबल समाधान है क्योंकि इससे कलेक्टर पर भार बढ़ जाता है। समाधान केवल तभी उपयुक्त है जब किसी कारण से हम मशीन पर मेम्कैश आँकड़े-डेमन नहीं बढ़ा सकते, या यह दुर्घटनाग्रस्त हो गया और हम सीधे चले गए।

इसके बाद, लॉग-कलेक्टर आँकड़ों को मर्ज करते हैं म्याऊडीबी - यह हमारा डेटाबेस है, जो मेट्रिक्स को भी स्टोर कर सकता है।

फिर हम कोड से बाइनरी "नियर-एसक्यूएल" चयन कर सकते हैं।

प्रयोग

2018 की गर्मियों में, हमारे पास एक आंतरिक हैकथॉन था, और आरेख के लाल भाग को किसी ऐसी चीज़ से बदलने का प्रयास करने का विचार आया जो क्लिकहाउस में मेट्रिक्स को संग्रहीत कर सके। हमारे पास ClickHouse पर लॉग हैं - इसे क्यों न आज़माएँ?

हमारे पास एक योजना थी जो किटनहाउस के माध्यम से लॉग लिखती थी।

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

मेमकैश, स्टैटिस्टिक्स-डेमॉन और लॉग्स-कलेक्टर्स डेटाबेस वाली योजना को इसके साथ बदल दिया गया है।

मेमकैश, स्टैटिस्टिक्स-डेमॉन और लॉग्स-कलेक्टर्स डेटाबेस वाली योजना को इसके साथ बदल दिया गया है।

• यहां कोड से एक प्रेषण है, जो स्टैट्सहाउस में स्थानीय रूप से लिखा गया है।
• स्टैट्सहाउस बैचों में किटनहाउस को यूडीपी मेट्रिक्स लिखता है, जो पहले से ही एसक्यूएल इंसर्ट में परिवर्तित हो चुका है।
• किटनहाउस उन्हें ClickHouse पर भेजता है।
• यदि हम उन्हें पढ़ना चाहते हैं, तो हम उन्हें स्टैट्सहाउस को दरकिनार करके नियमित SQL का उपयोग करके सीधे ClickHouse से पढ़ते हैं।

क्या यह अभी भी है प्रयोग, लेकिन हमें यह पसंद है कि यह कैसे होता है। यदि हम योजना की समस्याओं को ठीक कर लें, तो शायद हम इसे पूरी तरह से अपना लेंगे। व्यक्तिगत रूप से, मुझे ऐसी आशा है.

ड्राइविंग आयरन की बचत नहीं होती. कम सर्वरों की आवश्यकता होती है, स्थानीय सांख्यिकी-डेमॉन और लॉग-कलेक्टरों की आवश्यकता नहीं होती है, लेकिन ClickHouse को वर्तमान योजना की तुलना में बड़े सर्वर की आवश्यकता होती है। कम सर्वर की आवश्यकता है, लेकिन वे अधिक महंगे और अधिक शक्तिशाली होने चाहिए.

तैनात करना

सबसे पहले, आइए PHP परिनियोजन को देखें। हम में विकास कर रहे हैं Git: उपयोग GitLab и TeamCity तैनाती के लिए. विकास शाखाओं को मास्टर शाखा में विलय कर दिया जाता है, परीक्षण के लिए मास्टर से उन्हें स्टेजिंग में और स्टेजिंग से उत्पादन में विलय कर दिया जाता है।

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

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

हमारे इंजनों के लिए, जो अनिवार्य रूप से बायनेरिज़ भी हैं, योजना बहुत समान है:

• गिट मास्टर शाखा;
• बाइनरी में लोगों के सामने पहली उपस्थिति करनेवाली;
• संस्करण बिनलॉग कॉपीफ़ास्ट को लिखा गया है;
• सर्वर पर प्रतिकृति;
• सर्वर एक ताज़ा .dep निकालता है;
• डीपीकेजी -आई;
• नए संस्करण में सुंदर पुन: लॉन्च।

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

उपयोगी लिंक्स:

• एंटोन किर्युश्किन की रिपोर्ट “Vkontakte सिस्टम प्रशासक। कैसे?" कॉपीफ़ास्ट और गपशप के बारे में विवरण के साथ।
• यूरी नसरेटदीनोव की रिपोर्ट "वीके हजारों सर्वरों से CLickHouse में डेटा कैसे सम्मिलित करता है".
• मेरी रिपोर्ट "VKontakte के उदाहरण का उपयोग करके एक बढ़ती परियोजना की वास्तुकला", लेकिन विकास के दृष्टिकोण से, हार्डवेयर नहीं।

एलेक्सी अकुलोविच उन लोगों में से एक हैं जो कार्यक्रम समिति के सदस्य के रूप में मदद करते हैं पीएचपी रूस 17 मई को हाल के दिनों में PHP डेवलपर्स के लिए सबसे बड़ा आयोजन बन जाएगा। देखो हमारे पास कितना अच्छा पीसी है, क्या वक्ताओं (उनमें से दो PHP कोर विकसित कर रहे हैं!) - ऐसा लगता है कि यदि आप PHP लिखते हैं तो कुछ ऐसा है जिसे आप मिस नहीं कर सकते।

स्रोत: www.habr.com