वास्तुकला र VKontakte को काम मा FAQ

VKontakte को सिर्जना को इतिहास विकिपीडिया मा छ; यो पावेल आफैले भनिएको थियो। सबैले उनलाई पहिले नै चिनेको देखिन्छ। HighLoad++ Pavel मा साइटको आन्तरिक, वास्तुकला र संरचना बारे मलाई 2010 मा फिर्ता भन्नुभयो। त्यसपछि धेरै सर्भरहरू लीक भएका छन्, त्यसैले हामी जानकारी अपडेट गर्नेछौं: हामी यसलाई विच्छेद गर्नेछौं, भित्री भागहरू निकाल्नेछौं, यसलाई तौल गर्नेछौं, र प्राविधिक दृष्टिकोणबाट VK उपकरणलाई हेर्नेछौं।

एलेक्सी अकुलोविच (AterCattus) VKontakte टोलीमा ब्याकएन्ड विकासकर्ता। यस रिपोर्टको ट्रान्सक्रिप्ट प्लेटफर्मको सञ्चालन, पूर्वाधार, सर्भर र तिनीहरू बीचको अन्तरक्रियाको बारेमा बारम्बार सोधिने प्रश्नहरूको सामूहिक जवाफ हो, तर विकासको बारेमा होइन, अर्थात्। फलामको बारेमा। अलग रूपमा, डाटाबेस र यसको सट्टा VK के छ, लगहरू सङ्कलन र सम्पूर्ण परियोजनाको समग्र रूपमा निगरानीको बारेमा। कट अन्तर्गत विवरणहरू।

चार वर्षभन्दा बढी समयदेखि मैले ब्याकइन्डसँग सम्बन्धित सबै प्रकारका कार्यहरू सम्हाल्दै आएको छु।

• अपलोड, भण्डारण, प्रशोधन, मिडिया वितरण: भिडियो, लाइभ स्ट्रिमिङ, अडियो, फोटो, कागजातहरू।
• पूर्वाधार, प्लेटफर्म, विकासकर्ता निगरानी, ​​लग, क्षेत्रीय क्यास, CDN, स्वामित्व RPC प्रोटोकल।
• बाह्य सेवाहरूसँग एकीकरण: पुश सूचनाहरू, बाह्य लिङ्क पार्सिङ, RSS फिड।
• विभिन्न प्रश्नहरूको साथ सहकर्मीहरूलाई मद्दत गर्दै, जसको जवाफहरू अज्ञात कोडमा डुब्न आवश्यक छ।

यस समयमा, मसँग साइटको धेरै घटकहरूमा हात थियो। म यो अनुभव साझा गर्न चाहन्छु।

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

सबै कुरा, सामान्य रूपमा, अनुरोधहरू स्वीकार गर्ने सर्भर वा सर्भरहरूको समूहबाट सुरु हुन्छ।

अगाडि सर्भर

अगाडि सर्भरले HTTPS, RTMP र WSS मार्फत अनुरोधहरू स्वीकार गर्दछ।

HTTPS - यी साइटको मुख्य र मोबाइल वेब संस्करणहरूका लागि अनुरोधहरू हुन्: vk.com र m.vk.com, र हाम्रो API का अन्य आधिकारिक र अनौपचारिक ग्राहकहरू: मोबाइल ग्राहकहरू, सन्देशवाहकहरू। हामीसँग रिसेप्शन छ RTMP- अलग फ्रन्ट सर्भर र प्रत्यक्ष प्रसारण लागि यातायात WSS- स्ट्रिमिङ API को लागि जडानहरू।

सर्भरहरूमा HTTPS र WSS को लागी यो लायक छ nginx। RTMP प्रसारणहरूको लागि, हामीले भर्खरै हाम्रो आफ्नै समाधानमा स्विच गर्यौं kive, तर यो रिपोर्ट को दायरा बाहिर छ। गल्ती सहिष्णुताको लागि, यी सर्भरहरूले साझा आईपी ठेगानाहरू विज्ञापन गर्छन् र समूहहरूमा कार्य गर्छन् ताकि यदि कुनै सर्भरमा समस्या छ भने, प्रयोगकर्ता अनुरोधहरू हराउँदैनन्। HTTPS र WSS को लागि, यी समान सर्भरहरूले CPU लोडको अंश आफैंमा लिनको लागि ट्राफिक इन्क्रिप्ट गर्दछ।

हामी WSS र RTMP को बारेमा थप कुरा गर्दैनौं, तर मानक HTTPS अनुरोधहरूको बारेमा मात्र, जुन सामान्यतया वेब परियोजनासँग सम्बन्धित हुन्छ।

ब्याकइन्ड

