Erlang पर वीडियो होस्टिंग विकास

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

उन्होंने वीडियो और प्रस्तुति को एक एकल वीडियो में लाया, और स्टास फ़ोमिन (एक आदमी और एक भाप इंजन) का एक प्रतिलेख भी रिकॉर्ड किया।

अमूर्त

स्केलेबल वेब सेवाओं के एक डेवलपर मैक्सिम लापशिन ( एर्लीविडियो ) ने एर्लांग पर एक वीडियो स्ट्रीमिंग सर्वर विकसित करने के बारे में बात की। हम ओपन-सोर्स प्रोजेक्ट ErlyVideo के बारे में बात कर रहे हैं - किसी भी वीडियो को प्रसारित करने के लिए एक तेजी से विश्वसनीय, स्केलेबल और मुफ्त सर्वर - सुरक्षा कैमरों से वीडियो कॉन्फ्रेंसिंग तक। प्रौद्योगिकी विशेष रुचि की है, क्योंकि यह एर्लांग के रूप में एक ऐसी अल्पज्ञात भाषा की पसंद थी जिसने विकास की उच्च विश्वसनीयता, मापनीयता और गति प्रदान की थी।

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

ये विशेषताएँ एरलांग को राज्य-स्तरीय ग्राहकों की सेवा के लिए एक उत्कृष्ट विकल्प बनाती हैं: वीडियो स्ट्रीमिंग सर्वर (एर्लीवीडियो), सबसे सामान्य जैबर सर्वर (ईज़बर्ड), पोकर सर्वर (ओपनपॉकर), आदि। रिपोर्ट की जाँच की गई कि एर्लैंग ऐसा करने के लिए कितना सुविधाजनक है।

वीडियो

पॉडकास्ट

पॉडकास्ट लिंक

प्रदर्शन

स्लाइड्स से पीडीएफ को लिंक करें

शब्दशः रिपोर्ट

वीडियो का एक प्रतिलेख Stas Fomin द्वारा रिकॉर्ड किया गया था।

स्ट्रीमिंग क्या है?

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

तो, सामान्य रूप से स्ट्रीमिंग क्या है।

स्लाइड:
YouTube स्ट्रीमिंग नहीं है

YouTube क्या है? बड़ी संख्या में विभिन्न वीडियो वहां संग्रहीत हैं, लेकिन यह स्ट्रीमिंग प्रोजेक्ट नहीं है, वहां कोई स्ट्रीमिंग नहीं है। केवल दस सेकंड के वीडियो हैं जो आपको नगनेक्स-ओम, वेल, या किसी अन्य वेब सर्वर द्वारा दिए गए हैं।

प्रत्येक ब्राउज़र प्रवेश करता है, एक वीडियो प्राप्त करता है और इसे खेलता है। लेकिन इसका स्ट्रीमिंग वीडियो से कोई लेना-देना नहीं है। तब यह सब कहां उपयोग किया जाता है, यह सब किस लिए है?

कस्टम टीवी

स्लाइड:
उपयोगकर्ता वीडियो फ़ाइलों को अपलोड करता है

• एक प्लेलिस्ट बनाता है
• दूसरों के अनुरोध पर, प्लेलिस्ट खेलना शुरू कर देती है
• अगर किसी को जरूरत नहीं है, तो वीडियो नहीं चलाया जाता है

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

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

नियमित नग्नेक्स पर यह सब क्यों नहीं करते?

यह एक रन-इन तकनीक की तरह लगता है, वही YouTube काम करता है, लेकिन नहीं, यह काम नहीं करता है।

एक सपने देखने वाला क्या करता है?

स्लाइड:
एक सपने देखने वाला क्या करता है?

• फ़ाइल कंटेनरों से वीडियो और ऑडियो अनपैक करें
• एक शिपिंग कंटेनर में पैक
• वास्तविक समय के साथ समकालिक फ्रेम भेजता है

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

