मैं Odnoklassniki प्लेटफ़ॉर्म की टीम में काम करता हूं और आज मैं संगीत वितरण सेवा की वास्तुकला, डिजाइन और कार्यान्वयन के बारे में बात करूंगा।

लेख जोकर 2018 की रिपोर्ट का एक प्रतिलेख है।

कुछ आँकड़े

सबसे पहले, ओके के बारे में कुछ शब्द। यह एक विशाल सेवा है जिसका उपयोग 70 मिलियन से अधिक उपयोगकर्ताओं द्वारा किया जाता है। उन्हें 4 डेटा केंद्रों में 7 हजार कारों द्वारा सेवा दी जाती है। हाल ही में, हमने कई सीडीएन साइटों को ध्यान में रखे बिना 2 टीबी / एस पर यातायात चिह्न के माध्यम से तोड़ दिया है। हम अपने हार्डवेयर से अधिकतम को निचोड़ते हैं, सबसे भरी हुई सेवाएं क्वाड-कोर नोड से प्रति सेकंड 100,000 अनुरोधों तक पहुंचती हैं। इसके अलावा, लगभग सभी सेवाएँ जावा में लिखी जाती हैं।

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

संगीत वितरक उपयोगकर्ता खिलाड़ियों और मोबाइल एप्लिकेशन को डेटा स्थानांतरित करने के लिए जिम्मेदार है। यदि आप Musicd.mycdn.me डोमेन के अनुरोधों को देखते हैं, तो आप इसे वेब निरीक्षक में पकड़ सकते हैं। वितरक एपीआई अत्यंत सरल है। यह HTTP अनुरोधों को GET करने और अनुरोधित ट्रैक श्रेणी को जारी करने का जवाब देता है।



चरम पर, लोड आधे मिलियन कनेक्शन के माध्यम से 100 जीबी / एस तक पहुंचता है। वास्तव में, संगीत वितरक हमारे आंतरिक ट्रैक रिपॉजिटरी के सामने एक कैशिंग दृश्य है, जो वन ब्लॉब स्टोरेज और वन कोल्ड स्टोरेज पर आधारित है और जिसमें डेटा की पेटबाइट्स हैं।

चूंकि मैंने कैशिंग के बारे में बात की है, तो आइए प्लेबैक आंकड़ों को देखें। हम एक स्पष्ट शीर्ष देखते हैं।



लगभग 140 ट्रैक प्रति दिन सभी नाटकों का 10% कवर करते हैं। अगर हम चाहते हैं कि हमारा कैश सर्वर कम से कम 90% कैश हिट हो, तो हमें इसमें फिट होने के लिए आधा मिलियन ट्रैक चाहिए। 95% - लगभग एक मिलियन ट्रैक।

वितरक आवश्यकताएँ

वितरक के अगले संस्करण को विकसित करते समय हमने खुद को क्या लक्ष्य निर्धारित किया था?

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

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

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

क्षैतिज मापनीयता की बात करें तो एक दिलचस्प प्रभाव उत्पन्न होता है: जब आपके पास हजारों सर्वर और दसियों हज़ार डिस्क होते हैं, तो कुछ लगातार टूटता है। डिस्क विफलता एक दिनचर्या है, हम उन्हें प्रति सप्ताह 20-30 टुकड़ों में बदलते हैं। और सर्वर विफलताओं से किसी को आश्चर्य नहीं होता है, दिन में 2-3 कारों को बदला जा रहा है। मुझे डेटा सेंटर विफलताओं से भी निपटना था, उदाहरण के लिए, 2018 में ऐसी तीन विफलताएं थीं, और यह शायद आखिरी बार नहीं है।

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

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

संतुलन

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

उपयोगकर्ता से नोड के लिए अनुरोध पथ कैसा दिखता है, जो खाते के संतुलन को ध्यान में रखते हुए डेटा लौटाएगा?



उपयोगकर्ता वेबसाइट या मोबाइल एप्लिकेशन के माध्यम से लॉग इन करता है और ट्रैक का URL प्राप्त करता है:

musicd.mycdn.me/v0/stream?id=...

URL में होस्ट नाम से आईपी पता प्राप्त करने के लिए, क्लाइंट हमारे जीएसएलबी डीएनएस से संपर्क करता है, जो हमारे सभी डेटा सेंटर और सीडीएन साइटों के बारे में जानता है। जीएसएलबी डीएनएस क्लाइंट को एक डेटा सेंटर के बैलेंसर का आईपी पता देता है, और क्लाइंट इसके साथ एक कनेक्शन स्थापित करता है। बैलेंसर डेटा सेंटर के अंदर सभी नोड्स और उनके वजन के बारे में जानता है। यह, उपयोगकर्ता की ओर से, नोड्स में से एक के साथ एक संबंध स्थापित करता है। हम N4Ware आधारित L4 balancers का उपयोग करते हैं । Noda यूजर डेटा को सीधे बैलेंसर को दरकिनार कर देता है। एक वितरक जैसी सेवाओं में, आउटगोइंग ट्रैफ़िक आवक की तुलना में काफी अधिक है।

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

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

इस समस्या को विभिन्न तरीकों से हल किया जा सकता है । हम लगातार हैशिंग पर बस गए। हम एक रिंग में ट्रैक पहचानकर्ताओं के हैश की पूरी संभव रेंज को लपेटते हैं, और फिर प्रत्येक ट्रैक इस रिंग के एक बिंदु पर प्रदर्शित होता है। फिर हम कम या ज्यादा समान रूप से क्लस्टर में नोड्स के बीच रिंग रेंज वितरित करते हैं। ट्रैक को स्टोर करने वाले नोड्स को रिंग के एक बिंदु पर पटरियों पर हैशिंग द्वारा और दक्षिणावर्त घूमते हुए चुना जाता है।



लेकिन इस तरह की योजना में एक खामी है: नोड एन 2 की विफलता के मामले में, उदाहरण के लिए, इसका पूरा भार रिंग में अगली प्रतिकृति पर गिर जाएगा - एन 3। और अगर प्रदर्शन में इसका दोहरा अंतर नहीं है - और यह आर्थिक रूप से उचित नहीं है - तो, ​​सबसे अधिक संभावना है, दूसरे नोड का भी बुरा समय होगा। एन 3 उच्च संभावना के साथ विकसित होगा, लोड एन 4 पर जाएगा, और इसी तरह - पूरे रिंग के साथ एक झरना विफलता होगी।

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



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

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

सुसंगत हैशिंग के साथ ऐसी प्रणाली में उपयोगकर्ता को वापसी ट्रैक कैसा दिखता है?

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



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

एक नोड कैसे काम करता है?

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

नोड लोड

आइए हम अनुमान लगाते हैं कि इस कॉन्फ़िगरेशन में एक नोड को क्या लोड रखना चाहिए। हमारे पास तीन डेटा केंद्र हैं जिनमें प्रत्येक में चार नोड हैं।



पूरी सेवा को 120 Gbit / s, यानी 40 Gbit / s प्रति डेटा सेंटर पर देना चाहिए। मान लीजिए कि नेटवर्क ने युद्धाभ्यास किया या कोई दुर्घटना हुई, और दो डेटा सेंटर DC1 और DC3 बचे थे। अब उनमें से प्रत्येक को 60 Gbit / s देना चाहिए। लेकिन यहां डेवलपर्स के ऊपर कुछ अपडेट रोल करना था, प्रत्येक डेटा सेंटर में 3 लाइव नोड्स बचे थे और उनमें से प्रत्येक को 20 Gbit / s देना चाहिए।



लेकिन शुरू में प्रत्येक डेटा सेंटर में 4 नोड थे। और अगर हम डेटा सेंटर में दो प्रतिकृतियां संग्रहीत करते हैं, तो 50% की संभावना के साथ, अनुरोध प्राप्त करने वाला नोड अनुरोधित ट्रैक की प्रतिकृति नहीं होगा और डेटा को प्रॉक्सी करेगा। यही है, डेटा सेंटर के अंदर यातायात का आधा हिस्सा अनुमानित है।