अगाडि पछाडि सामान्यतया ब्याकइन्ड सर्भरहरू छन्। तिनीहरूले अनुरोधहरू प्रशोधन गर्छन् जुन अगाडि सर्भरले ग्राहकहरूबाट प्राप्त गर्दछ।

यो kPHP सर्भरहरू, जसमा HTTP डेमन चलिरहेको छ, किनभने HTTPS पहिले नै डिक्रिप्ट गरिएको छ। kPHP चल्ने सर्भर हो prefork मोडेलहरू: एक मास्टर प्रक्रिया सुरु गर्दछ, बच्चा प्रक्रियाहरूको एक गुच्छा, तिनीहरूलाई सुन्ने सकेटहरू पास गर्दछ र तिनीहरूले आफ्ना अनुरोधहरू प्रशोधन गर्छन्। यस अवस्थामा, प्रयोगकर्ताबाट प्रत्येक अनुरोधको बीचमा प्रक्रियाहरू पुन: सुरु हुँदैन, तर तिनीहरूको अवस्थालाई मूल शून्य-मान स्थितिमा रिसेट गर्नुहोस् - अनुरोध पछि अनुरोध, पुन: सुरु गर्नुको सट्टा।

लोड वितरण

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

मेट्रिक सङ्कलन र पुन: सन्तुलन

हामीसँग प्रत्येक समूहमा कतिवटा कारहरू हुनु आवश्यक छ भनेर बुझ्नको लागि, हामी QPS मा भरोसा नगर्नुहोस्। ब्याकएन्डहरू फरक छन्, तिनीहरूसँग फरक अनुरोधहरू छन्, प्रत्येक अनुरोधमा QPS गणना गर्ने फरक जटिलता छ। त्यही भएर हामीले हामी समग्र रूपमा सर्भरमा लोडको अवधारणासँग काम गर्छौं - CPU र perf मा.

हामीसँग त्यस्ता हजारौं सर्भरहरू छन्। प्रत्येक भौतिक सर्भरले सबै कोरहरू पुन: प्रयोग गर्न kPHP समूह चलाउँछ (किनभने kPHP एकल थ्रेडेड छ)।

सामग्री सर्भर

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

हामीसँग हजारौं भौतिक सर्भरहरू छन् जसले फाइलहरू भण्डार गर्दछ। प्रयोगकर्ताहरू फाइलहरू अपलोड गर्न मन पराउँछन्, र हामी तिनीहरूलाई भण्डारण गर्न र साझेदारी गर्न मनपर्छ। यी मध्ये केही सर्भरहरू विशेष pu/pp सर्भरहरूद्वारा बन्द गरिएका छन्।

pu/pp

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

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

पु फोटो अपलोडको लागि ऐतिहासिक नाम हो, र pp फोटो प्रोक्सी हो। त्यो हो, एउटा सर्भर फोटोहरू अपलोड गर्नको लागि हो, र अर्को अपलोडको लागि हो। अहिले तस्बिर मात्रै लोड भएन, नाम पनि जोगाइएको छ ।

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

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

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

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

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

केही समय अघि हामीले प्रोक्सीको सुधारिएको संस्करण पायौं। अब म तपाईलाई बताउनेछु कि तिनीहरू कसरी साधारण भन्दा फरक छन् र यो किन आवश्यक छ।

सूर्य

सेप्टेम्बर 2017 मा, ओरेकल, जसले पहिले सन किनेको थियो, धेरै संख्यामा सूर्यका कर्मचारीहरूलाई हटायो। हामी भन्न सक्छौं कि यस क्षणमा कम्पनीको अस्तित्व समाप्त भयो। नयाँ प्रणालीको लागि नाम छनोट गर्दा, हाम्रा प्रशासकहरूले यस कम्पनीको स्मृतिलाई श्रद्धांजलि अर्पण गर्ने निर्णय गरे र नयाँ प्रणालीलाई सूर्यको नाम दिए। हामी बीचमा हामी उसलाई "सूर्य" भन्छौं।

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

फलस्वरूप - हामी सामग्री काट्न सक्दैनौं, किनभने हामी यो समूहको लागि एक विशेष सर्भर चयन गर्न सक्दैनौं - तिनीहरूसँग साझा आईपी छ। केही आन्तरिक कारणले पनि हामीसँग छ क्षेत्रहरूमा त्यस्ता सर्भरहरू स्थापना गर्न सम्भव थिएन। तिनीहरू सेन्ट पीटर्सबर्गमा मात्र उभिए।

