आज हम आपको बताएंगे कि कैसे हमने 3 महीने में जावा में Odnoklassniki पर वीडियो सेवा के लिए अपना मंच बनाने में कामयाबी हासिल की।

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

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

Odnoklassniki पर वीडियो सेवा प्रति दिन 10 मिलियन से अधिक अद्वितीय उपयोगकर्ताओं द्वारा उपयोग की जाती है, जो 70 मिलियन से अधिक वीडियो देखते हैं और प्रति दिन 50 हजार वीडियो डाउनलोड करते हैं।

Odnoklassniki वीडियो डेटाबेस में 28 मिलियन से अधिक वीडियो हैं। शाम के समय बाहर जाने वाला यातायात 80 गीगाबिट प्रति सेकंड तक पहुँच जाता है। प्रति दिन डाउनलोड किए गए नए वीडियो के 5 टेराबाइट्स को हमारे आंतरिक प्रारूप में बदल दिया जाता है और 2 टेराबाइट्स आउटपुट होते हैं। परिणामी फ़ाइलें तीन प्रतियों में संग्रहीत की जाती हैं, जो कुल मिलाकर, प्रति दिन नए वीडियो के 6 टेराबाइट्स की मात्रा होती हैं। इनबाउंड डाउनलोड ट्रैफ़िक पीक ऑवर्स के दौरान 2 गीगाबिट तक पहुंचता है।



यह सब किस पर काम करता है? अब वीडियो सर्विस पार्क में लगभग 200 सर्वर हैं, और जल्द ही बहुत कुछ होगा। भंडारण में 70 सर्वर हैं, कुल 5 पेटाबाइट्स हैं। 30 सर्वर मेटाडेटा को संग्रहीत करने में लगे हुए हैं, यह एक डेटाबेस है और उनके सामने कैश है। एक और 60 सर्वर कस्टम वीडियो को हमारे प्रारूपों में बदल रहे हैं। एक और 30 सर्वर - डाउनलोड और वितरण के लिए।



हमने 2010 में वापस Odnoklassniki पर वीडियो सेवा विकसित करना शुरू किया। सबसे पहले, हमारे पास अपना स्वयं का प्लेटफ़ॉर्म नहीं था और हमने उपयोगकर्ताओं को केवल उन सामग्री के लिंक को साझा करने की अनुमति दी जो अन्य संसाधनों पर स्थित थीं: रुट्यूब, यूट्यूब, वीडियो मेल। आरयू। 2011 में, हमने Odnoklassniki पोर्टल के माध्यम से वीडियो डाउनलोड करना शुरू किया, लेकिन यह सब Video.Ru वीडियो प्लेटफॉर्म के आधार पर काम करता था। सेवा बढ़ने लगी, नई आवश्यकताएं बननी शुरू हुईं और जनवरी 2013 में हमने महसूस किया कि वीडियो प्लेटफॉर्म बनाए बिना हमारी सेवा आगे विकसित नहीं हो सकती।

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



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



आइए प्रत्येक चरण के कार्यान्वयन पर अधिक विस्तार से विचार करें।

लदान

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



हमारा वीडियो लोड बैलेंसर कैसा दिखता है? हमारे पास प्रत्येक डेटा सेंटर में 6 सर्वर, 2 हैं। डेटा केंद्रों के अंदर लोड को संतुलित करने के लिए, हम LVS (लिनक्स वर्चुअल सर्वर) का उपयोग करते हैं। यह आपको एक आईपी पते के लिए कई सर्वरों को संग्रहीत करने और उनके कार्यभार के आधार पर उनके लिए अनुरोधों को स्थानांतरित करने की अनुमति देता है।





डेटा केंद्रों के लिए दोष सहिष्णुता सुनिश्चित करने के लिए, हम DNS-GSLB का उपयोग करते हैं। उपयोगकर्ता ऐड वीडियो बटन पर क्लिक करता है, डाउनलोड करने के लिए एक लिंक प्राप्त करता है, फिर डोमेन नाम किसी डेटा केंद्र के आईपी पते में अधिकृत होता है। DNS-GSLB ग्लोबल सर्वर लोड बैलेंसिंग है, इसका मुख्य कार्य डेटा केंद्रों के स्तर पर दोष सहिष्णुता प्रदान करना है। डेटा केंद्र की विफलता की स्थिति में, हमारा DNS इस डेटा केंद्र में डोमेन नाम की अनुमति (समाधान, समाधान) की अनुमति नहीं देगा।

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



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



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

परिवर्तन (ट्रांसकोडिंग)

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



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



फ्लैश और एचटीएमएल 5 द्वारा समर्थित प्रारूपों की जांच करने के बाद, हमने MP4 को मीडिया कंटेनर के रूप में चुना - H264 कोडेक, ऑडियो कोडेक - AAC।



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



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

