🚡 🤘🏽 👋 एक "अतुल्यकालिक घटना मॉडल" क्या है, और यह अब "फैशन में" क्यों है ✂️ 🧓🏻 ⛽️

अब थीम वाले इंटरनेट में "Node.js" शब्द फैशनेबल है। इस छोटे से लेख में हम समझने की कोशिश करेंगे ("उंगलियों पर") कि यह सब कहां से आया है, और यह आर्किटेक्चर "सिंक्रोनस" और एप्लिकेशन कोड ( PHP + MySQL में नियमित वेबसाइट) में "अवरुद्ध" I / O के साथ सामान्य वास्तुकला से कैसे भिन्न होता है एक एप्लिकेशन सर्वर पर चल रहा है जो "अनुरोध द्वारा स्ट्रीम (या प्रक्रिया) द्वारा" योजना (क्लासिक अपाचे वेब सर्वर ) के अनुसार काम करता है।

लेख की पठनीयता के बारे में

यह लेख, यहाँ दिखाई देने के समय से, कई परिवर्तन (वैचारिक लोगों सहित) और परिवर्धन से गुज़रे हैं, लेख के अंत में उल्लिखित पाठकों से प्रतिक्रिया के लिए धन्यवाद। यदि आपको समझने में कुछ अंश के लिए यह मुश्किल लगता है, तो टिप्पणियों में इसका वर्णन करें, और हम इसे और अधिक समझने योग्य भाषा में एक लेख में लिखेंगे।

प्रदर्शन के बारे में

ट्विटर , VKontakte और facebook जैसी आधुनिक अत्यधिक भरी हुई साइटें PHP + Apache + NoSQL या रूबी ऑन रेल्स + यूनिकॉर्न + NoSQL के बंडलों पर काम करती हैं, और बिल्कुल भी धीमी नहीं होती हैं। सबसे पहले, वे SQL के बजाय NoSQL का उपयोग करते हैं। दूसरे, वे कई समान उत्पादन सर्वरों में अनुरोध ( "संतुलन" ) वितरित करते हैं (इसे "क्षैतिज स्केलिंग" कहा जाता है)। तीसरा, वे सब कुछ संभव है जो कैश करते हैं: पूरे पृष्ठ, पृष्ठ विखंडू, अजाक्स अनुरोधों के लिए Json प्रारूप में डेटा, आदि ... कैश्ड डेटा "स्थिर" है और इसे नाइजेनएक्स जैसे सर्वरों द्वारा तुरंत डिलीवर किया जाता है। आवेदन।

यदि आप Apache + PHP से Node.js. विषयगत इंटरनेट में आप उन दोनों से मिल सकते हैं जो सिस्टम के प्रवाह को "अतुल्यकालिक घटना मॉडल" की तुलना में धीमा मानते हैं, और जो विपरीत दृष्टिकोण का बचाव करते हैं।

अगली परियोजना को किस पर लिखना है, इसके बारे में सोचते हुए, आपको इसके कार्यों से आगे बढ़ना चाहिए, और उस आर्किटेक्चर को चुनना चाहिए जो परियोजना के कार्यों पर अच्छी तरह से आरोपित है।

उदाहरण के लिए, यदि आपका प्रोग्राम कई युगपत कनेक्शनों का समर्थन करता है, और उनसे लगातार लिखता और पढ़ता है, तो इस मामले में आपको निश्चित रूप से "अतुल्यकालिक घटना मॉडल" (उदाहरण के लिए, Node.js) की ओर देखना चाहिए। यदि आप कुछ सबसिस्टम को WebSocket प्रोटोकॉल में बदलना चाहते हैं तो Node.js सही है।

सिस्टम के उदाहरण जो "अतुल्यकालिक घटना मॉडल" अच्छा करेंगे:

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

अवरुद्ध और गैर-अवरुद्ध इनपुट / आउटपुट क्या हैं?