सूर्य संग, हामीले चयन प्रणाली परिवर्तन गर्यौं। अब हामीसँग छ कुनै पनि कास्ट रूटिङ: डायनामिक राउटिङ, anycast, सेल्फ-चेक डेमन। प्रत्येक सर्भरको आफ्नै व्यक्तिगत IP छ, तर एक साझा सबनेट। सबै कुरा यसरी कन्फिगर गरिएको छ कि यदि एक सर्भर असफल भयो भने, ट्राफिक स्वचालित रूपमा उही समूहको अन्य सर्भरहरूमा फैलिएको छ। अब यो एक विशेष सर्भर चयन गर्न सम्भव छ, कुनै अनावश्यक क्यासिङ छैन, र विश्वसनीयता प्रभावित भएको छैन।

वजन समर्थन। अब हामी आवश्यकता अनुसार बिभिन्न शक्तिका मेसिनहरू स्थापना गर्न सक्नेछौं, र साथै, अस्थायी समस्याहरूको अवस्थामा, काम गर्ने "सूर्य" को भारलाई कम गर्नको लागि तिनीहरूको वजन परिवर्तन गर्नुहोस्, ताकि तिनीहरू "आराम" र फेरि काम गर्न सुरु गर्नुहोस्।

सामग्री आईडी द्वारा साझेदारी। शार्डिङको बारेमा एउटा रमाइलो कुरा: हामी सामान्यतया सामग्रीलाई छ्याउछौँ ताकि विभिन्न प्रयोगकर्ताहरू एउटै "सन" मार्फत एउटै फाइलमा जान्छन् ताकि उनीहरूसँग साझा क्यास हुन्छ।

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

एउटै फाइलको लागि अनुरोधहरूको फटहरू सामना गर्नको लागि, यो निश्चित प्रकारको सामग्रीको लागि हो जुन हामी एउटा मूर्ख योजना खोल्छौं जसले फाइलहरूलाई सबै उपलब्ध "सूर्य" मा फैलाउँछ।

भित्रबाट घाम

nginx मा रिभर्स प्रोक्सी, या त RAM मा वा छिटो Optane/NVMe डिस्कहरूमा क्यास। उदाहरण: http://sun4-2.userapi.com/c100500/path - "सूर्य" को लिङ्क, जुन चौथो क्षेत्रमा अवस्थित छ, दोस्रो सर्भर समूह। यसले पथ फाइल बन्द गर्दछ, जुन भौतिक रूपमा सर्भर 100500 मा रहेको छ।

क्यास

हामी हाम्रो आर्किटेक्चरल योजनामा ​​थप एउटा नोड थप्छौं - क्यासिङ वातावरण।

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

यो मल्टिमिडिया सामग्रीको क्यासिङ हो; यहाँ कुनै प्रयोगकर्ता डेटा भण्डार गरिएको छैन - केवल संगीत, भिडियो, फोटोहरू।

प्रयोगकर्ताको क्षेत्र निर्धारण गर्न, हामी हामी क्षेत्रहरूमा घोषणा गरिएको BGP नेटवर्क उपसर्गहरू सङ्कलन गर्छौं। फलब्याकको अवस्थामा, हामीले उपसर्गहरूद्वारा IP फेला पार्न सकेनौं भने हामीले geoip डाटाबेसलाई पनि पार्स गर्नुपर्छ। हामी प्रयोगकर्ताको आईपी द्वारा क्षेत्र निर्धारण गर्छौं। कोडमा, हामी प्रयोगकर्ताको एक वा बढी क्षेत्रहरू हेर्न सक्छौं - ती बिन्दुहरू जुन उहाँ भौगोलिक रूपमा नजिक छ।

यसले कसरी काम गर्छ?

हामी क्षेत्र अनुसार फाइलहरूको लोकप्रियता गणना गर्छौं। त्यहाँ धेरै क्षेत्रीय क्यास छ जहाँ प्रयोगकर्ता अवस्थित छ, र एउटा फाइल पहिचानकर्ता - हामी यो जोडी लिन्छौं र प्रत्येक डाउनलोडको साथ मूल्याङ्कन बढाउँछौं।

एकै समयमा, राक्षसहरू - क्षेत्रहरूमा सेवाहरू - समय-समयमा API मा आउँछन् र भन्छन्: "म यस्तो र यस्तो क्यास हुँ, मलाई मेरो क्षेत्रमा सबैभन्दा लोकप्रिय फाइलहरूको सूची दिनुहोस् जुन अहिलेसम्म ममा छैन। " एपीआईले रेटिङद्वारा क्रमबद्ध गरिएका फाइलहरूको गुच्छा डेलिभर गर्दछ, डेमनले तिनीहरूलाई डाउनलोड गर्छ, तिनीहरूलाई क्षेत्रहरूमा लैजान्छ र त्यहाँबाट फाइलहरू डेलिभर गर्दछ। यो क्यासबाट pu/pp र Sun बीचको आधारभूत भिन्नता हो: तिनीहरूले तुरुन्तै फाइल आफैं मार्फत दिन्छन्, यो फाइल क्यासमा नभए पनि, र क्यासले पहिले फाइल आफैमा डाउनलोड गर्छ, र त्यसपछि फिर्ता दिन थाल्छ।