तो, एक नोड को उपयोगकर्ताओं को 20 जीबी / एस देना चाहिए। इनमें से 10 Gb / s यह अपने पड़ोसियों से डेटा सेंटर में खींचती है। लेकिन यह योजना सममित है: नोड डेटा सेंटर में पड़ोसियों को समान 10 जीबी / एस देता है। यह पता चला है कि 30 Gbit / s नोड से बाहर जाता है, जिसमें से 20 Gbit / s को स्वयं द्वारा सेवित किया जाना चाहिए, क्योंकि यह अनुरोधित डेटा की प्रतिकृति है। इसके अलावा, डेटा डिस्क से या रैम से जाएगा, जो लगभग 50 हजार "हॉट" ट्रैक रखता है। हमारे प्लेबैक आंकड़ों के आधार पर, यह आपको डिस्क से लोड का 60-70% निकालने की अनुमति देता है, और लगभग 8 जीबी / एस रहेगा। यह धागा एक दर्जन एसएसडी देने में काफी सक्षम है।

एक नोड पर डेटा भंडारण

यदि आप प्रत्येक ट्रैक को एक अलग फ़ाइल में रखते हैं, तो इन फ़ाइलों को प्रबंधित करने का ओवरहेड बहुत बड़ा होगा। यहां तक ​​कि नोड्स को पुनरारंभ करने और डिस्क पर डेटा को स्कैन करने में मिनट लगेंगे, यदि दसियों मिनट नहीं।

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

इसलिए, हम इसे पूरी तरह से अलग तरीके से करते हैं: हम पटरियों को 256 KB ब्लॉकों में विभाजित करते हैं, क्योंकि यह SSD में ब्लॉक आकार के साथ संबंधित है, और हम पहले से ही इन ब्लॉकों के साथ काम कर रहे हैं। 1 टीबी की एक डिस्क में 4 मिलियन ब्लॉक होते हैं। नोड में प्रत्येक डिस्क एक स्वतंत्र भंडारण है, और प्रत्येक ट्रैक के सभी ब्लॉक सभी डिस्क में वितरित किए जाते हैं।

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

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

डिस्क पर ब्लॉक कैसे स्टोर करें?

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

सूची

लेकिन यह ब्लॉक को स्टोर करने में सक्षम होने के लिए पर्याप्त नहीं है; आपको डिस्क पर ब्लॉक करने के लिए संगीत पटरियों के ब्लॉक से एक इंडेक्स बनाए रखने की आवश्यकता है।



यह काफी कॉम्पैक्ट निकला, एक सूचकांक प्रविष्टि केवल 29 बाइट्स लेती है। 10 टीबी स्टोरेज के लिए, इंडेक्स 1 जीबी से थोड़ा अधिक है।

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

हमने इंडेक्स के लिए कई आवश्यकताओं को तैयार किया: जल्दी से काम करना (अधिमानतः, रैम में संग्रहीत), कॉम्पैक्ट होने के लिए और पेज कैश पर जगह नहीं लेने के लिए। एक और सूचकांक लगातार होना चाहिए। यदि हम इसे खो देते हैं, तो हम इस बारे में जानकारी खो देंगे कि डिस्क पर किस स्थान पर कौन सा ट्रैक संग्रहीत है, और डिस्क को साफ करने के लिए यह समान है। और सामान्य तौर पर, मैं पुराने ब्लॉकों को पसंद करूंगा, जिन्हें लंबे समय तक एक्सेस नहीं किया गया है, किसी भी तरह से दबाए जाने के लिए, अधिक लोकप्रिय पटरियों के लिए जगह बनाना। हमने LRU क्राउडिंग आउट पॉलिसी को चुना है : ब्लॉक में एक मिनट में एक बार भीड़ होती है, 1% ब्लॉक फ्री रखे जाते हैं। बेशक, सूचकांक संरचना को सुरक्षित होना चाहिए, क्योंकि हमारे पास प्रति नोड 100 हजार कनेक्शन हैं। ये सभी स्थितियाँ हमारे एक-एक nio ओपन सोर्स लाइब्रेरी से SharedMemoryFixedMap द्वारा आदर्श रूप से संतुष्ट हैं।

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

