🏪 👦 🚔 वास्तुकला और काम पर पूछे जाने वाले प्रश्न VKontakte 🥘 🏷️ 👩🏾‍🍳

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

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

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

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

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

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

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

सामने सर्वर

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

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

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

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

बैकएंड

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

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

लोड साझा करना

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

मेट्रिक्स कलेक्शन और रीबैलेंसिंग

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

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

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

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

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

पु / पीपी

यदि आपने VK में नेटवर्क टैब खोला है, तो आपने pu / pp देखा।

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

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

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

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

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

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

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

बहुत पहले नहीं, हमारे पास प्रॉक्सी का उन्नत संस्करण है। अब मैं आपको बताता हूँ कि वे कैसे सामान्य लोगों से अलग हैं और यह क्यों आवश्यक है।

सूर्य

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

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

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

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

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

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

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

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

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

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

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

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

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

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

समूहों

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

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

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

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

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

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

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

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

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

MySQL के लिए, जो अभी भी हमारे पास कुछ स्थानों पर है, हम db-प्रॉक्सी और ClickHouse - Kittenhouse का उपयोग करते हैं ।

यह समग्र तरह काम करता है। एक सर्वर है, kPHP, गो, पायथन उस पर चल रहे हैं - सामान्य तौर पर, कोई भी कोड जो हमारे 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;

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

टीसीपी / आरडीपी से अधिक टीएल पर आरपीसी ... यूडीपी?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आरपीसी-प्रॉक्सी में डेटा की पैठ

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

सबसे सरल योजना है फर्स्ट , रिक्वेस्ट में पहला नंबर।

get(photo100_500) => 100 % N.

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

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

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

hash(photo100_500) => 3539886280 % N

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

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

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

- . : RPC-proxy , , . , , , . proxy.

. — memcache .

ring-buffer: prefix.idx = line

— , , — . 0 1. memcache — . .

, Multi Get , , . , - , , , .

logs-engine . , . 600 .

, , 6–7 . , , , ClickHouse .

ClickHouse

, .

, RPC RPC-proxy, , . ClickHouse, :

- ClickHouse;
RPC-proxy, ClickHouse, - , , RPC.

— ClickHouse.

ClickHouse, KittenHouse . KittenHouse ClickHouse — . , HTTP- . , ClickHouse reverse proxy , , . .

RPC- , , nginx. KittenHouse UDP.

, UDP- . RPC , UDP. .

निगरानी

: , , . : .

Netdata , Graphite Carbon . ClickHouse, Whisper, . ClickHouse, Grafana , . , Netdata Grafana .

. , , Counts, UniqueCounts , - .

 statlogsCountEvent ( 'stat_name', $key1, $key2, …) statlogsUniqueCount ( 'stat_name', $uid, $key1, $key2, …) statlogsValuetEvent ( 'stat_name', $value, $key1, $key2, …) $stats = statlogsStatData($params)

, , — , Wathdogs.

, 600 1 . , . — , . , .

, memcache , . stats-daemon . logs-collectors , , .

logs-collectors.

stas-daemom — , collector. , - memcache stats-daemon, , .

logs-collectors meowDB — , .

«-SQL» .

2018 , -, ClickHouse. ClickHouse — ?

, KittenHouse.

«*House» , , UDP. *House inserts, , KittenHouse. ClickHouse, .

memcache, stats-daemon logs-collectors .

, StatsHouse.
StatsHouse KittenHouse UDP-, SQL-inserts, .
KittenHouse ClickHouse.
, StatsHouse — ClickHouse SQL.

, , . , , , . .

. , stats-daemons logs-collectors, ClickHouse , , . , .

PHP. git : GitLab TeamCity . -, , — .

, diff — : , , . binlog copyfast, . , gossip replication , , — , . . , . .

kPHP git . HTTP- , diff — . — binlog copyfast . , . . copyfast' , binlog , gossip replication , -, . graceful .

, , :

git master branch;
.deb ;
binlog copyfast;
;
.dep;
dpkg -i ;
graceful .

, .deb , dpkg -i . kPHP , — dpkg? . — .

:

, PHP Russia 17 PHP-. , , ( PHP!) — , PHP, .

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