यस अवस्थामा हामीले पाउँछौं प्रयोगकर्ताहरूको नजिक सामग्री र नेटवर्क लोड फैलाउन। उदाहरणका लागि, मस्को क्यासबाट मात्र हामी चरम घण्टामा 1 Tbit/s भन्दा बढी वितरण गर्छौं।

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

हामीले सामान्य वास्तुकला हेर्यौं।

• अनुरोधहरू स्वीकार गर्ने फ्रन्ट सर्भरहरू।
• प्रक्रिया अनुरोधहरूलाई ब्याकएन्ड गर्दछ।
• दुई प्रकारका प्रोक्सीहरूद्वारा बन्द गरिएका भण्डारहरू।
• क्षेत्रीय क्यासहरू।

यो रेखाचित्रबाट के छुटेको छ? अवश्य पनि, डाटाबेस जसमा हामीले डाटा भण्डारण गर्छौं।

डाटाबेस वा इन्जिनहरू

हामी तिनीहरूलाई डाटाबेस होइन, तर इन्जिनहरू - इन्जिनहरू भन्छौं, किनभने हामीसँग व्यावहारिक रूपमा सामान्य रूपमा स्वीकार्य अर्थमा डाटाबेसहरू छैनन्।

यो आवश्यक उपाय हो। यो भयो किनभने 2008-2009 मा, जब VK लोकप्रियतामा विस्फोटक वृद्धि भएको थियो, परियोजनाले MySQL र Memcache मा पूर्ण रूपमा काम गर्यो र त्यहाँ समस्याहरू थिए। MySQL लाई क्र्यास र भ्रष्ट फाइलहरू मन पर्यो, जस पछि यो रिकभर हुँदैन, र Memcache बिस्तारै कार्यसम्पादनमा घट्यो र पुन: सुरु गर्नुपर्‍यो।

यसले पत्ता लगायो कि बढ्दो लोकप्रिय परियोजनामा ​​लगातार भण्डारण थियो, जसले डेटा भ्रष्ट गर्छ, र क्यास, जो ढिलो हुन्छ। यस्तो अवस्थामा, बढ्दो परियोजना विकास गर्न गाह्रो छ। यो महत्वपूर्ण कुराहरु लाई पुन: लेख्ने प्रयास गर्ने निर्णय गरियो जुन परियोजना हाम्रो आफ्नै साइकलमा केन्द्रित थियो।

समाधान सफल भयो। त्यहाँ यो गर्न को लागी एक अवसर थियो, साथै एक चरम आवश्यकता, किनभने स्केलिंग को अन्य तरिकाहरु त्यो समयमा अवस्थित थिएन। त्यहाँ डाटाबेसहरूको गुच्छा थिएन, NoSQL अझै अवस्थित थिएन, त्यहाँ MySQL, Memcache, PostrgreSQL मात्र थिए - र यो हो।

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

इन्जिन को प्रकार

टोलीले धेरै इन्जिनहरू लेखे। यहाँ तिनीहरू मध्ये केही छन्: साथी, संकेत, छवि, ipdb, अक्षरहरू, सूचीहरू, लगहरू, memcached, meowdb, समाचार, nostradamus, फोटो, प्लेलिस्टहरू, pmemcached, Sandbox, खोज, भण्डारण, मनपर्ने, कार्यहरू, ...

प्रत्येक कार्यको लागि एक विशिष्ट डेटा संरचना आवश्यक पर्दछ वा असामान्य अनुरोधहरू प्रशोधन गर्दछ, 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?

हामीसँग TL योजनाको शीर्षमा चल्ने इन्जिन अनुरोधहरू कार्यान्वयन गर्नको लागि RPC प्रोटोकल छ। यो सबै TCP/UDP जडानमा काम गर्दछ। TCP बुझ्न सकिन्छ, तर हामीलाई किन UDP चाहिन्छ?

UDP मद्दत गर्दछ सर्भरहरू बीच जडानहरूको ठूलो संख्याको समस्याबाट बच्न। यदि प्रत्येक सर्भरमा RPC प्रोक्सी छ र, सामान्यतया, यो कुनै पनि इन्जिनमा जान सक्छ, त्यसपछि त्यहाँ प्रति सर्भर हजारौं TCP जडानहरू छन्। त्यहाँ एक भार छ, तर यो बेकार छ। UDP को मामला मा यो समस्या अवस्थित छैन।

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

