Node.js采用 事件驅(qū)動 和 異步I/O 的方式，實現(xiàn)了一個單線程、高并發(fā)的運(yùn)行時環(huán)境，而單線程就意味著同一時間只能做一件事，那么Node.js如何利用單線程來實現(xiàn)高并發(fā)和異步I/O？本文將圍繞這個問題來探討Node.js的單線程模型：

1、高并發(fā)

一般來說，高并發(fā)的解決方案就是多線程模型，服務(wù)器為每個客戶端請求分配一個線程，使用同步I/O，系統(tǒng)通過線程切換來彌補(bǔ)同步I/O調(diào)用的時間開銷，比如Apache就是這種策略，由于I/O一般都是耗時操作，因此這種策略很難實現(xiàn)高性能，但非常簡單，可以實現(xiàn)復(fù)雜的交互邏輯。

而事實上，大多數(shù)網(wǎng)站的服務(wù)器端都不會做太多的計算，它們只是接收請求，交給其它服務(wù)（比如從數(shù)據(jù)庫讀取數(shù)據(jù)），然后等著結(jié)果返回再發(fā)給客戶端。因此，Node.js針對這一事實采用了單線程模型來處理，它不會為每個接入請求分配一個線程，而是用一個主線程處理所有的請求，然后對I/O操作進(jìn)行異步處理，避開了創(chuàng)建、銷毀線程以及在線程間切換所需的開銷和復(fù)雜性。

2、事件循環(huán)

Node.js 在主線程中維護(hù)了一個事件隊列，當(dāng)接收到請求后，就將請求作為一個事件放入該隊列中，然后繼續(xù)接收其他請求。當(dāng)主線程空閑時(沒有請求接入時)，就開始循環(huán)事件隊列，檢查隊列中是否有要處理的事件，這時要分兩種情況：如果是非I/O任務(wù)，就親自處理，并通過回調(diào)函數(shù)返回到上層調(diào)用；如果是I/O任務(wù)，就從線程池中拿出一個線程來執(zhí)行這個事件，并指定回調(diào)函數(shù)，然后繼續(xù)循環(huán)隊列中的其他事件。當(dāng)線程中的I/O任務(wù)完成后，就執(zhí)行指定的回調(diào)函數(shù)，并把這個完成的事件放到事件隊列的尾部，等待事件循環(huán)，當(dāng)主線程再次循環(huán)到該事件時，就直接處理并返回給上層調(diào)用。 這個過程就叫事件循環(huán)(Event Loop)，如下圖所示：

這個圖是整個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語言來實現(xiàn)，和操作系統(tǒng)進(jìn)行交互
LIBUV層： 即Event Loop，是Node.js實現(xiàn)異步的核心，由LIBUV庫來實現(xiàn)，而LIBUV中的線程池是由操作系統(tǒng)內(nèi)核接受管理的。

從上述理解來看，Node.js的單線程僅僅是指Javascript運(yùn)行在單線程中，而并非Node.js是單線程，在Node中，無論是Linux平臺還是Windows平臺，內(nèi)部都是通過線程池來完成IO操作，而LIBUV就是針對不同平臺的差異性實現(xiàn)了統(tǒng)一調(diào)用。

3、事件驅(qū)動

總結(jié)上面的過程可以發(fā)現(xiàn)，Node.js的核心是使用事件驅(qū)動模式實現(xiàn)了異步I/O，為了更具體、更清晰的理解和接受這個事實，我們用代碼來描述Node.js的事件驅(qū)動模型：

3.1、事件隊列

首先，我們需要定義一個事件隊列，既然是隊列，那就是一個先進(jìn)先出(FIFO)的數(shù)據(jù)結(jié)構(gòu)，我們用JS的數(shù)組來描述，如下：

/**
 * 定義事件隊列
 * 入隊：unshfit()
 * 出隊：pop()
 * 空隊列：length == 0
 */
eventQueue:[],

為了方便理解，我們規(guī)定：數(shù)組的第一個元素是隊列的尾部，數(shù)組的最后一個元素是隊列的頭部， unshfit 就是在尾部插入一個元素，pop就是從頭部彈出一個元素，這樣就實現(xiàn)了一個簡單的隊列。

3.2、接收請求

定義一個總的入口來接收用戶請求，如下所示：

/**
 * 接收用戶請求
 * 每一個請求都會進(jìn)入到該函數(shù)
 * 傳遞參數(shù)request和response
 */
processHttpRequest:function(request,response){
   
  //定義一個事件對象
  var event = createEvent({
    params:request.params, //傳遞請求參數(shù)
    result:null, //存放請求結(jié)果
    callback:function(){} //指定回調(diào)函數(shù)
  });
 
  //在隊列的尾部添加該事件 
  eventQueue.unshift(event);
},

