前言

我們都知道nodejs最大的特點(diǎn)就是單進(jìn)程、無(wú)阻塞運(yùn)行，并且是異步事件驅(qū)動(dòng)的。Nodejs的這些特性能夠很好的解決一些問(wèn)題，例如在服務(wù)器開(kāi)發(fā)中，并發(fā)的請(qǐng)求處理是個(gè)大問(wèn)題，阻塞式的函數(shù)會(huì)導(dǎo)致資源浪費(fèi)和時(shí)間延遲。通過(guò)事件注冊(cè)、異步函數(shù)，開(kāi)發(fā)人員可以提高資源的利用率，性能也會(huì)改善。既然Node.js采用單進(jìn)程、單線程模式，那么在如今多核硬件流行的環(huán)境中，單核性能出色的Nodejs如何利用多核CPU呢？創(chuàng)始人Ryan Dahl建議，運(yùn)行多個(gè)Nodejs進(jìn)程，利用某些通信機(jī)制來(lái)協(xié)調(diào)各項(xiàng)任務(wù)。目前，已經(jīng)有不少第三方的Node.js多進(jìn)程支持模塊發(fā)布，而NodeJS 0.6.x 以上的版本提供了一個(gè)cluster模塊 ,允許創(chuàng)建“共享同一個(gè)socket”的一組進(jìn)程,用來(lái)分擔(dān)負(fù)載壓力。

本篇文章就基于該cluster模塊來(lái)講述Node.js在多核CPU下的編程。

Cluster模塊介紹

nodejs所提供的cluster模塊目前尚處于試驗(yàn)階段，在v0.10.7的官方文檔上我們可以看到模塊的發(fā)布信息如下：

Stability: 1 - Experimental

關(guān)于該模塊的功能，源文檔描述如此“A single instance of Node runs in a single thread. To take advantage of multi-core systems the user will sometimes want to launch a cluster of Node processes to handle the load.” 其意就是：Node的示例以單進(jìn)程的模式運(yùn)行，有時(shí)為了充分利用多核系統(tǒng)的資源用戶(hù)需要運(yùn)行一組Node進(jìn)程來(lái)分擔(dān)負(fù)載。

Cluster用法介紹

首先貼出一段該模塊示例應(yīng)用代碼，接下來(lái)進(jìn)行詳細(xì)分析，代碼如下：

var cluster = require('cluster');
var http = require('http');
var numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
 require('os').cpus().forEach(function(){
 cluster.fork();
 });
 cluster.on('exit', function(worker, code, signal) {
 console.log('worker ' + worker.process.pid + ' died');
 });
 cluster.on('listening', function(worker, address) { 
 console.log("A worker with #"+worker.id+" is now connected to " +
  address.address +
 ":" + address.port); 
 }); 
} else {
 http.createServer(function(req, res) {
 res.writeHead(200);
 res.end("hello world\n");
 console.log('Worker #' + cluster.worker.id + ' make a response');
 }).listen(8000);
}

這段代碼很簡(jiǎn)單，主線程就是當(dāng)前運(yùn)行的js文件，主線程根據(jù)你本機(jī)系統(tǒng)的核數(shù)來(lái)創(chuàng)建子進(jìn)程。所有進(jìn)程共享一個(gè)監(jiān)聽(tīng)端口8000，當(dāng)有請(qǐng)求發(fā)起時(shí)，主線程會(huì)將該請(qǐng)求隨機(jī)分配給某個(gè)子進(jìn)程。console.log('Worker #' + cluster.worker.id + ' make a response');這句代碼可以打印出是哪個(gè)進(jìn)程處理該請(qǐng)求。

問(wèn)題分析

我們前面提到有請(qǐng)求發(fā)起時(shí)，由系統(tǒng)來(lái)決定將該請(qǐng)求交給哪個(gè)進(jìn)程進(jìn)行處理。這種完全依賴(lài)于系統(tǒng)的負(fù)載均衡存在著一個(gè)重要缺陷：在windows，linux和Solaris上，只要某個(gè)子進(jìn)程的accept queue為空（通常為最后創(chuàng)建的那個(gè)子進(jìn)程），系統(tǒng)就會(huì)將多個(gè)connetion分配到同一個(gè)子進(jìn)程上，這會(huì)造成進(jìn)程間負(fù)載極為不均衡。特別是在使用長(zhǎng)連接的時(shí)候，單位時(shí)間內(nèi)的new coming connection并不高，子進(jìn)程的accept queue往往均為空，就會(huì)導(dǎo)致connection會(huì)不停的分配給同一個(gè)進(jìn)程。所以這種負(fù)載均衡完全依賴(lài)于accept queue的空閑程度，只有在使用短連接，而且并發(fā)非常高的情況下，才能達(dá)到負(fù)載均衡，但是這個(gè)時(shí)候系統(tǒng)的load會(huì)非常高，系統(tǒng)也會(huì)變得不穩(wěn)定起來(lái)。

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來(lái)一定的幫助，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)腳本之家的支持。

最新評(píng)論