हो, यो सबै काम गर्दछ प्याकेट हानि को एक धेरै सानो प्रतिशत संग। प्रोटोकलमा रिट्रान्समिट र टाइमआउटको लागि समर्थन छ, तर यदि हामीले धेरै गुमायौं भने, हामीले लगभग TCP प्राप्त गर्नेछौं, जुन फाइदाजनक छैन। हामी महासागरहरूमा UDP चलाउँदैनौं।

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

लगातार डाटा भण्डारण

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

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

म छिट्टै सञ्चालनको सिद्धान्त वर्णन गर्नेछु। त्यहाँ एउटा सर्भर छ जसमा इन्जिन चल्छ। उसले लेख्नको लागि नयाँ खाली बिनलग खोल्छ र त्यसमा परिवर्तनको लागि घटना लेख्छ।

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

कुनै बिन्दुमा, जब इन्जिन पुन: सुरु हुन्छ, त्यहाँ डिस्कमा बिनलग र स्न्यापसट दुवै हुनेछ। इन्जिनले सम्पूर्ण स्न्यापसट पढ्छ र निश्चित बिन्दुमा यसको अवस्था बढाउँछ।

स्न्यापसट सिर्जना गर्दाको स्थिति र बिनलगको साइज पढ्छ।

हालको अवस्था प्राप्त गर्न बिनलगको अन्त्य पढ्छ र थप घटनाहरू लेख्न जारी राख्छ। यो एक साधारण योजना हो; हाम्रा सबै इन्जिनहरू यसको अनुसार काम गर्छन्।

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

नतिजाको रूपमा, हाम्रो मा डाटा प्रतिकृति कथन आधारित — हामी binlog मा कुनै पृष्ठ परिवर्तन होइन, तर नाम लेख्छौं अनुरोधहरू परिवर्तन गर्नुहोस्। नेटवर्कमा आउने कुरासँग धेरै मिल्दोजुल्दो, थोरै परिमार्जन मात्र।

एउटै योजना प्रतिकृतिको लागि मात्र होइन, तर पनि प्रयोग गरिन्छ ब्याकअपहरू सिर्जना गर्न। हामीसँग एउटा इन्जिन छ - एक लेखन मास्टर जसले बिनलगमा लेख्छ। अन्य कुनै पनि ठाउँमा जहाँ प्रशासकहरूले यसलाई सेट अप गरे, यो बिनलग प्रतिलिपि गरिएको छ, र यो हो - हामीसँग ब्याकअप छ।

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

यहाँ ढिलाइ धेरै सानो छ, र यो पत्ता लगाउन सम्भव छ कि प्रतिकृति मास्टर पछि कति पछाडी छ।

RPC प्रोक्सीमा डाटा शेर्डिङ

शेर्डिङले कसरी काम गर्छ? प्रोक्सीले कुन क्लस्टर शार्डमा पठाउने भनेर कसरी बुझ्छ? कोडले यसो भन्दैन: "१५ शार्डको लागि पठाउनुहोस्!" - होइन, यो प्रोक्सी द्वारा गरिन्छ।

सरल योजना पहिलो छ - अनुरोध मा पहिलो नम्बर।

get(photo100_500) => 100 % N.

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

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

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

hash(photo100_500) => 3539886280 % N

हामीले ह्यास, विभाजनको बाँकी र शार्ड नम्बर पनि पाउँछौं।

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

यदि हामीले सर्भरहरूको स्वेच्छाचारी संख्या थप्न वा हटाउन आवश्यक छ भने, हामी प्रयोग गर्छौं रिंग a la Ketama मा लगातार ह्यासिङ। तर एकै समयमा, हामीले डेटाको स्थानीयता पूर्ण रूपमा गुमाउँछौं; हामीले क्लस्टरमा अनुरोध मर्ज गर्नुपर्छ ताकि प्रत्येक टुक्राले आफ्नै सानो प्रतिक्रिया फर्काउँछ, र त्यसपछि प्रतिक्रियाहरूलाई प्रोक्सीमा मर्ज गर्नुहोस्।

त्यहाँ सुपर-विशिष्ट अनुरोधहरू छन्। यो यस्तो देखिन्छ: RPC प्रोक्सीले अनुरोध प्राप्त गर्दछ, कुन क्लस्टरमा जाने र शार्ड निर्धारण गर्दछ। त्यसपछि त्यहाँ कि त लेखन मास्टरहरू छन्, वा, यदि क्लस्टरसँग प्रतिकृति समर्थन छ भने, यसले मागमा प्रतिकृतिमा पठाउँछ। प्रोक्सीले यो सबै गर्छ।

लगहरू

हामी धेरै तरिकामा लगहरू लेख्छौं। सबैभन्दा स्पष्ट र सरल छ memcache मा लगहरू लेख्नुहोस्.

ring-buffer: prefix.idx = line