हम नेटवर्क सॉकेट ("सॉकेट" - शाब्दिक, "कनेक्शन बिंदु") के उदाहरण का उपयोग करके इनपुट / आउटपुट के प्रकारों से निपटेंगे, जिसके माध्यम से एक इंटरनेट उपयोगकर्ता हमारी साइट से जुड़ा है और उस पर एक अवतार के लिए एक तस्वीर अपलोड करता है। इस लेख में, हम "अतुल्यकालिक घटना मॉडल" की तुलना "परिचित" वास्तुकला के साथ करेंगे, जहां आवेदन कोड में सभी इनपुट / आउटपुट "तुल्यकालिक" और "अवरुद्ध" है। "आदतन" - केवल इसलिए कि पहले, कोई भी "ताले" के सभी प्रकारों से परेशान नहीं था, और हर किसी ने उस तरह लिखा था, और हर कोई पर्याप्त था। "सिंक्रोनस" और "ब्लॉकिंग" I / O क्या है? यह सबसे सरल और सबसे सामान्य इनपुट / आउटपुट है जिस पर अधिकांश साइटें लिखी गई हैं:

खुली फाइल
इसे पढ़ना शुरू करें
विचार करने तक प्रतीक्षा करें
फाइल पर विचार किया गया
फ़ाइल बंद करें
स्क्रीन पर प्रदर्शन पठन सामग्री

हमारे सॉकेट के मामले में, यह होगा:

सॉकेट सुनना शुरू करें
छवि डेटा के पहले भाग को पढ़ें
छवि डेटा का दूसरा भाग आने तक प्रतीक्षा करें
छवि डेटा के दूसरे भाग को पढ़ें
चित्र डेटा के अगले बैच की प्रतीक्षा करें
...
तस्वीर पर विचार किया गया
उपयोगकर्ता को अवतार पर चित्र डालें

उसी समय, "अवरुद्ध करना" हमारे कार्यक्रम के कोड में होता है, जिसके दौरान धागा बेकार है, हालांकि यह कुछ उपयोगी कर सकता है। इस समस्या को हल करने के लिए, "सिंक्रोनस" और "नॉन-ब्लॉकिंग" I / O का आविष्कार किया गया था:

सॉकेट सुनना शुरू करें
यदि इस पर कोई नया डेटा नहीं है, तो सॉकेट को सुनना बंद कर दें
यदि चित्र डेटा का कोई भाग पहले ही उस पर आ चुका है - इस डेटा को पढ़ें
सॉकेट सुनना बंद करो

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

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

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

आवश्यक शर्तें

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

PHP + MySQL + Apache का गुच्छा , वर्षों में परीक्षण किया गया, जिसने इंटरनेट 1.0 के साथ अच्छा काम किया। सर्वर ने प्रत्येक उपयोगकर्ता के अनुरोध के लिए एक नया सूत्र (या प्रक्रिया, जो ऑपरेटिंग सिस्टम के दृष्टिकोण से लगभग समान है ) शुरू किया। यह स्ट्रीम PHP में गया , वहां से - डेटाबेस में, वहां कुछ का चयन किया, और एक प्रतिक्रिया के साथ लौटा जो इसे HTTP के माध्यम से उपयोगकर्ता को भेजा, जिसके बाद उसने खुद को नष्ट कर दिया।

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

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

शेड्यूलर कितनी बार शुरू होता है यह तय करने के लिए ऑपरेटिंग सिस्टम तक है। उदाहरण के लिए, लिनक्स में, डिफ़ॉल्ट रूप से, अनुसूचक सेकंड के सौवें भाग में कहीं से शुरू होता है। शेड्यूलर को तब भी कहा जाता है जब प्रक्रिया मैन्युअल रूप से "स्लीप फ़ंक्शन" (उदाहरण के लिए, नींद समारोह द्वारा) या "सिंक्रोनस" और "ब्लॉकिंग" की प्रत्याशा में होती है (अर्थात, सबसे सरल और सबसे सामान्य) I / O (उदाहरण के लिए, PHP स्ट्रीम में एक उपयोगकर्ता अनुरोध डेटाबेस का इंतजार करता है डेटा उसे मासिक बिक्री रिपोर्ट देगा)।

सामान्य मामले में , यह माना जाता है कि सिस्टम थ्रेड्स के बीच "संदर्भ स्विचिंग" इतना महंगा नहीं है, और माइक्रोसेकंड के आदेश का है।