這個函數(shù)很簡單，就是把用戶的請求包裝成事件，放到隊列里，然后繼續(xù)接收其他請求。

3.3、事件循環(huán)

當(dāng)主線程處于空閑時就開始循環(huán)事件隊列，所以，我們再定義一個事件循環(huán)的函數(shù)：

/**
 * 事件循環(huán)主體，主線程擇機(jī)執(zhí)行
 * 循環(huán)遍歷事件隊列
 * 處理事件
 * 執(zhí)行回調(diào)，返回給上層
 */
eventLoop:function(){
  //如果隊列不為空，就繼續(xù)循環(huán)
  while(this.eventQueue.length > 0){
    //從隊列的頭部拿出一個事件
    var event = this.eventQueue.pop();
    //如果是IO任務(wù)
    if(isIOTask(event)){
      //從線程池里拿出一個線程
      var thread = getThreadFromThreadPool();
      //交給線程處理
      thread.handleIOTask(event)
    }else {
      //非IO任務(wù)處理后，直接返回結(jié)果
      var result = handleEvent(event);
      //最終通過回調(diào)函數(shù)返回給V8，再由V8返回給應(yīng)用程序
      event.callback.call(null,result);
    }
  }
},

主線程不停的檢測事件隊列，對于IO任務(wù)就交給線程池來處理，非IO任務(wù)就自己處理并返回。

3.4、線程池

線程池接到任務(wù)以后，直接處理IO操作，比如讀取數(shù)據(jù)庫：

當(dāng)IO

/**
 * 處理IO任務(wù)
 * 完成后將事件添加到隊列尾部
 * 釋放線程
 */
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é)果存入事件對象中
    event.result = result;
 
    //IO完成后，將不再是耗時任務(wù)
    event.isIOTask = false;
     
    //將該事件重新添加到隊列的尾部
    this.eventQueue.unshift(event);
     
    //釋放當(dāng)前線程
    releaseThread(curThread)
  })
}

任務(wù)完成以后就執(zhí)行回調(diào)，把請求結(jié)果存入事件中，并將該事件重新放入隊列中，等待循環(huán)，最后釋放線程。當(dāng)主線程再次循環(huán)到該事件時，就直接處理了。

 4、Node.js軟肋

以上四步簡單描述了Node.js事件驅(qū)動模型，至此，我們對Node.js應(yīng)該有了一個簡單而又清晰的認(rèn)識，但Node.js 并不是什么都能做。

上面提到，如果是I/O任務(wù)，Nodejs就把任務(wù)交給線程池來異步處理，高效簡單，因此Node.js適合處理I/O密集型任務(wù)，但不是所有的任務(wù)都是I/O密集型任務(wù)，當(dāng)碰到CPU密集型任務(wù)時，就是只用CPU計算的操作，比如要對數(shù)據(jù)加解密(node.bcrypt.js)，數(shù)據(jù)壓縮和解壓(node-tar)，這時Node.js就會親自處理，一個一個的計算，前面的任務(wù)沒有執(zhí)行完，后面的任務(wù)只能干等著，如下圖所示：

在事件隊列中，如果前面的CPU計算任務(wù)沒有完成，那么后面的任務(wù)就會被阻塞，出現(xiàn)響應(yīng)緩慢的情況，如果操作系統(tǒng)本身就是單核，那也就算了，但現(xiàn)在大部分服務(wù)器都是多CPU或多核的，而Node.js只有一個EventLoop，也只占用一個CPU/內(nèi)核，當(dāng)Node.js被CPU密集型任務(wù)占用，導(dǎo)致其他任務(wù)被阻塞時，卻還有CPU/內(nèi)核處理閑置狀態(tài)，造成資源浪費(fèi)。因此Node.js不適合CPU密集型任務(wù)。

5、Node.js適用場景

5.1、RESTful API

這是適合 Node 的理想情況，因為您可以構(gòu)建它來處理數(shù)萬條連接。它仍然不需要大量邏輯；它本質(zhì)上只是從某個數(shù)據(jù)庫中查找一些值并將它們組成一個響應(yīng)。由于響應(yīng)是少量文本，入站請求也是少量的文本，因此流量不高，一臺機(jī)器甚至也可以處理最繁忙的公司的 API 需求。

5.2、實時程序

比如聊天服務(wù)，聊天應(yīng)用程序是最能體現(xiàn) Node.js 優(yōu)點的例子：輕量級、高流量并且能良好的應(yīng)對跨平臺設(shè)備上運(yùn)行密集型數(shù)據(jù)（雖然計算能力低）。同時，聊天也是一個非常值得學(xué)習(xí)的用例，因為它很簡單，并且涵蓋了目前為止一個典型的 Node.js 會用到的大部分解決方案。

以上所述是小編給大家介紹的Node.js單線程模型，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！

最新評論