त्यहाँ एउटा कुञ्जी उपसर्ग छ - लग को नाम, एक रेखा, र त्यहाँ यो लग को आकार छ - लाइन को संख्या। हामी ० देखि लाइनहरूको संख्या माइनस १ मा अनियमित संख्या लिन्छौं। मेमक्याचमा कुञ्जी यो अनियमित संख्यासँग जोडिएको उपसर्ग हो। हामीले लग लाइन र हालको समयलाई मानमा बचत गर्छौं।

जब यो लगहरू पढ्न आवश्यक छ, हामी पूरा गर्छौं बहु प्राप्त गर्नुहोस् सबै कुञ्जीहरू, समय अनुसार क्रमबद्ध, र यसरी वास्तविक समयमा उत्पादन लग प्राप्त गर्नुहोस्। यो योजना प्रयोग गरिन्छ जब तपाइँ वास्तविक समयमा उत्पादनमा केहि डिबग गर्न आवश्यक हुन्छ, केहि पनि तोड्न बिना, रोक्न वा अन्य मेशिनहरूमा ट्राफिकलाई अनुमति नदिई, तर यो लग लामो समय सम्म रहँदैन।

लगहरूको भरपर्दो भण्डारणको लागि हामीसँग इन्जिन छ लग इन्जिन। यही कारणले गर्दा यो सिर्जना गरिएको थियो र व्यापक रूपमा क्लस्टरहरूको ठूलो संख्यामा प्रयोग गरिन्छ। मलाई थाहा भएको सबैभन्दा ठूलो क्लस्टरले 600 TB प्याक गरिएका लगहरू पाउँछ।

इन्जिन धेरै पुरानो छ, त्यहाँ 6-7 वर्ष पुरानो क्लस्टरहरू छन्। त्यहाँ समस्याहरू छन् जुन हामी समाधान गर्न प्रयास गर्दैछौं, उदाहरणका लागि, हामीले लगहरू भण्डारण गर्न सक्रिय रूपमा क्लिकहाउस प्रयोग गर्न थाल्यौं।

ClickHouse मा लगहरू सङ्कलन गर्दै

यो रेखाचित्रले हामी हाम्रो इन्जिनहरूमा कसरी हिंड्छौं भनेर देखाउँछ।

त्यहाँ कोड छ जुन स्थानीय रूपमा RPC मार्फत RPC-proxy मा जान्छ, र यसले इन्जिनमा कहाँ जाने भनेर बुझ्छ। यदि हामी ClickHouse मा लगहरू लेख्न चाहन्छौं भने, हामीले यस योजनामा ​​दुई भागहरू परिवर्तन गर्न आवश्यक छ:

• क्लिकहाउसको साथ केहि इन्जिन बदल्नुहोस्;
• RPC प्रोक्सी प्रतिस्थापन गर्नुहोस्, जसले ClickHouse पहुँच गर्न सक्दैन, केहि समाधानको साथ, र RPC मार्फत।

इन्जिन सरल छ - हामी यसलाई सर्भर वा क्लिकहाउसको साथ सर्भरहरूको क्लस्टरसँग बदल्छौं।

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

कहिलेकाहीँ हामी गैर-मानक समाधानहरूमा RPC योजना लागू गर्न चाहँदैनौं, उदाहरणका लागि, nginx मा। त्यसैले, KittenHouse सँग UDP मार्फत लगहरू प्राप्त गर्ने क्षमता छ।

यदि लगहरू प्रेषक र प्राप्तकर्ताले एउटै मेसिनमा काम गर्छन् भने, स्थानीय होस्ट भित्र UDP प्याकेट गुमाउने सम्भावना एकदम कम छ। तेस्रो-पक्ष समाधान र विश्वसनीयतामा RPC लागू गर्ने आवश्यकता बीचको सम्झौताको रूपमा, हामी केवल UDP पठाउने प्रयोग गर्छौं। हामी पछि यो योजनामा ​​फर्कनेछौं।

निगरानी गर्दै

हामीसँग दुई प्रकारका लगहरू छन्: तिनीहरूको सर्भरमा प्रशासकहरूद्वारा सङ्कलन गरिएका र कोडबाट विकासकर्ताहरूद्वारा लेखिएका लगहरू। तिनीहरू दुई प्रकारका मेट्रिकहरूसँग मेल खान्छ: प्रणाली र उत्पादन.

प्रणाली मेट्रिक्स