यदि थ्रेड सक्रिय रूप से RAM के विभिन्न क्षेत्रों को पढ़ते हैं (और RAM के विभिन्न क्षेत्रों में लिखते हैं), तो ऐसे थ्रेड्स की संख्या में वृद्धि के साथ, वे प्रोसेसर के "दूसरे स्तर के कैश" (L2) को याद करेंगे, जो कि मेगाबाइट के आदेश पर है। इस स्थिति में, उन्हें रैम से प्रोसेसर तक सिस्टम बस पर डेटा की डिलीवरी के लिए, और प्रोसेसर से रैम तक सिस्टम बस में डेटा की रिकॉर्डिंग के लिए हर बार इंतजार करना होगा। रैम तक इस तरह की पहुंच प्रोसेसर कैश तक पहुंच की तुलना में धीमी गति के आदेश है : इस कैश का आविष्कार इसके लिए किया गया था। इन मामलों में, "संदर्भ स्विच" समय 50 माइक्रोसेकंड तक जा सकता है।

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

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

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

लिनक्स पर, डिफ़ॉल्ट स्टैक का आकार 8 मेगाबाइट है , और "मेमोरी पेज" का आकार 4 किलोबाइट है ("स्टैक" के लिए एक या दो "मेमोरी पेज" तुरंत आवंटित किए जाते हैं)। एक साथ लॉन्च किए गए 10,000 थ्रेड्स के संदर्भ में, हमें लगभग 80 मेगाबाइट "वास्तविक" रैम की आवश्यकता होती है। यह थोड़ा सा लगता है, और ऐसा लगता है कि चिंता का कोई कारण नहीं है। लेकिन इस मामले में आवश्यक मेमोरी का आकार ओ (एन) के रूप में बढ़ता है, जो बताता है कि लोड में और वृद्धि के साथ, "स्केलेबिलिटी" के साथ कठिनाइयां हो सकती हैं: क्या होगा यदि कल आपकी साइट पहले से ही एक साथ 100,000 उपयोगकर्ताओं की सेवा करेगी, और 100 को बनाए रखने की आवश्यकता होगी 000 एक साथ कनेक्शन? और परसों - 1,000,000? और कल के बाद के दिन - यह अभी भी अज्ञात है कि कितना ...

सिंगल-थ्रेडेड एप्लिकेशन सर्वरों में यह खामी नहीं होती है, और एक साथ कनेक्शन की संख्या में वृद्धि के साथ नई मेमोरी की आवश्यकता नहीं होती है (इसे ओ (1) कहा जाता है)। Apache Web Server और NginX के मेमोरी उपयोग की तुलना करने वाले इस ग्राफ पर एक नज़र डालें :

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

यदि हम सिस्टम थ्रेड्स के ऐसे "पूल" का उपयोग करते हैं, तो एक ही समय में हम केवल उपयोगकर्ताओं की संख्या की सेवा कर पाएंगे, हमारे पास "पूल" में कितने थ्रेड होंगे, अर्थात् 10,000 नहीं।

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

अतुल्यकालिक घटना मॉडल

अनुप्रयोगों के इस वर्ग के लिए एक नई वास्तुकला की आवश्यकता थी। और इस स्थिति में, बस मामले में, "अतुल्यकालिक घटना मॉडल" सामने आया। यह "घटना चक्र" और टेम्पलेट "रिएक्टर" (शब्द "प्रतिक्रिया" से - प्रतिक्रिया करने के लिए) पर आधारित है।

एक "ईवेंट लूप" एक अंतहीन लूप है जो उनमें किसी प्रकार के "ईवेंट" की उपस्थिति के लिए "घटनाओं के स्रोत" (डिस्क्रिप्टर) का सर्वेक्षण करता है। मतदान "सिंक्रोनस" I / O लाइब्रेरी का उपयोग करके होता है, जो एक ही समय में, "गैर-अवरोधक" होगा (O_NONBLOCK ध्वज सिस्टम I / O फ़ंक्शन के लिए पारित किया गया है)।

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

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

इस स्थिति में, "घटनाओं का स्रोत" बहुत ही टीसीपी सॉकेट का "डिस्क्रिप्टर" (डेटा स्ट्रीम का सूचक) होगा जिसके माध्यम से आप नेटवर्क के माध्यम से साइट से जुड़े।

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

