हम नोड को नेत्रगोलक में लोड करते हैं (मोज़िला पहचान टीम से Node.js पर 12 लेखों में से 2)

एक अनुवादक से: यह मोज़िला आइडेंटिटी टीम से Node.js श्रृंखला का दूसरा लेख है, जो पर्सोना प्रोजेक्ट में शामिल है। यह लेख फिलाडेल्फिया में नोड फिलि 2012 में लॉयड हिलियल के एक भाषण पर आधारित है।

---

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

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

समस्या का बयान

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

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

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

इन आवश्यकताओं के साथ सशस्त्र, हम अलग-अलग तरीकों से सार्थक तुलना कर सकते हैं।

दृष्टिकोण संख्या १। बस मुख्य सूत्र में सब कुछ कर रहा है

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

function myRequestHandler(request, response) { //     -. var results = doComputationWorkSync(request.somesuch); } 

Node.js एप्लिकेशन में सिंक्रोनस कंप्यूटिंग जो एक समय में एक से अधिक अनुरोधों को संसाधित करने की आवश्यकता है, एक बुरा विचार है।

दृष्टिकोण संख्या 2। हम सब कुछ अतुल्यकालिक रूप से करते हैं

पृष्ठभूमि में चलने वाले अतुल्यकालिक कार्य हमारी समस्याओं को हल करेंगे, है ना?

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

 function doComputationWork(input, callback) { //       //      ,   , //      . var output = doComputationWorkSync(input); process.nextTick(function() { callback(null, output); }); } function myRequestHandler(request, response) { //   ,    ** , //      . doComputationWork(request.somesuch, function(err, results) { // ...  -   ... }); } 

नोड में अतुल्यकालिक एपीआई के मात्र उपयोग की गारंटी नहीं है कि आपको एक आवेदन प्राप्त होगा जो कई कोर पर चलता है।

दृष्टिकोण संख्या 3। मल्टीथ्रेडेड लाइब्रेरी के साथ सब कुछ अतुल्यकालिक रूप से करना

एक पुस्तकालय जिसमें मूल कोड का उपयोग करके सही ढंग से लिखा गया है, यह Node.js. पर एक आवेदन से कई थ्रेड का उपयोग करना संभव है। कई ऐसे पुस्तकालय हैं, उदाहरण के लिए, निक कैंपबेल द्वारा लिखित नोड ।bcrypt.js ।

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

समस्या यह है कि यह पुस्तकालय Node.js आंतरिक थ्रेड पूल का उपयोग करता है, जो इस उद्देश्य के लिए बिल्कुल भी नहीं है, और केवल 4 थ्रेड्स तक ही सीमित है ।

और यह एकमात्र समस्या नहीं है:

• कम्प्यूटेशनल कार्यों के साथ नोड थ्रेड्स के सिस्टम पूल को भरना फ़ाइल या नेटवर्क संचालन को धीमा कर सकता है, जिससे जवाबदेही कम हो सकती है।
• कार्य कतार को नियंत्रित करने का कोई तरीका नहीं है। यदि सर्वर पहले से काम से 5 मिनट आगे है, तो क्या आप इसे और भी अधिक लोड करना चाहेंगे?

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

दृष्टिकोण संख्या 4। अंतर्निहित क्लस्टरिंग का उपयोग करना

Node.js संस्करण 0.6.x और उच्चतर में एक अंतर्निहित क्लस्टरिंग मॉड्यूल है जो आपको लोड को संतुलित करने के लिए एक ही सॉकेट पर सुनने वाली कई प्रक्रियाओं को बनाने की अनुमति देता है। यदि आप इस सुविधा को पिछले दृष्टिकोणों में से एक के साथ जोड़ते हैं तो क्या होगा?

इस तरह की वास्तुकला पिछले दृष्टिकोणों की कमियों को विरासत में लेगी, उसी तरह, हम जवाबदेही और दोष सहिष्णुता प्रदान करने में सक्षम नहीं होंगे।

आवेदन के कुछ अतिरिक्त उदाहरणों को चलाना हमेशा सही विकल्प नहीं होता है।

दृष्टिकोण 5। कम्प्यूट-क्लस्टर का परिचय

व्यक्तित्व के लिए, हमने कम्प्यूटेशनल कार्य के लिए विशेष रूप से डिज़ाइन की गई प्रक्रियाओं का एक समूह बनाकर कंप्यूटिंग को समानांतर करने की समस्या को हल किया। परिणाम एक कम्प्यूट-क्लस्टर लाइब्रेरी है।

कम्प्यूट-क्लस्टर स्पॉन्स और प्रक्रियाओं का प्रबंधन करता है, जो आपको बाल प्रक्रियाओं में काम वितरित करने का एक सुविधाजनक साधन प्रदान करता है। इसका उपयोग कैसे करें:

 const computecluster = require('compute-cluster'); //    var cc = new computecluster({ module: './worker.js' }); //    cc.enqueue({ input: "foo" }, function (error, result) { console.log("foo done", result); }); cc.enqueue({ input: "bar" }, function (error, result) { console.log("bar done", result); }); 

worker.js फ़ाइल में इनपुट प्राप्त करने के लिए एक message ईवेंट हैंडलर होना चाहिए।

 process.on('message', function(m) { var output; //     ,    ,    //  ,           var output = doComputationWorkSync(m.input); process.send(output); }); 

कम्प्यूट-क्लस्टर को कॉल कोड को फिर से लिखने के बिना मौजूदा अतुल्यकालिक एपीआई में एकीकृत किया जा सकता है और कार्यक्रम में न्यूनतम बदलाव के साथ वास्तव में तेजी से समानांतर गणना चला सकता है।

यह दृष्टिकोण हमारी चार आवश्यकताओं को कैसे पूरा करता है?

संतृप्ति : कई वर्कफ़्लो सभी उपलब्ध कोर का उपयोग करते हैं।

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

सरलता : यह समाधान मौजूदा परियोजना में एकीकृत करना आसान है। एक सरल एसिंक्रोनस एपीआई के पीछे के विवरणों को छिपाते हुए, गणना-क्लस्टर कार्यान्वयन विवरण से अनभिज्ञ रूप से कॉलिंग प्रक्रिया को छोड़ देता है।

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

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

max_request_time पैरामीटर max_request_time अनुरोध को निष्पादित करने के लिए अधिकतम स्वीकार्य समय निर्धारित करने की अनुमति देता है। अनुरोध को पंक्तिबद्ध करने का प्रयास करने पर त्रुटि हो जाएगी यदि इसे पूरा करने का अपेक्षित समय अधिकतम अनुमत से अधिक हो।

उदाहरण के लिए, प्रपत्र की आवश्यकता "उपयोगकर्ता को 10 सेकंड से अधिक समय तक पूरा करने के लिए प्राधिकरण की प्रतीक्षा नहीं करनी चाहिए" max_request_time 7 सेकंड (हम संभव नेटवर्क देरी के लिए 3 सेकंड का मार्जिन छोड़ देंगे) सेट करके सेट किया जा सकता है।

गणना-क्लस्टर के लोड परीक्षण ने आशाजनक परिणाम दिखाए हैं। यहां तक ​​कि अत्यधिक लोड के तहत, अधिकृत उपयोगकर्ता सिस्टम का उपयोग करना जारी रख सकते हैं, और उनमें से कुछ जिन्होंने ओवरलोड सर्वर में प्रवेश करने की कोशिश की, उन्हें तुरंत एक त्रुटि संदेश मिला।

आगे क्या है?

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

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

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

यदि आपके पास कम्प्यूट-क्लस्टर में सुधार के लिए कोई विचार या सुझाव है, तो मुझे उन्हें सुनकर खुशी होगी। हमारी मेलिंग सूची में व्यक्ति चर्चा में शामिल हों। पढ़ने के लिए धन्यवाद!

---