यसले हाम्रा सबै सर्भरहरूमा काम गर्दछ नेटडाटा, जसले तथ्याङ्क सङ्कलन गर्दछ र तिनीहरूलाई पठाउँछ ग्रेफाइट कार्बन। तसर्थ, ClickHouse भण्डारण प्रणालीको रूपमा प्रयोग गरिन्छ, र Whisper होइन, उदाहरणका लागि। यदि आवश्यक छ भने, तपाइँ सीधा क्लिकहाउसबाट पढ्न सक्नुहुन्छ, वा प्रयोग गर्नुहोस् ग्राफाना मेट्रिक्स, ग्राफ र रिपोर्टहरूको लागि। विकासकर्ताको रूपमा, हामीसँग Netdata र Grafana मा पर्याप्त पहुँच छ।

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

सुविधाको लागि, हामीले धेरै चीजहरू लेखेका छौं। उदाहरणका लागि, त्यहाँ सामान्य प्रकार्यहरूको एक सेट छ जसले तपाइँलाई तथ्याङ्कहरूमा गणनाहरू, अद्वितीय गणना मानहरू लेख्न अनुमति दिन्छ, जुन कतै अगाडि पठाइन्छ।

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

$stats = statlogsStatData($params)

त्यसपछि, हामी क्रमबद्ध र समूहबद्ध फिल्टरहरू प्रयोग गर्न सक्छौं र तथ्याङ्कहरूबाट हामीले चाहेको सबै गर्न सक्छौं - ग्राफहरू निर्माण गर्नुहोस्, वाचडगहरू कन्फिगर गर्नुहोस्।

हामी धेरै लेख्छौं धेरै मेट्रिक्स घटनाहरूको संख्या 600 बिलियन देखि 1 ट्रिलियन प्रति दिन हो। यद्यपि, हामी तिनीहरूलाई राख्न चाहन्छौं कम्तिमा एक दुई वर्षमेट्रिक्समा प्रवृत्तिहरू बुझ्न। यो सबै सँगै राख्नु एउटा ठूलो समस्या हो जुन हामीले अहिलेसम्म समाधान गर्न सकेका छैनौं। म तपाईलाई बताउछु कि यो विगत केहि वर्ष देखि कसरी काम गरिरहेको छ।

हामीसँग यी मेट्रिकहरू लेख्ने कार्यहरू छन् स्थानीय memcache माप्रविष्टिहरूको संख्या कम गर्न। एक पटक छोटो अवधिमा स्थानीय रूपमा सुरु भयो तथ्याङ्क-डेमन सबै रेकर्ड सङ्कलन। अर्को, राक्षसले मेट्रिक्सलाई सर्भरको दुई तहहरूमा मर्ज गर्दछ लग-कलेक्टरहरू, जसले हाम्रा मेसिनहरूको गुच्छाबाट तथ्याङ्कहरू जम्मा गर्छ ताकि तिनीहरूको पछाडिको तह मर्दैन।

आवश्यक भएमा, हामी लग-कलेक्टरहरूलाई सिधै लेख्न सक्छौं।

तर कोडबाट सिधै कलेक्टरहरूमा लेख्नु, stas-daemom लाई बाइपास गर्दै, एक खराब स्केलेबल समाधान हो किनभने यसले कलेक्टरमा भार बढाउँछ। समाधान मात्र उपयुक्त हुन्छ यदि कुनै कारणले हामीले मेसिनमा मेमक्यास तथ्याङ्क-डेमन उठाउन सक्दैनौं, वा यो क्र्यास भयो र हामी सिधै गयौं।

अर्को, लग-कलेक्टरहरूले तथ्याङ्कहरू मर्ज गर्छन् meowDB - यो हाम्रो डाटाबेस हो, जसले मेट्रिक्स पनि भण्डारण गर्न सक्छ।

त्यसपछि हामी कोडबाट बाइनरी "नजीक-SQL" चयन गर्न सक्छौं।

प्रयोग

2018 को गर्मीमा, हामीसँग आन्तरिक ह्याकाथन थियो, र क्लिकहाउसमा मेट्रिक्स भण्डारण गर्न सक्ने केहिसँग रेखाचित्रको रातो भागलाई प्रतिस्थापन गर्ने प्रयास गर्ने विचार आयो। हामीसँग ClickHouse मा लगहरू छन् - किन प्रयास नगर्ने?

हामीसँग एउटा योजना थियो जसले KittenHouse मार्फत लगहरू लेखेको थियो।

निर्णय गर्यौं रेखाचित्रमा अर्को "*घर" थप्नुहोस्, जसले हाम्रो कोडले UDP मार्फत लेखेको ढाँचामा ठ्याक्कै मेट्रिक्स प्राप्त गर्नेछ। त्यसपछि यो *हाउसले तिनीहरूलाई इन्सर्ट्समा परिणत गर्छ, जस्तै लगहरू, जसलाई KittenHouse ले बुझ्दछ। उसले यी लगहरूलाई क्लिकहाउसमा पूर्ण रूपमा डेलिभर गर्न सक्छ, जुन तिनीहरूलाई पढ्न सक्षम हुनुपर्छ।