सब कुछ ठीक है, लेकिन पिछला सर्वर बस कनेक्शन खो सकता है। और हमें कनेक्शन को पुनर्स्थापित करते समय अनावश्यक कार्य करने के लिए सर्वर की आवश्यकता नहीं होती है, जो एक और सर्वर पहले से ही कर रहा है। ऐसा करने के लिए, हर बार कतार की जाँच करते हुए, हम काम जारी रखने का अवसर लौटाते हैं। यही है, एल्गोरिथ्म इस प्रकार है: सर्वर जाग गया, कतार में बदल गया और कहा कि यह कार्य को जारी रखेगा। कतार जवाब देती है कि कार्य अब प्रासंगिक नहीं है, और सर्वर एक नया कार्य करता है।

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

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



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



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

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

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

भंडारण

वीडियो काटने के बाद, इसे रिपॉजिटरी में भेजा जाता है। अब इसमें लगभग 70 सर्वर शामिल हैं, जिनमें से प्रत्येक में 36 दो-टेराबाइट ड्राइव हैं। कुल 5 पेटाबाइट्स। वितरित, दोष सहिष्णु भंडारण, इसे वन ब्लॉब स्टोरेज (ओबीएस) कहा जाता है। क्लस्टर की स्थिति को संग्रहीत करने के लिए, हम ज़ुकाइपर का उपयोग करते हैं। वीडियो 64 मेगाबाइट के ब्लॉक में डिस्क पर संग्रहीत हैं। इस भंडारण के लिए, हार्ड ड्राइव की विफलता कोई समस्या नहीं है। सर्वर पर अतिरिक्त ड्राइव हैं। उनमें से एक की विफलता की स्थिति में, दूसरा स्वचालित रूप से इसकी स्थिति को पुनर्स्थापित करता है। हम प्रत्येक वीडियो को तीन प्रतियों में रखते हैं। इस प्रकार, प्रत्येक वीडियो से चार नए वीडियो प्राप्त किए जाते हैं, जिनमें से प्रत्येक को तीन प्रतियों में सहेजा जाता है, प्रत्येक डीसी में एक।

सामग्री वितरण

शायद सबसे दिलचस्प हिस्सा। आवश्यकताएँ:

• पूर्व बफरिंग के बिना किसी भी क्षण से वीडियो आउटपुट।
• उच्च प्रदर्शन, हमें प्रति सेकंड 150 गीगाबिट्स की उम्मीद थी।
• दोष सहिष्णुता।

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

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



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

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

छद्म स्ट्रीमिंग

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





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



हमारे वितरक की वास्तुकला पर विचार करें। यह हमारे स्थायी भंडारण के बीच एक कैशिंग परत है, इसमें कई स्तर के कैश हैं। ऐतिहासिक रूप से, हमें सर्वर पर लगभग 96 गीगाबाइट रैम आवंटित किया गया है। यहां हमने एक और एसएसडी-ड्राइव लगाया।



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

96 गीगाबाइट कैश आवश्यकताएं:

• कैश को GC को प्रभावित नहीं करना चाहिए, यह LRU होना चाहिए। अब हमारा सर्वर प्रति सेकंड लगभग 20 हजार अनुरोधों को संसाधित करता है, अर्थात, यह उच्च-प्रदर्शन होना चाहिए।
• कैश निरंतर होना चाहिए, अर्थात वितरण सेवा के पुनरारंभ या अद्यतन के बाद बने रहें।

डिस्क पर कैशिंग के दूसरे स्तर की आवश्यकताएं कम हैं। यह FIFO कैशिंग का उपयोग करने के लिए पर्याप्त है, आंतरिक OBS समाधान भी स्थानीय रूप से लागू किया जाता है।



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



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



परीक्षण के परिणामों के अनुसार, हम सफलतापूर्वक 20 गीगाबिट्स के वितरण के साथ सामना करते हैं। यही है, जितना बाहरी नेटवर्क कार्ड हमें प्रदान कर सकते हैं। इस मामले में, प्रोसेसर लोड लगभग 30% है। अब हमारे इंजीनियर सिस्टम को फिर से कॉन्फ़िगर करने और अधिक वितरण शुरू करने के लिए काम कर रहे हैं। मुख्य सीमा एक सर्वर पर 6 स्लॉट और हमारे कैश की प्रभावशीलता है। हमें यह कहीं 80/20 मिला: 80% ब्लॉक अनुरोध कैश से लिए गए, 20% अनुरोध OBS के हैं। यह शायद बुरा नहीं है, लेकिन 20 गीगाबिट्स के लिए हम लगभग पूरी तरह से ईथरनेट स्टोर के 4 गीगाबिट्स के संसाधन को अपने स्थायी भंडारण के लिए चुनते हैं।