इस कार्य के लिए, आपको बस एक स्ट्रीमर की आवश्यकता होती है, अर्थात् एक स्ट्रीमिंग वीडियो सर्वर जो ऐसा करेगा।

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

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

कोडेक्स के बारे में पीछे हटें

एक छोटा विषयांतर ताकि हर कोई समझता है कि कोडेक्स और कंटेनर क्या हैं, ताकि कोई भ्रम न हो। एक कोडेक, यह वही है जो आपने इसे प्राप्त किया है ... यह कच्चे डेटा का प्रतिनिधित्व करने के लिए एक प्रारूप है जो कैमरे के मैट्रिक्स से, या माइक्रोफ़ोन से कैप्चर किया जाता है।

एक कंटेनर वह है जो पहले से एन्कोडेड डेटा में पैक किया गया है। उदाहरण के लिए, यदि आप h264 या AAC से मिले हैं, तो ये क्रमशः वीडियो और ऑडियो कोडेक्स हैं। और MP4 ... - ऐसा कोई कोडेक नहीं है, यह एक कंटेनर है जिसमें आप बिल्कुल किसी भी वीडियो और बिल्कुल किसी भी ध्वनि को निकाल सकते हैं।

स्लाइड:

• कोडेक - संपीड़ित ऑडियो और वीडियो डेटा के लिए प्रस्तुति प्रारूप
• कंटेनर - एक फ़ाइल या स्ट्रीम में ऑडियो और वीडियो की एक या अधिक धाराओं के लिए एक पैकेजिंग प्रारूप
• H.264 / AAC - सर्वश्रेष्ठ कोडेक
• MP4 - सबसे छोटी फ़ाइल कंटेनर

उपयोगकर्ता टीवी चरणों

स्लाइड:
उपयोगकर्ता टीवी चरणों

• प्लेलिस्ट डाउनलोड करें
• अनज़िप फ़ाइल
• एक परिवहन कंटेनर में फ्रेम पैक करें (RTMP, MPEG-TS, ...)
• जब ग्राहक निकल जाएं तो सफाई करें
• ग्राहकों को डिस्कनेक्ट किए बिना कोड अपडेट करने दें

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

इस तथ्य के अलावा कि यह प्रतिबंधात्मक है, उपयोगकर्ताओं के लिए बस एक असुविधा है, यह भी बहुत, बहुत, बहुत महंगा है, क्योंकि हमारा यातायात पूरी तरह से बंद हो जाएगा।

पारंपरिक समाधान

आमतौर पर लोग इस तरह के फैसले क्या करते हैं? पारंपरिक समाधान, ये पारंपरिक उपकरण हैं - जावा, सी ++, उनके पास ऐसे उत्पाद हैं जो वीडियो स्ट्रीमिंग के साथ काम करते हैं। यह, उदाहरण के लिए, Red5, एक मुफ़्त, सशुल्क Wowza जावा में लिखा गया है, या यह C ++ में लिखा गया rtmpd है।

जावा में पार्सिंग एमपी

क्या समस्या है ...? खैर, यहां एक उदाहरण मैंने दिया है, यह कोड का एक छोटा सा टुकड़ा है, जावा में RTMP को कैसे पार्स किया जाता है, यह कोड का एक छोटा सा टुकड़ा है, एक फ़ाइल का सौवां हिस्सा।

यह है कि जावा में कोई भी सर्वर कैसा दिखता है, आप करीब से देख सकते हैं - यह फ़ाइल का एक छोटा, छोटा हिस्सा है। इसमें देरी बहुत मुश्किल है।