memcache, stats-deemon र logs-collectors database को साथ योजना यो एक संग प्रतिस्थापन गरिएको छ।

memcache, stats-deemon र logs-collectors database को साथ योजना यो एक संग प्रतिस्थापन गरिएको छ।

• यहाँ कोडबाट प्रेषण छ, जुन स्थानीय रूपमा StatsHouse मा लेखिएको छ।
• StatsHouse ले UDP मेट्रिक्स लेख्छ, पहिले नै SQL इन्सर्टमा रूपान्तरित, ब्याचहरूमा KittenHouse मा।
• KittenHouse ले तिनीहरूलाई ClickHouse मा पठाउँछ।
• यदि हामी तिनीहरूलाई पढ्न चाहन्छौं भने, हामी तिनीहरूलाई StatsHouse लाई बाइपास गरेर पढ्छौं - सीधा क्लिकहाउसबाट नियमित SQL प्रयोग गरेर।

के यो अझै छ एक प्रयोग, तर हामी यो कसरी बाहिर जान्छ मनपर्छ। यदि हामीले योजनाको साथ समस्याहरू समाधान गर्यौं भने, त्यसपछि हामी यसलाई पूर्ण रूपमा स्विच गर्नेछौं। व्यक्तिगत रूपमा, मलाई आशा छ।

योजना फलाम बचाउँदैन। थोरै सर्भरहरू आवश्यक छन्, स्थानीय तथ्याङ्क-डेमनहरू र लग-कलेक्टरहरू आवश्यक पर्दैन, तर ClickHouse लाई हालको योजनामा ​​भन्दा ठूलो सर्भर चाहिन्छ। कम सर्भरहरू आवश्यक छन्, तर तिनीहरू अधिक महँगो र अधिक शक्तिशाली हुनुपर्छ.

तैनाथ गर्नुहोस्

पहिले, PHP डिप्लोइमेन्ट हेरौं। मा विकास गर्दैछौं जानुहोस्: प्रयोग गर्नुहोस् GitLab и TeamCity तैनाती को लागी। विकास शाखाहरू मास्टर शाखामा मर्ज गरिएका छन्, परीक्षणका लागि मास्टरबाट तिनीहरू स्टेजिङमा र स्टेजिङबाट उत्पादनमा मर्ज हुन्छन्।

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

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

हाम्रा इन्जिनहरूको लागि, जुन अनिवार्य रूपमा बाइनरीहरू पनि छन्, योजना धेरै समान छ:

• git मास्टर शाखा;
• बाइनरी मा .deb;
• संस्करण binlog copyfast मा लेखिएको छ;
• सर्भरहरूमा प्रतिकृति;
• सर्भरले ताजा .dep बाहिर निकाल्छ;
• dpkg -i;
• नयाँ संस्करणमा सुन्दर पुन: सुरुवात।

फरक यो हो कि हाम्रो बाइनरी अभिलेखमा प्याकेज गरिएको छ .deb, र तिनीहरू बाहिर पम्प गर्दा dpkg -i प्रणालीमा राखिएको छ। किन केपीएचपी बाइनरीको रूपमा प्रयोग गरिन्छ, र इन्जिनहरू dpkg को रूपमा प्रयोग गरिन्छ? यस्तै भयो । यसले काम गर्छ - यसलाई नछुनुहोस्।

उपयोगी लिंकहरू:

• Anton Kiryushkin द्वारा रिपोर्ट "Vkontakte प्रणाली प्रशासक। कसरी?" प्रतिलिपिफास्ट र गपशप बारे विवरण संग।
• यूरी Nasretdinov द्वारा रिपोर्ट "कसरी VK ले दशौं हजार सर्भरहरूबाट क्लिकहाउसमा डाटा घुसाउँछ".
• मेरो रिपोर्ट "VKontakte को उदाहरण प्रयोग गरेर बढ्दो परियोजनाको वास्तुकला"तर विकासको दृष्टिकोणबाट, हार्डवेयर होइन।

एलेक्सी अकुलोविच ती मध्ये एक हुन् जसले कार्यक्रम समितिको भागको रूपमा मद्दत गर्दछ PHP रूस 17 मई मा हालैका समयमा PHP विकासकर्ताहरूको लागि सबैभन्दा ठूलो घटना हुनेछ। हामीसँग कस्तो राम्रो पीसी छ हेर्नुहोस् वक्ताहरू (तिनीहरू मध्ये दुई PHP कोर विकास गर्दैछन्!) - यदि तपाईंले PHP लेख्नुभयो भने तपाईंले याद गर्न सक्नुहुन्न जस्तो देखिन्छ।

स्रोत: www.habr.com