यह नई वास्तुकला Node.js. के आगमन के बाद मुख्यधारा बन गई। Node.js को C ++ में लिखा गया है , और इसके इवेंट लूप को libev C # लाइब्रेरी पर आधारित करता है। हालाँकि, जावास्क्रिप्ट यहाँ एक चुनी हुई भाषा नहीं है: यदि लाइब्रेरी की भाषा में "नॉन-ब्लॉकिंग" I / O है, तो आप इसके लिए समान "फ्रेमवर्क" भी लिख सकते हैं: पायथन में ट्विस्टेड और टोर्नेडो है , पर्ल में पर्ल पर्यावरण है , रूबी है EventMachine (जो पहले से ही पांच साल पुराना है)। इन "फ्रेमवर्क" पर आप Node.js. के समान अपना सर्वर लिख सकते हैं उदाहरण के लिए, जावा के लिए (java.nio पर आधारित) नेट्टी और MINA लिखे गए हैं, और रूबी (EventMachine पर आधारित) के लिए - गोलियत (जो कि फाइबर का लाभ भी उठाता है)।

फायदे और नुकसान

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

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

इसलिए, Node.js जैसे सर्वर केवल उन कार्यों के लिए उपयुक्त हैं जो प्रोसेसर को लोड नहीं करते हैं, या एक भारी बैकएंड के लिए एक फ्रंटेंड के रूप में । और वे "धीमी" अनुरोधों के लिए सर्वर के रूप में भी उपयुक्त हैं (संकीर्ण संचार चैनल, धीमी गति से वापसी / डेटा भेजना, लंबी प्रतिक्रिया समय अंदर कहीं, ...)। मैं एक "इनपुट-आउटपुट" मध्यस्थ की जगह Node.js जैसे सर्वर देता हूं। उदाहरण के लिए, "क्लाइंट" और "सर्वर" के बीच का मध्यस्थ: संपूर्ण दृश्य प्रतिनिधित्व इंटरनेट उपयोगकर्ता के ब्राउज़र में सीधे बनाया और प्रदान किया जाता है, सभी आवश्यक डेटा सर्वर पर रिपॉजिटरी में संग्रहीत होते हैं, और Node.js मध्यस्थ का कार्य करते हैं, "क्लाइंट" अनुरोध पर आवश्यक डेटा देते हैं। , और जब यह "क्लाइंट" से आता है, तो रिपॉजिटरी को नया डेटा लिखना।

तथ्य यह है कि "एसिंक्रोनस इवेंट मॉडल" के अनुसार सर्वर एक ही सिस्टम थ्रेड में चल रहे हैं, व्यवहार में दो और बाधाएं उठाते हैं। पहला है मेमोरी लीक। यदि अपाचे प्रत्येक नए अनुरोध के लिए एक सिस्टम थ्रेड बनाता है, तो, उपयोगकर्ता को एक प्रतिक्रिया भेजने के बाद, यह सिस्टम थ्रेड को स्वयं नष्ट कर देता है, और इसके लिए आवंटित सभी मेमोरी को बस मुक्त कर दिया जाता है। के मामले में, कहते हैं, Node.js, डेवलपर को अगले उपयोगकर्ता अनुरोध को संसाधित करते समय किसी भी निशान को न छोड़ने के लिए सावधान रहना चाहिए (रैम से सभी सबूतों को हटाने के लिए कि इस तरह के अनुरोध सभी पर पहुंचे), अन्यथा प्रक्रिया अधिक से अधिक खा जाएगी। प्रत्येक नए अनुरोध के साथ स्मृति। दूसरा है प्रोग्राम का एरर हैंडलिंग। यदि, फिर से, नियमित अपाचे आने वाले अनुरोध को संसाधित करने के लिए एक अलग सिस्टम थ्रेड बनाता है, और PHP प्रोसेसिंग कोड किसी तरह का "अपवाद" फेंकता है, तो यह सिस्टम थ्रेड केवल चुपचाप "मर" जाएगा, और उपयोगकर्ता को "500" जैसा एक पृष्ठ प्राप्त होगा। आंतरिक सर्वर त्रुटि। "उसी Node.js के मामले में, एक ही अनुरोध को संसाधित करते समय हुई एकमात्र त्रुटि पूरे सर्वर को "डाल" देगी, यही वजह है कि इसे मॉनिटर करना होगा और मैन्युअल रूप से पुनरारंभ करना होगा ।

