概述nodejs核心機制

nodejs

• Non-Blocking I/O Model
• Event Loop
• Event-Driven
  • 基本架構
  • 何爲阻塞
  • 代碼執行時
  • 阻止事件循環的幾個維度
  • Worker Pool
  • npm模塊的風險

Non-Blocking I/O Model

non-blocking是指node.js進程中不一樣步等待執行非javascript操做（例如I/O）完成而繼續執行下一塊代碼的特性。

注：CPU密集型屬於javascript操做。

I/O一般指與磁盤與網絡的交互

非阻塞I/O模型使得nodejs支持高併發且很是適合於I/O密集型應用

Nodejs Event Loop and Worker Pool

共6個階段

• timers setTimeout與setInterval回調函數隊列
• pending callbacks 會在下一次loop中執行的系統級回調隊列。如TCP ECONNREFUSED -idle,prepare 內部使用
• poll 接收新的I/O事件。執行I/O相關回調。在這個階段node進程可能會阻塞
• check setImmediate回調會在這個階段執行
• close 一些關閉的回調。好比connect.on('close', () => {....})

注：process.nextTick不屬於任何一個階段，它是介於任意兩個階段之間，而且在階段切換時執行nextTick回調

Event-Driven

基本架構

• nodejs事件驅動架構中有兩種線程：事件循環線程（Event Loop）以及工做線程池（worker pool）
• Event Loop負責編排客戶端請求然後調度Worker Pool處理CPU密集型任務

注：所以nodejs並非純粹的單線程語言！

何爲阻塞

• 若是Event Loop執行回調或worker執行任務須要很長時間，即爲阻塞。當發生阻塞時，主要會有兩點須要考慮：
  • 性能：若是某worker線程按期執行heavyweight任務，會影響服務吞吐量（請求/秒）
  • 安全性：假設某些輸入會引發程序阻塞，則存在被惡意客戶端利用並攻擊的風險。即拒絕服務攻擊。

代碼執行時

• 在Event Loop中同步執行常規的變量、方法的定義與調用，javascript全部回調以及非阻塞異步I/O如網絡I/O
• Worker Pool是libuv（線程池工做調度的c++庫）在Worker Pool中異步執行「昂貴」繁重的任務。node提供非阻塞I/O（操做系統不提供）API，以及CPU密集的I/O API
  • I/O密集型API：
    • DNS: dns.lookup()
    • fs: fs.readFile()，除了那些顯示說明同步的方法
  • CPU密集型API：
    • crypto: crypto.pbkdf2()
    • zlib: 除了那些顯示說明同步的方法

Event Loop實質

抽象來講，Event Loop維護掛起事件的隊列，Worker Pool維護掛起任務的隊列。

實際上，Event Loop並非維護一個隊列。而是一個文件描述符的集合，這些文件描述符從系統級事件通知機制獲取好比epoll(linux),kqueue(OSX),IOCP(Windows)。這些文件描述符對應於某些網絡套接字以及node正在監視的文件等等。當某個描述符準備好時，Event Loop會將其轉換爲合適的事件並執行對應的回調。

另外，Worker Pool維護的是一個真正的隊列。Worker會pop出隊列的task並執行，完成後會觸發Event Loop「至少一個事件已完成」的事件。

阻止事件循環的幾個維度

1. 數據處理流程中是否包含計算複雜度高的任務，好比使用CPU密集型Node API好比crypto,fs,zlib,child-process（分區處理與offload to Worker Pool）
2. ReDoS攻擊，檢查是否存在易受攻擊的正則表達式（使用安全正則表達式庫作安全校驗）
3. 是否在主線程中使用JSON.parse以及JSON.stringify（潛在風險，所以也建議offload給Worker Pool）

Worker Pool

nodejs默認的Worker Pool專門用於處理I/O任務，維護本身的線程池可使用cluster模塊以及child_process模塊作自定義線程池。

Node服務器的吞吐量取決於WorkerPool的吞吐量。有效下降逐個任務時間開銷以及穩定任務時間開銷的變化將最大程度提高服務器的吞吐量。最多見的方法就是複雜重複型任務（好比數組迭代）作分區處理。

注：因爲調度Worker Pool會增長額外的通訊開銷，由於Worker Pool沒法獲取主線程的命名空間從而沒法直接讀取Javascript對象，因此須要序列化/反序列化致使增長通訊成本。

npm模塊的風險

npm生態系統中存在數十萬個模塊爲開發者提供了極大的便利，然而社區中npm包參差不齊，由於沒法較爲準確的估計其使用Event Loop或者Worker Pool的成本而致使一些程序隱患。