तीन प्रविष्टियों के साथ एक सूचकांक लें: ट्रैक नंबर 1 के दो ब्लॉक और ट्रैक नंबर 2 का एक ब्लॉक।



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



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



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

अनुकूलन

लेकिन यह सब नहीं है, हम गहराई तक जाते हैं।

पेज कैश से शुरू करते हैं। हमने शुरुआत में इसे गिना, लेकिन जब हमने पहले संस्करण का लोड परीक्षण शुरू किया, तो यह पता चला कि पेज कैश हिट दर 20% नहीं थी। उन्होंने सुझाव दिया कि समस्या को आगे पढ़ा जाता है: हम फ़ाइलों को संग्रहीत नहीं करते हैं, लेकिन कनेक्शन के एक समूह की सेवा करते समय, ब्लॉक करते हैं, और इस कॉन्फ़िगरेशन में, डिस्क के साथ काम करना यादृच्छिक रूप से कुशल है। हम लगभग कभी भी क्रमिक रूप से कुछ नहीं पढ़ते हैं। सौभाग्य से, लिनक्स में एक posix_fadvise कॉल है जो आपको कर्नेल को यह बताने की अनुमति देता है कि हम फ़ाइल डिस्क्रिप्टर के साथ कैसे काम करने जा रहे हैं - विशेष रूप से, हम कह सकते हैं कि हमें POSIX_FADV_RANDOM ध्वज को पास करके आगे पढ़ने की आवश्यकता नहीं है। यह सिस्टम कॉल वन-एनआईओ के माध्यम से उपलब्ध है। ऑपरेशन में, हमारा कैश हिट 70-80% है। डिस्क से भौतिक रीडिंग की संख्या 2 गुना से कम हो गई, HTTP प्रतिक्रिया में देरी 20% तक कम हो गई।

आगे चलते हैं। सेवा में बड़े आकार का ढेर होता है। प्रोसेसर के टीएलबी कैश के लिए जीवन को आसान बनाने के लिए, हमने अपनी जावा प्रक्रिया के लिए विशाल पृष्ठ शामिल करने का फैसला किया। नतीजतन, हमें कचरा संग्रहण समय (GC Time / Safepoint Total Time 20-30% कम है) के लिए ध्यान देने योग्य लाभ मिला, कर्नेल लोडिंग अधिक समान हो गई, लेकिन HTTP विलंबता ग्राफ़ पर कोई प्रभाव नहीं देखा।

घटना

( ) .

. , , , , . , - . , . , , . , Daft Punk №2 sdc, sdd.



, . Linux : , .



. ID. WWN , WAL. , , .

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

हम अपने जीवन को इस तरह सरल बनाते हैं। लॉगिन पर, हम ओपन ट्रेन्डिंग और जिपकिन के समान टैग के साथ सभी अनुरोधों को चिह्नित करते हैं . , . , , HTTP- . , , , , , , .