"अतुल्यकालिक घटना मॉडल" का एक और संभावित दोष यह है कि कभी-कभी (हमेशा नहीं, लेकिन ऐसा होता है, खासकर तब जब "अभिप्रेत घटना मॉडल" का उपयोग उस उद्देश्य के लिए नहीं किया जाता है) "कॉलबैक" के अंतःविषय के कारण आवेदन कोड को समझना मुश्किल हो सकता है। । इसे "स्पेगेटी कोड" समस्या कहा जाता है , और इसे निम्नानुसार वर्णित किया गया है: "कॉलबैक पर कॉलबैक, कॉलबैक का पीछा।" कि कोशिश के साथ लड़ने के लिए, और, उदाहरण के लिए, एक पुस्तकालय लिखा Node.js'a के लिए Seq ।

सामान्य रूप से "कॉलबैक" को खत्म करने का एक और तरीका तथाकथित निरंतरता ( कोराउटाइन ) है। वे पेश किए जाते हैं, उदाहरण के लिए, स्काला में , 2.8 संस्करण ( कोराउटाइन्स ) के साथ, और रूबी में, संस्करण 1.9 ( फाइबर ) के साथ शुरू होता है । यहाँ एक उदाहरण है कि कैसे रूबी में फाइबर्स का उपयोग करके आप कॉलबैक को पूरी तरह से समाप्त कर सकते हैं, और कोड लिख सकते हैं जैसे कि सब कुछ सिंक्रनाइज़ हो रहा है ।

Node.js'a के लिए यह एक ऐसी ही पुस्तकालय लिखा गया था नोड फाइबर । प्रदर्शन के संदर्भ में (कृत्रिम परीक्षणों में, एक वास्तविक अनुप्रयोग में नहीं), नोड-फाइबर अभी भी "कॉलबैक" के साथ सामान्य शैली की तुलना में लगभग तीन से चार गुना धीमी गति से काम करते हैं । पुस्तकालय लेखकयह तर्क दिया जाता है कि यह प्रदर्शन अंतर वहाँ होता है जहाँ जावास्क्रिप्ट V8 इंजन के C ++ इंजन कोड (जो कि Node.js स्वयं पर आधारित है) के साथ फिट बैठता है , और उस प्रदर्शन माप की व्याख्या "नोड-फाइबर्स कॉलबैक की तुलना में तीन से चार गुना धीमी" के रूप में की जानी चाहिए। लेकिन "आपके कोड में अन्य निम्न-स्तरीय कार्यों (बाइट सरणियों के साथ काम करना, डेटाबेस से कनेक्ट करना या इंटरनेट पर किसी सेवा की तुलना में) की तुलना में, नोड-फ़ाइबर का प्रदर्शन पदचिह्न बिल्कुल भी ध्यान देने योग्य नहीं होगा"।

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

इस लेख का मुख्य भाग समाप्त हो गया है, और अंत में हम वैकल्पिक मार्ग पर संक्षेप में विचार करेंगे, और नए डेटा के लिए "इवेंट चक्र" कैसे "घटनाओं के स्रोत" को प्रदर्शित करता है।

वैकल्पिक तरीका है

इस लेख में, हमने बताया कि क्यों "सिंक्रोनस" और "ब्लॉकिंग" I / O का उपयोग करने वाला एप्लिकेशन बड़ी संख्या में एक साथ कनेक्शन का सामना नहीं करता है। समाधान के एक के रूप में, हमने इस एप्लिकेशन को "अतुल्यकालिक घटना मॉडल" में अनुवाद करने का प्रस्ताव दिया (जो कि, Node.js पर, एप्लिकेशन को फिर से लिखना, कहना)। इस तरह, हम वास्तव में (पर्दे के पीछे) "तुल्यकालिक" और "अवरुद्ध" I / O से "तुल्यकालिक" और "गैर-अवरुद्ध" I / O से स्विच करके समस्या का समाधान करेंगे। लेकिन यह एकमात्र समाधान नहीं है: हम "एसिंक्रोनस" I / O का भी सहारा ले सकते हैं।

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

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

प्रत्येक "ऑब्जेक्ट" में "संदेशों" की बारी है (इसके लिए "ग्रीन प्रोसेस" बनाया गया है)। और "ऑब्जेक्ट" के कोड पर कोई भी कॉल उसके लिए एक "संदेश" भेजना है। एक "ऑब्जेक्ट" से दूसरे "ऑब्जेक्ट" में "संदेश" भेजना अतुल्यकालिक रूप से होता है।