संतुलन

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



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



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

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

इस तरह के एक दिलचस्प तथ्य है: अगस्त 2012 में, जब मंगल पर रोवर उतरा, तो नासा ने एक ऑनलाइन वीडियो प्रसारण आयोजित करने का फैसला किया। ऐसा करने के लिए, उन्होंने नगनेक्स को आमंत्रित किया। Nginx के पास एक प्लेटफ़ॉर्म है जो 40 अमेज़ॅन-ईसी 2 सर्वरों को वितरित करता है, कैश करता है। ये, ज़ाहिर है, सुपर-कुशल सर्वर नहीं हैं, लेकिन 40 टुकड़े काफी गंभीर हैं। इस वीडियो सेवा पर लोड की जाँच के लिए एक परीक्षण कंपनी को आमंत्रित किया गया था, और उन्होंने प्रति सेकंड लगभग 25 गीगाबिट्स के भार का परीक्षण किया। मुझे लगता है कि कुछ संशोधनों के बाद हमारा एक सर्वर प्रति सेकंड 25 गीगाबिट का सामना करेगा। उन्होंने सर्वर बंद कर दिए। सबसे पहले, वे 10 सर्वरों को बाहर लाए, ट्रैफ़िक थोड़ा डूबा, असंतुलित होकर वापस सामान्य हो गया। उन्होंने एक और 10 सर्वर काट दिए, ट्रैफ़िक नीचे बैठ गया और 25 गीगाबिट्स में वापस नहीं आया, लेकिन प्रति सेकंड 12 गीगाबिट्स पर रहा। यह पता चला कि nginx पर वितरण है,बेशक, स्ट्रीमिंग वीडियो का वितरण था, लेकिन उनके पास केवल एक वीडियो स्ट्रिप थी। 20 सर्वरों ने लगभग 12 गीगाबिट का प्रदर्शन प्रदान किया।



नीचे हमारी परियोजना के मुख्य मील के पत्थर हैं। यह ध्यान देने योग्य है कि हमने जनवरी 2013 में विकास शुरू किया था, और मई 2013 में पूरे जावा प्लेटफॉर्म को 100% पोर्टल्स पर लॉन्च किया गया था।

प्रौद्योगिकी के

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

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



वास्तव में, यह है कि इन सभी तकनीकों को हमारे सर्वर पर वितरित किया जाता है। FFMpeg को छोड़कर सब कुछ जावा है।

परिणाम

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



निकट भविष्य की मुख्य योजना HTML5 प्लेयर पर ऐड-ऑन का प्रयास करना है। आप कोडेक्स के साथ FFMpeg के काम में भी सुधार कर सकते हैं। हमें उपयोगकर्ता-डाउनलोड किए गए वीडियो, जैसे कि GPS से सभी प्रकार के दिलचस्प मेटाडेटा मिलते हैं, लेकिन हम अभी भी GPS निर्देशांक का उपयोग नहीं करते हैं।

और वीडियो प्लेटफॉर्म के बारे में कुछ शब्द

हम Odnoklassniki उपयोगकर्ताओं को हमारे आकार में 8 गीगाबाइट तक के वीडियो अपलोड करने की अनुमति देते हैं, जो कि VKontakte पर अपलोड करने के लिए स्वीकृत अधिकतम वीडियो आकार का चार गुना है। और डाउनलोड किए गए वीडियो की अवधि असीमित है (उदाहरण के लिए YouTube, कुछ खातों के लिए 15 मिनट की सीमा है)। हालाँकि, अधिकतम वीडियो रिज़ॉल्यूशन, हमसे कम है - केवल 720p, जो, हालाँकि, HD मानक से मेल खाता है। फिर भी, जल्द ही हम नई क्षमताओं का अधिग्रहण करेंगे, जिससे हम गुणवत्ता को वांछित 1080p तक बढ़ा सकेंगे।

इसके अलावा, अन्य वीडियो संसाधनों के विपरीत, Odnoklassniki सेवा वीडियो प्रारूपों की एक विस्तारित श्रृंखला का समर्थन करती है - .evo और .asf सहित 20 से अधिक हैं। यह प्रतियोगियों के बीच सबसे बड़ा संकेतक है, हालांकि वे MP4 सहित सभी प्रमुख प्रारूपों का समर्थन करते हैं।

डाउनलोड करने की सामग्री न केवल फाइलों के रूप में उपलब्ध है: आप अन्य वीडियो संसाधनों से संदर्भ द्वारा एक वीडियो जोड़ सकते हैं।

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