Node.js 事件循環(huán)機(jī)制
Node.js 采用事件驅(qū)動(dòng)和異步 I/O 的方式,實(shí)現(xiàn)了一個(gè)單線程、高并發(fā)的 JavaScript 運(yùn)行時(shí)環(huán)境,而單線程就意味著同一時(shí)間只能做一件事,那么 Node.js 如何通過單線程來實(shí)現(xiàn)高并發(fā)和異步 I/O?本文將圍繞這個(gè)問題來探討 Node.js 的單線程模型 。
高并發(fā)策略
一般來說,高并發(fā)的解決方案就是提供多線程模型,服務(wù)器為每個(gè)客戶端請(qǐng)求分配一個(gè)線程,使用同步 I/O,系統(tǒng)通過線程切換來彌補(bǔ)同步 I/O 調(diào)用的時(shí)間開銷。比如 Apache 就是這種策略,由于 I/O 一般都是耗時(shí)操作,因此這種策略很難實(shí)現(xiàn)高性能,但非常簡單,可以實(shí)現(xiàn)復(fù)雜的交互邏輯。
而事實(shí)上,大多數(shù)網(wǎng)站的服務(wù)器端都不會(huì)做太多的計(jì)算,它們接收到請(qǐng)求以后,把請(qǐng)求交給其它服務(wù)來處理(比如讀取數(shù)據(jù)庫),然后等著結(jié)果返回,最后再把結(jié)果發(fā)給客戶端。因此,Node.js 針對(duì)這一事實(shí)采用了單線程模型來處理,它不會(huì)為每個(gè)接入請(qǐng)求分配一個(gè)線程,而是用一個(gè)主線程處理所有的請(qǐng)求,然后對(duì) I/O 操作進(jìn)行異步處理,避開了創(chuàng)建、銷毀線程以及在線程間切換所需的開銷和復(fù)雜性。
事件循環(huán)
Node.js 在主線程里維護(hù)了一個(gè)事件隊(duì)列,當(dāng)接到請(qǐng)求后,就將該請(qǐng)求作為一個(gè)事件放入這個(gè)隊(duì)列中,然后繼續(xù)接收其他請(qǐng)求。當(dāng)主線程空閑時(shí)(沒有請(qǐng)求接入時(shí)),就開始循環(huán)事件隊(duì)列,檢查隊(duì)列中是否有要處理的事件,這時(shí)要分兩種情況:如果是非 I/O 任務(wù),就親自處理,并通過回調(diào)函數(shù)返回到上層調(diào)用;如果是 I/O 任務(wù),就從 線程池 中拿出一個(gè)線程來處理這個(gè)事件,并指定回調(diào)函數(shù),然后繼續(xù)循環(huán)隊(duì)列中的其他事件。
當(dāng)線程中的 I/O 任務(wù)完成以后,就執(zhí)行指定的回調(diào)函數(shù),并把這個(gè)完成的事件放到事件隊(duì)列的尾部,等待事件循環(huán),當(dāng)主線程再次循環(huán)到該事件時(shí),就直接處理并返回給上層調(diào)用。 這個(gè)過程就叫 事件循環(huán) (Event Loop),其運(yùn)行原理如下圖所示:

這個(gè)圖是整個(gè) Node.js 的運(yùn)行原理,從左到右,從上到下,Node.js 被分為了四層,分別是 應(yīng)用層、V8引擎層、Node API層 和 LIBUV層。
應(yīng)用層: 即 JavaScript 交互層,常見的就是 Node.js 的模塊,比如 http,fs
V8引擎層: 即利用 V8 引擎來解析JavaScript 語法,進(jìn)而和下層 API 交互
NodeAPI層: 為上層模塊提供系統(tǒng)調(diào)用,一般是由 C 語言來實(shí)現(xiàn),和操作系統(tǒng)進(jìn)行交互 。
LIBUV層: 是跨平臺(tái)的底層封裝,實(shí)現(xiàn)了 事件循環(huán)、文件操作等,是 Node.js 實(shí)現(xiàn)異步的核心 。
無論是 Linux 平臺(tái)還是 Windows 平臺(tái),Node.js 內(nèi)部都是通過 線程池 來完成異步 I/O 操作的,而 LIBUV 針對(duì)不同平臺(tái)的差異性實(shí)現(xiàn)了統(tǒng)一調(diào)用。因此,Node.js 的單線程僅僅是指 JavaScript 運(yùn)行在單線程中,而并非 Node.js 是單線程。
工作原理
Node.js 實(shí)現(xiàn)異步的核心是事件,也就是說,它把每一個(gè)任務(wù)都當(dāng)成 事件 來處理,然后通過 Event Loop 模擬了異步的效果,為了更具體、更清晰的理解和接受這個(gè)事實(shí),下面我們用偽代碼來描述一下其工作原理 。
【1】定義事件隊(duì)列
既然是隊(duì)列,那就是一個(gè)先進(jìn)先出 (FIFO) 的數(shù)據(jù)結(jié)構(gòu),我們用JS數(shù)組來描述,如下:
/** * 定義事件隊(duì)列 * 入隊(duì):push() * 出隊(duì):shift() * 空隊(duì)列:length == 0 */ globalEventQueue: []
我們利用數(shù)組來模擬隊(duì)列結(jié)構(gòu):數(shù)組的第一個(gè)元素是隊(duì)列的頭部,數(shù)組的最后一個(gè)元素是隊(duì)列的尾部,push() 就是在隊(duì)列尾部插入一個(gè)元素,shift() 就是從隊(duì)列頭部彈出一個(gè)元素。這樣就實(shí)現(xiàn)了一個(gè)簡單的事件隊(duì)列。
【2】定義接收請(qǐng)求入口
每一個(gè)請(qǐng)求都會(huì)被攔截并進(jìn)入處理函數(shù),如下所示:
/**
* 接收用戶請(qǐng)求
* 每一個(gè)請(qǐng)求都會(huì)進(jìn)入到該函數(shù)
* 傳遞參數(shù)request和response
*/
processHttpRequest:function(request,response){
// 定義一個(gè)事件對(duì)象
var event = createEvent({
params:request.params, // 傳遞請(qǐng)求參數(shù)
result:null, // 存放請(qǐng)求結(jié)果
callback:function(){} // 指定回調(diào)函數(shù)
});
// 在隊(duì)列的尾部添加該事件
globalEventQueue.push(event);
}
這個(gè)函數(shù)很簡單,就是把用戶的請(qǐng)求包裝成事件,放到隊(duì)列里,然后繼續(xù)接收其他請(qǐng)求。
【3】定義 Event Loop
當(dāng)主線程處于空閑時(shí)就開始循環(huán)事件隊(duì)列,所以我們還要定義一個(gè)函數(shù)來循環(huán)事件隊(duì)列:
/**
* 事件循環(huán)主體,主線程擇機(jī)執(zhí)行
* 循環(huán)遍歷事件隊(duì)列
* 處理非IO任務(wù)
* 處理IO任務(wù)
* 執(zhí)行回調(diào),返回給上層
*/
eventLoop:function(){
// 如果隊(duì)列不為空,就繼續(xù)循環(huán)
while(this.globalEventQueue.length > 0){
// 從隊(duì)列的頭部拿出一個(gè)事件
var event = this.globalEventQueue.shift();
// 如果是耗時(shí)任務(wù)
if(isIOTask(event)){
// 從線程池里拿出一個(gè)線程
var thread = getThreadFromThreadPool();
// 交給線程處理
thread.handleIOTask(event)
}else {
// 非耗時(shí)任務(wù)處理后,直接返回結(jié)果
var result = handleEvent(event);
// 最終通過回調(diào)函數(shù)返回給V8,再由V8返回給應(yīng)用程序
event.callback.call(null,result);
}
}
}
主線程不停的檢測事件隊(duì)列,對(duì)于 I/O 任務(wù),就交給線程池來處理,非 I/O 任務(wù)就自己處理并返回。
【4】處理 I/O 任務(wù)
線程池接到任務(wù)以后,直接處理IO操作,比如讀取數(shù)據(jù)庫:
/**
* 處理IO任務(wù)
* 完成后將事件添加到隊(duì)列尾部
* 釋放線程
*/
handleIOTask:function(event){
//當(dāng)前線程
var curThread = this;
// 操作數(shù)據(jù)庫
var optDatabase = function(params,callback){
var result = readDataFromDb(params);
callback.call(null,result)
};
// 執(zhí)行IO任務(wù)
optDatabase(event.params,function(result){
// 返回結(jié)果存入事件對(duì)象中
event.result = result;
// IO完成后,將不再是耗時(shí)任務(wù)
event.isIOTask = false;
// 將該事件重新添加到隊(duì)列的尾部
this.globalEventQueue.push(event);
// 釋放當(dāng)前線程
releaseThread(curThread)
})
}
當(dāng) I/O 任務(wù)完成以后就執(zhí)行回調(diào),把請(qǐng)求結(jié)果存入事件中,并將該事件重新放入隊(duì)列中,等待循環(huán),最后釋放當(dāng)前線程,當(dāng)主線程再次循環(huán)到該事件時(shí),就直接處理了。
總結(jié)以上過程我們發(fā)現(xiàn),Node.js 只用了一個(gè)主線程來接收請(qǐng)求,但它接收請(qǐng)求以后并沒有直接做處理,而是放到了事件隊(duì)列中,然后又去接收其他請(qǐng)求了,空閑的時(shí)候,再通過 Event Loop 來處理這些事件,從而實(shí)現(xiàn)了異步效果,當(dāng)然對(duì)于IO類任務(wù)還需要依賴于系統(tǒng)層面的線程池來處理。
因此,我們可以簡單的理解為:Node.js 本身是一個(gè)多線程平臺(tái),而它對(duì) JavaScript 層面的任務(wù)處理是單線程的。
CPU密集型是短板
至此,對(duì)于 Node.js 的單線程模型,我們應(yīng)該有了一個(gè)簡單而又清晰的認(rèn)識(shí),它通過事件驅(qū)動(dòng)模型實(shí)現(xiàn)了高并發(fā)和異步 I/O,然而也有 Node.js 不擅長做的事情:
上面提到,如果是 I/O 任務(wù),Node.js 就把任務(wù)交給線程池來異步處理,高效簡單,因此 Node.js 適合處理I/O密集型任務(wù)。但不是所有的任務(wù)都是 I/O 密集型任務(wù),當(dāng)碰到CPU密集型任務(wù)時(shí),即只用CPU計(jì)算的操作,比如要對(duì)數(shù)據(jù)加解密(node.bcrypt.js),數(shù)據(jù)壓縮和解壓(node-tar),這時(shí) Node.js 就會(huì)親自處理,一個(gè)一個(gè)的計(jì)算,前面的任務(wù)沒有執(zhí)行完,后面的任務(wù)就只能干等著 。如下圖所示:

在事件隊(duì)列中,如果前面的 CPU 計(jì)算任務(wù)沒有完成,后面的任務(wù)就會(huì)被阻塞,出現(xiàn)響應(yīng)緩慢的情況,如果操作系統(tǒng)本身就是單核,那也就算了,但現(xiàn)在大部分服務(wù)器都是多 CPU 或多核的,而 Node.js 只有一個(gè) EventLoop,也就是只占用一個(gè) CPU 內(nèi)核,當(dāng) Node.js 被CPU 密集型任務(wù)占用,導(dǎo)致其他任務(wù)被阻塞時(shí),卻還有 CPU 內(nèi)核處于閑置狀態(tài),造成資源浪費(fèi)。
因此,Node.js 并不適合 CPU 密集型任務(wù)。
適用場景
RESTful API - 請(qǐng)求和響應(yīng)只需少量文本,并且不需要大量邏輯處理, 因此可以并發(fā)處理數(shù)萬條連接。
聊天服務(wù) - 輕量級(jí)、高流量,沒有復(fù)雜的計(jì)算邏輯。
原創(chuàng)發(fā)布 @一像素 2017.07
參考文獻(xiàn):


浙公網(wǎng)安備 33010602011771號(hào)