इसके अतिरिक्त, वर्चुअल मशीन अपना I / O सबसिस्टम बनाता है, जो नॉन-ब्लॉकिंग सिस्टम I / O में मैप करता है (और फिर से, डेवलपर को कुछ भी संदेह नहीं है)।

और, ज़ाहिर है, आभासी मशीन में अपना आंतरिक अनुसूचक भी होता है।

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

नए डेटा के लिए "ईवेंट चक्र" कैसे "घटनाओं के स्रोत" को प्रदर्शित करता है

सबसे सरल समाधान आप के साथ आ सकते हैं नए डेटा के लिए सभी "डिस्क्रिप्टर" (खुले नेटवर्क सॉकेट, फ़ाइलों को पढ़ने या लिखने, ...) को क्वेरी करने के लिए है। इस तरह के एक एल्गोरिथ्म को "पोल" कहा जाता है । यह कुछ इस तरह दिखता है:

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

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

चूंकि प्रोसेसर से डेटा की डिलीवरी रैम से होती है, और प्रोसेसर से डेटा को रैम में भेजने से फास्ट ऑपरेशंस नहीं होते हैं, ऐसे ऐरे को आगे-पीछे कॉपी करना सिस्टम परफॉर्मेंस को प्रभावित करता है (प्रोसेसर बेकार है जबकि सिस्टम बस का डेटा रैम में चला जाता है और इससे आते ह)।

इसके अलावा, बहुमत ( लगभग 95%)) परिणामी सरणी (लगभग 10,000 खुली सॉकेट के लिए) बेकार हैं, क्योंकि संबंधित सॉकेट में नया डेटा नहीं है।

और जब से इस सरणी का आकार वर्णनकर्ताओं की संख्या के अनुपात में बढ़ता है, तो यह पता चलता है कि यह एल्गोरिथ्म धीमी गति से अधिक जेब खोलने का काम करता है। यही है, आपकी साइट पर जितने अधिक आगंतुक आते हैं, उतना ही "घटना चक्र" धीमा होने लगता है। इस मामले में, वे कहते हैं: "एल्गोरिथ्म में जटिलता ओ (एन) है।"

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

पर विचार करें epoll । यह दोनों तरफ के साधारण मतदान से अलग है ।

कार्यक्रम सभी डिस्क्रिप्टर (और सभी प्रकार की घटनाओं) की बिल्कुल भी जांच नहीं करता है, लेकिन केवल उन डिस्क्रिप्टर (और घटनाओं के प्रकार) की सदस्यता लेता है जिनकी उसे आवश्यकता है।
कर्नेल / / dev / epoll फ़ाइल (वास्तव में यह "डिवाइस" है, लेकिन लिनक्स के दर्शन के दृष्टिकोण से, "सब कुछ एक फ़ाइल है") बनाकर प्रोग्राम के लिए दृश्यमान डेटा के साथ कर्नेल मेमोरी क्षेत्र बनाता है। कार्यक्रम किसी भी नकल के बिना mmap फ़ंक्शन का उपयोग करके इस फ़ाइल को पढ़ सकता है (और इसे लिख सकता है) । नए संदेशों की उपस्थिति ioctl सिस्टम फ़ंक्शन द्वारा जाँच की जाती है।

और यदि विवरणकर्ताओं की सामान्य गणना में O (n) समय लगता है, तो इन अनुकूलित एल्गोरिदम को O (1) समय की आवश्यकता होती है, अर्थात, वे साइट पर एक साथ आने वाले आगंतुकों की संख्या में वृद्धि के साथ धीमे नहीं हो जाते हैं।

जिन उपयोगकर्ताओं ने लेख को संपादित करने में भाग लिया

: लेख अर्थ परिवर्तन उपयोगकर्ताओं द्वारा सुझाए शामिल akzhan , erlyvideo , eyeofhell , MagaSoft , Mox , nuit , Olegich , reddot , splav_asv , tanenn , फेंकने योग्य की ।
साथ ही साथ उपयोगकर्ताओं द्वारा देखे गए वाक्य-विन्यास और शैलीगत परिवर्तन: गोडर , @ सेलेब्रिटी।

एक "अतुल्यकालिक घटना मॉडल" क्या है, और यह अब "फैशन में" क्यों है