. , : , , .

 ByteBuffer buffer = ByteBuffer.allocate(size); int count = fileChannel.read(buffer, position); if (count <= 0) { // ... } buffer.flip(); socketChannel.write(buffer); 

, :

• FileChannel.read() kernel space user space;
• SocketChannel.write() , user space kernel space.

, Linux sendfile() , , user space. , one-nio . , sendfile() — 10 / sendfile() 0.

user-space SSL- sendfile() , . . SocketChannel FileChannel , Async Profiler , sun.nio.ch.IOUtil , read() write() . .

 ByteBuffer bb = Util.getTemporaryDirectBuffer(dst.remaining()); try { int n = readIntoNativeBuffer(fd, bb, position, nd); bb.flip(); if (n > 0) dst.put(bb); return n; } finally { Util.offerFirstTemporaryDirectBuffer(bb); } 

. heap ByteBuffer , , , heap ByteBuffer , . .

. one-nio . MallocMT — , . SSL , Java heap, ByteBuffer , FileChannel . .

 final Allocator allocator = new MallocMT(size, concurrency); int write(Socket socket) { if (socket.getSslContext() != null) { long address = allocator.malloc(size); ByteBuffer buf = DirectMemory.wrap(address, size); int available = channel.read(buf, offset); socket.writeRaw(address, available, flags); 

100 000

लेकिन निचले स्तर पर उचित कार्यान्वयन से प्रणाली की सफलता की गारंटी नहीं है। यहां एक और समस्या है। प्रत्येक नोड पर कन्वेयर एक साथ 100 हजार तक काम करता है। ऐसी प्रणाली में गणना कैसे व्यवस्थित करें?

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



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

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

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

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

हमारा कन्वेयर जेट स्ट्रीम में बदल जाता है। प्रत्येक चरण पिछले चरण के लिए प्रकाशक और अगले के लिए ग्राहक में बदल जाता है।

जेट धाराओं का इंटरफ़ेस बेहद सरल दिखता है। Publisherसंकेत देता हैSubscriber , और उसे केवल चार हैंडलर लागू करने चाहिए:

 interface Publisher<T> { void subscribe(Subscriber<? super T> s); } interface Subscriber<T> { void onSubscribe(Subscription s); void onNext(T t); void onError(Throwable t); void onComplete(); } interface Subscription { void request(long n); void cancel(); } 

Subscription आप मांग और सदस्यता समाप्त करने के लिए अनुमति देता है। कहीं आसान नहीं है।

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

 interface Chunk { int read(ByteBuffer dst); int write(Socket socket); void write(FileChannel channel, long offset); } 

चूजों के कई कार्यान्वयन हैं:

• सबसे लोकप्रिय एक, जो कैश हिट के मामले में उपयोग किया जाता है और डिस्क से डेटा भेजते समय शीर्ष पर कार्यान्वयन होता है RandomAccessFile। चंक में केवल फ़ाइल का लिंक, इस फ़ाइल में ऑफ़सेट और डेटा का आकार होता है। यह पूरी पाइपलाइन से गुजरता है, उपयोगकर्ता कनेक्शन सॉकेट तक पहुंचता है, और वहां यह कॉल में बदल जाता है sendfile()। यानी मेमोरी का सेवन बिलकुल नहीं किया जाता है।
• cache miss : . , — , , — .
• , - heap. ByteBuffer .

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


हमें पूरी तरह से गैर-अवरुद्ध कार्यान्वयन मिला। कोड सरल और लगातार, बिना volatile, Atomic*, विवाद, और अन्य। हमारे पूरे सिस्टम में, 100,000 कनेक्शन की सेवा के लिए कुल 200 धागे हैं।

अंत में

उत्पादन में, हमारे पास 12 मशीनें हैं, जबकि बैंडविड्थ में एक डबल मार्जिन से अधिक है। सामान्य मोड में प्रत्येक मशीन सैकड़ों कनेक्शन के माध्यम से 10 Gbit / s तक देती है। हमने स्केलेबिलिटी और रिसिलिबिलिटी प्रदान की है। सब कुछ जावा और एक-एक में लिखा है ।



यह सर्वर की तरफ से उपयोगकर्ता को दी गई पहली बाइट तक का ग्राफ है। 20 एमएस से कम 99 प्रतिशत। ब्लू ग्राफ उपयोगकर्ता के लिए HTTPS डेटा की वापसी है। रेड ग्राफ, sendfile()HTTP से HTTP तक प्रतिकृति से डेटा की वापसी है ।

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



यदि आप डिस्क से लौटते समय 75 वें प्रतिशत को देखते हैं, तो पहली बाइट उपयोगकर्ता के लिए 1 एमएस के बाद उड़ जाती है। क्लस्टर के अंदर प्रतिकृतियां और भी अधिक गति के साथ संवाद करती हैं - वे 300 μs के लिए जिम्मेदार हैं। यानी0.7 एमएस प्रॉक्सिमिंग की लागत है।

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