if (id3v1 instanceof ID3V1_1Tag) { try { // Add the track property graph.add(mp3Resource, processor.resolveIdentifier(IdentifierProcessor.TRCK), factory.createLiteral("" + ((ID3V1_1Tag) id3v1).getAlbumTrack())); } catch (GraphException graphException) { throw new ParserException( "Unable to add track number to id3v1 resource.", graphException); } catch (GraphElementFactoryException graphElementFactoryException) { throw new ParserException( .... ѐ 600   graphElementFactoryException); } } 

पार्सलिंग एमपी को एर्लांग में

एमपी 3 को डीकोड करने के लिए आपको Erlange में लिखना होगा। वह सब है। पाँच पंक्तियाँ। यह पहले से ही अनपैक्ड है और इसे यूजर्स को भेजा जा सकता है।

 decode(<<2#11111111111:11, VsnBits:2, LayerBits:2, _:1, BitRate:4, _/binary>> = Packet) -> Layer = layer(LayerBits), Version = version(VsnBits), <<Frame:(framelength(bitrate({Version,Layer}, BitRate))/binary, Rest/binary>> = Packet, {ok, Frame, Rest}. 

तदनुसार, हमें जो मिलता है - बहुत शुरुआत से, फ़ाइल को अनपैक करने से, कुछ सही नहीं है, जावा और सी ++ में, बहुत सारे कोड हैं, बहुत सारे ओवरहेड तर्क जो हम अपने कोड में लिखते हैं।

लेकिन सबकुछ बन जाता है ... यह सब सनातन चीनी, यह सब पूरी तरह से महत्वहीन हो जाता है जब हजारों ग्राहक हमारे पास आते हैं।

और हमें पूरी तरह से नई प्रकृति की समस्या हो रही है, बिना इस बात की परवाह किए कि वहां कोड लिखना सुविधाजनक है या असुविधाजनक।

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

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

और एक और समस्या यह है कि जब आप हजारों क्लाइंट शुरू करते हैं, तो आपके लिए I / O को व्यवस्थित करना मुश्किल होता है। आपके लिए केवल थ्रेड्स का उपयोग करना पर्याप्त नहीं है, और सिर्फ सॉकेट पर लिखना है, आपको जटिल पुस्तकालयों या घटनाओं का उपयोग करना होगा जो विभिन्न जटिल तंत्रों का उपयोग करते हैं।

स्लाइड:
हजारों ग्राहकों के साथ क्लासिक समाधान की चुनौतियां

• मेमोरी मैनेजमेंट: लीक या समयपूर्व रिलीज
• ग्राहक संसाधन नियंत्रण
• एक स्थान पर अराजक प्रणाली की विफलता
• हजारों ग्राहकों की सेवा करते समय इनपुट / आउटपुट

यह क्या है? Red5 सर्वर सौ उपयोगकर्ताओं के अंतर्गत क्रैश हो जाता है। ओह, दुर्भाग्य से, यह लाल नहीं हुआ

पहले से ही एक सौ उपयोगकर्ताओं पर सर्वर गिर जाता है और ग्राहकों की सेवा नहीं करता है। क्यों? हां, क्योंकि यह खराब तरीके से लिखा गया है, इसे विकसित करते समय लोगों ने इसे ध्यान में नहीं रखा, I / O समस्या, और अब, यह सिर्फ सेवा करना बंद कर देता है।

Wowza के मामले में, हमारे पास अन्य समस्याएँ हैं जो मेरे ग्राहकों के पास थीं - उनके पास एक Wowza प्रवाह है, इस तथ्य के बावजूद कि जावा में एक कचरा संग्रहकर्ता है, कहीं न कहीं कुछ लिंक बचा हुआ है, संसाधनों को मुक्त नहीं किया गया है, सर्वर सूजन है, और उस तरह डरावना लगता है।

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

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

स्लाइड:
स्मृति प्रबंधन के कारण लंबे समय तक कनेक्शन के लिए एपोल / केक्यूयू मुश्किल है।

I / O के लिए, एपोल / केक्यूए तंत्र, जिसके लिए libevent लाइब्रेरी हैं, हजारों सॉकेट्स की सेवा करने का एकमात्र तरीका है, वे बहुत, बहुत जटिल हैं, के लिए ... जब आपके पास जटिल व्यावसायिक तर्क होते हैं ... क्योंकि कुशल मेमोरी मैनेजमेंट इन घटना-मॉडल, मेरी राय में, बहुत मुश्किल है।

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

समस्याओं की जड़

कुछ मायनों में, इन समस्याओं की जड़ें पारंपरिक समाधानों से जुड़ी हैं। पहली साझा की गई स्मृति है।

दुर्भाग्य से, तस्वीर फिर से दिखाई नहीं दे रही है।

साझा की गई मेमोरी जो सिस्टम में मौजूद सभी ऑब्जेक्ट्स के बीच साझा की जाती है। कोई भी कहीं भी जा सकता है, किसी भी चीज़ के लिए लिंक ले सकता है, और अंत में, हमें ऐसा डिज़ाइन मिलता है जब सभी ऑब्जेक्ट एक-दूसरे को क्रॉस-रेफर करते हैं, और यह हमारे लिए बहुत मुश्किल है कि कौन और किस चीज की जरूरत है, उनकी स्मृति को नियंत्रित करें। ।

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

स्लाइड:
वेब दृष्टिकोण → "इसे बहने दो, हम जल्द ही मार देंगे" → काम नहीं करता है।

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

एरलंग इन समस्याओं को मौलिक रूप से हल करता है

एर्लैंग एक ऐसा मंच बन गया, जिसने आश्चर्यजनक रूप से, मौलिक रूप से इन समस्याओं को हल किया, और लगभग उन समस्याओं को पूरी तरह से बंद कर दिया जिनके बारे में मैंने बात की थी।

प्रक्रियाओं की अपनी अवधारणा के कारण यह 90% किया गया था।

स्लाइड:
प्रक्रियाओं

• समानांतर धागे
• पृथक स्मृति क्षेत्र
• मैसेजिंग एक्सचेंज
• अपरिवर्तनीय चर
• प्रक्रियाओं के बाहर कोई डेटा नहीं

Erlange में प्रक्रियाएं, यह सामान्य सिस्टम में थ्रेड्स की तरह है। वे हल्के होते हैं, वे बहुत कम जगह लेते हैं, और सबसे महत्वपूर्ण बात, वे पूरी तरह से अलग-थलग हैं।

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

प्रश्न: लेकिन बायनेरिज़ को संदर्भ द्वारा प्रक्रियाओं के बीच स्थानांतरित किया जाता है?

ठीक है, ये कार्यान्वयन की पेचीदगियां हैं, लेकिन वास्तव में, इन बायनेरिज़ का हमेशा पता लगाया जा सकता है। उनकी जांच की जा रही है।

प्रश्न: क्या और कैसे?

हम जानते हैं कि प्रक्रिया यह जानती है कि यह किस बायनेरी और किस आकार को संदर्भित करता है।

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

स्लाइड:
सभी डेटा प्रगणित वस्तुओं के अंदर संग्रहीत किया जाता है।

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

स्लाइड:
हैंडलिंग में त्रुटि

• उन्हें पकड़ा जा सकता है
• यदि आप नहीं पकड़ते हैं, तो प्रक्रिया समाप्त हो जाती है
• पड़ोसी इसे संदेशों के माध्यम से सीखते हैं
• गारंटीकृत स्ट्रिपिंग संसाधन

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

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

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

स्लाइड:
प्रक्रिया ट्रैकिंग

• संचार
• पर्यवेक्षकों
• appmon

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

लेकिन, दुर्भाग्य से, मैं आपको नहीं दिखाऊंगा। :(

Erlang का असली हॉट कोड अपडेट

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

स्लाइड:
ग्राहकों को डिस्कनेक्ट किए बिना!

अन्य प्रणालियाँ जो मुझे ऐसा करने की अनुमति देती हैं, मैं नहीं जानता।

Erlang का उपयोग करने के परिणाम क्या हैं?

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

स्लाइड:
Erlyvideo:

• मल्टीप्रोटोकॉल सर्वर
• एक सर्वर पर हजारों ग्राहक मिलते हैं
• प्लगइन्स के लिए मौजूदा बुनियादी ढांचा

उदाहरण के लिए, यह एक ही सर्वर से हजारों ग्राहकों को सामान्य रूप से काम करता है, अब यह BD (???) के उत्पादन में है और यह काम करता है।

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

इसलिए, यह प्लगइन्स के लिए एक बहुत ही सुविधाजनक बुनियादी ढाँचा निकला, जो बहुत सक्रिय रूप से विकसित हो रहा है।

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

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

निष्कर्ष

स्लाइड:
वीडियो स्ट्रीमिंग कार्यों में ऐसी विशिष्टताएँ हैं जो उन्हें वेब से अलग करती हैं:

• एक ही समय में आवश्यक कुशल और उच्च-स्तरीय उपकरण
• Erlang इस जगह में पूरी तरह से फिट बैठता है
• व्यावहारिक उपयोग ने पसंद की प्रभावशीलता को दिखाया है

अंत में, इस कार्य के लिए एर्लंगा के उपयोग से क्या निष्कर्ष निकाला जा सकता है?

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

आपको ये समस्याएं नहीं होंगी, क्योंकि ... सिर्फ कोड के विशिष्ट संगठन के कारण।

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

फिटकरी मिटती है

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

स्लाइड:

• वीडियो स्ट्रीमिंग (erlyvideo)
• जब्बार सर्वर (ejabberd)
• बैंक प्रसंस्करण (निजी बैंक)
• ऑनलाइन खेल (ऑनलाइन पोकर)

हालांकि, इसके पास प्रयोज्यता के अन्य कारण हैं, उदाहरण के लिए, सबसे अच्छा Jabbera सर्वर एक ही erlang पर बनाया गया है, यह Ejabberd है, यह इतना अच्छा है कि Yandex में, उदाहरण के लिए, erlang के लिए भयानक एंटीपैथी के बावजूद, उन्होंने इसका उपयोग करने का फैसला किया, हां, यश? क्या ग्रिशा एर्लांग (बॉबुक) को दृढ़ता से नापसंद करता है? उसने शाप दिया और बहुत थूक दिया, लेकिन उनके पास कोई विकल्प नहीं था - यह उत्पाद के बारे में बहुत कुछ कहता है। उदाहरण के लिए, यह विश्वसनीय रूप से ज्ञात है कि बैंक बैंकिंग प्रसंस्करण प्रणाली बनाते हैं। मुझे नहीं पता, निश्चित रूप से, कौन से विशेष विवरण, निश्चित रूप से, विवरणों का खुलासा नहीं किया गया है, लेकिन मुझे पता है कि प्राइवेट-बैंक के पास कई कंपनियां हैं जो अपने लंबे समय तक प्रसंस्करण प्रणालियों को एर्लांग में स्थानांतरित करती हैं, क्योंकि वे इसे सुविधाजनक पाते हैं।

और हां, ऑनलाइन गेम्स। लोग नियमित रूप से मेरी ओर मुड़ते हैं, शीर्ष VKontakte खिलौना को उतारने के साथ हमारी सफलता के बाद, अर्थात, लोग "हमें ऐसा करना चाहिए ताकि यह हमारे लिए अच्छी तरह से और आसानी से काम करे।"

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

और erlang पर पोकर का ऑनलाइन कार्यान्वयन भी है।

प्रश्न?

तो, सामान्य तौर पर, मेरे पास शायद सब कुछ है, यह मुझे मिली रिपोर्ट है। यदि आपके कोई प्रश्न हैं, तो मुझे उनका उत्तर देने में खुशी होगी।

स्लाइड:

• मैक्स लापिशिन
• max@maxidoors.ru
• erlyvideo.org

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