Node.js 采用事件驅動和異步 I/O 的方式，實作了一個單線程、高并發的 JavaScript 運作時環境，而單線程就意味着同一時間隻能做一件事，那麼 Node.js 如何通過單線程來實作高并發和異步 I/O？本文将圍繞這個問題來探讨 Node.js 的單線程模型 。
高并發政策
一般來說，高并發的解決方案就是提供多線程模型，伺服器為每個用戶端請求配置設定一個線程，使用同步 I/O，系統通過線程切換來彌補同步 I/O 調用的時間開銷。比如 Apache 就是這種政策，由于 I/O 一般都是耗時操作，是以這種政策很難實作高性能，但非常簡單，可以實作複雜的互動邏輯。
而事實上，大多數網站的伺服器端都不會做太多的計算，它們接收到請求以後，把請求交給其它服務來處理（比如讀取資料庫），然後等着結果傳回，最後再把結果發給用戶端。是以，Node.js 針對這一事實采用了單線程模型來處理，它不會為每個接入請求配置設定一個線程，而是用一個主線程處理所有的請求，然後對 I/O 操作進行異步處理，避開了建立、銷毀線程以及線上程間切換所需的開銷和複雜性。
事件循環
Node.js 在主線程裡維護了一個事件隊列，當接到請求後，就将該請求作為一個事件放入這個隊列中，然後繼續接收其他請求。當主線程空閑時(沒有請求接入時)，就開始循環事件隊列，檢查隊列中是否有要處理的事件，這時要分兩種情況：如果是非 I/O 任務，就親自處理，并通過回調函數傳回到上層調用；如果是 I/O 任務，就從 線程池 中拿出一個線程來處理這個事件，并指定回調函數，然後繼續循環隊列中的其他事件。
當線程中的 I/O 任務完成以後，就執行指定的回調函數，并把這個完成的事件放到事件隊列的尾部，等待事件循環，當主線程再次循環到該事件時，就直接處理并傳回給上層調用。 這個過程就叫 事件循環 (Event Loop)，其運作原理如下圖所示：
這個圖是整個 Node.js 的運作原理，從左到右，從上到下，Node.js 被分為了四層，分别是 應用層、V8引擎層、Node API層 和 LIBUV層。
應用層： 即 JavaScript 互動層，常見的就是 Node.js 的子產品，比如 http，fs
V8引擎層： 即利用 V8 引擎來解析JavaScript 文法，進而和下層 API 互動
NodeAPI層： 為上層子產品提供系統調用，一般是由 C 語言來實作，和作業系統進行互動 。
LIBUV層： 是跨平台的底層封裝，實作了 事件循環、檔案操作等，是 Node.js 實作異步的核心 。
無論是 Linux 平台還是 Windows 平台，Node.js 内部都是通過 線程池 來完成異步 I/O 操作的，而 LIBUV 針對不同平台的差異性實作了統一調用。是以，Node.js 的單線程僅僅是指 JavaScript 運作在單線程中，而并非 Node.js 是單線程。
工作原理
Node.js 實作異步的核心是事件，也就是說，它把每一個任務都當成 事件 來處理，然後通過 Event Loop 模拟了異步的效果，為了更具體、更清晰的了解和接受這個事實，下面我們用僞代碼來描述一下其工作原理 。
【1】定義事件隊列
既然是隊列，那就是一個先進先出 (FIFO) 的資料結構，我們用JS數組來描述，如下：
/**
* 定義事件隊列
* 入隊：push()
* 出隊：shift()
* 空隊列：length == 0
*/
globalEventQueue: [] 我們利用數組來模拟隊列結構：數組的第一個元素是隊列的頭部，數組的最後一個元素是隊列的尾部，push() 就是在隊列尾部插入一個元素，shift() 就是從隊列頭部彈出一個元素。這樣就實作了一個簡單的事件隊列。
【2】定義接收請求入口
每一個請求都會被攔截并進入處理函數，如下所示：
/**
* 接收使用者請求
* 每一個請求都會進入到該函數
* 傳遞參數request和response
*/
processHttpRequest:function(request,response){
// 定義一個事件對象
var event = createEvent({
params:request.params, // 傳遞請求參數
result:null, // 存放請求結果
callback:function(){} // 指定回調函數
});
// 在隊列的尾部添加該事件
globalEventQueue.push(event);
} 這個函數很簡單，就是把使用者的請求包裝成事件，放到隊列裡，然後繼續接收其他請求。
【3】定義 Event Loop
當主線程處于空閑時就開始循環事件隊列，是以我們還要定義一個函數來循環事件隊列：
/**
* 事件循環主體，主線程擇機執行
* 循環周遊事件隊列
* 處理非IO任務
* 處理IO任務
* 執行回調，傳回給上層
*/
eventLoop:function(){
// 如果隊列不為空，就繼續循環
while(this.globalEventQueue.length > 0){
// 從隊列的頭部拿出一個事件
var event = this.globalEventQueue.shift();
// 如果是耗時任務
if(isIOTask(event)){
// 從線程池裡拿出一個線程
var thread = getThreadFromThreadPool();
// 交給線程處理
thread.handleIOTask(event)
}else {
// 非耗時任務處理後，直接傳回結果
var result = handleEvent(event);
// 最終通過回調函數傳回給V8，再由V8傳回給應用程式
event.callback.call(null,result);
}
}
} 主線程不停的檢測事件隊列，對于 I/O 任務，就交給線程池來處理，非 I/O 任務就自己處理并傳回。
【4】處理 I/O 任務
線程池接到任務以後，直接處理IO操作，比如讀取資料庫：
/**
* 處理IO任務
* 完成後将事件添加到隊列尾部
* 釋放線程
*/
handleIOTask:function(event){
//目前線程
var curThread = this;
// 操作資料庫
var optDatabase = function(params,callback){
var result = readDataFromDb(params);
callback.call(null,result)
};
// 執行IO任務
optDatabase(event.params,function(result){
// 傳回結果存入事件對象中
event.result = result;
// IO完成後，将不再是耗時任務
event.isIOTask = false;
// 将該事件重新添加到隊列的尾部
this.globalEventQueue.push(event);
// 釋放目前線程
releaseThread(curThread)
})
} 當 I/O 任務完成以後就執行回調，把請求結果存入事件中，并将該事件重新放入隊列中，等待循環，最後釋放目前線程，當主線程再次循環到該事件時，就直接處理了。
總結以上過程我們發現，Node.js 隻用了一個主線程來接收請求，但它接收請求以後并沒有直接做處理，而是放到了事件隊列中，然後又去接收其他請求了，空閑的時候，再通過 Event Loop 來處理這些事件，進而實作了異步效果，當然對于IO類任務還需要依賴于系統層面的線程池來處理。
是以，我們可以簡單的了解為：Node.js 本身是一個多線程平台，而它對 JavaScript 層面的任務處理是單線程的。
CPU密集型是短闆
至此，對于 Node.js 的單線程模型，我們應該有了一個簡單而又清晰的認識，它通過事件驅動模型實作了高并發和異步 I/O，然而也有 Node.js 不擅長做的事情：
上面提到，如果是 I/O 任務，Node.js 就把任務交給線程池來異步處理，高效簡單，是以 Node.js 适合處理I/O密集型任務。但不是所有的任務都是 I/O 密集型任務，當碰到CPU密集型任務時，即隻用CPU計算的操作，比如要對資料加解密(node.bcrypt.js)，資料壓縮和解壓(node-tar)，這時 Node.js 就會親自處理，一個一個的計算，前面的任務沒有執行完，後面的任務就隻能幹等着 。如下圖所示：
在事件隊列中，如果前面的 CPU 計算任務沒有完成，後面的任務就會被阻塞，出現響應緩慢的情況，如果作業系統本身就是單核，那也就算了，但現在大部分伺服器都是多 CPU 或多核的，而 Node.js 隻有一個 EventLoop，也就是隻占用一個 CPU 核心，當 Node.js 被CPU 密集型任務占用，導緻其他任務被阻塞時，卻還有 CPU 核心處于閑置狀态，造成資源浪費。
是以，Node.js 并不适合 CPU 密集型任務。
适用場景
RESTful API - 請求和響應隻需少量文本，并且不需要大量邏輯處理， 是以可以并發處理數萬條連接配接。
聊天服務 - 輕量級、高流量，沒有複雜的計算邏輯。
原創釋出 @一像素 2017.07
參考文獻：
[1] Node.js軟肋之CPU密集型任務
[2] nodejs筆記之：事件驅動，線程池，非阻塞，異常處理等
[3] Node.js機制及原理了解初步