Node.js機制及原理理解初步

http://blog.csdn.net/leftfist/article/details/41891407

 

1、node.js優缺點

node.js是單線程。

好處就是

1）簡單

2）高性能，避免了頻繁的線程切換開銷

3）佔用資源小，由於是單線程，在大負荷狀況下，對內存佔用仍然很低

3）線程安全，沒有加鎖、解鎖、死鎖這些問題

php

node.js

壞處就是

如何解決高併發？

node使用異步IO和事件驅動（回調函數）來解決這個問題。

通常來講，高併發解決方案會提供多線程模型，爲每一個業務邏輯提供一個線程，經過系統線程切換來來彌補同步I/O調用的時間開銷。像apache，是一個請求一個線程。

而node.js使用的是單線程模型，對全部I/O都採用異步的請求方式，避免頻繁的上下文切換，在node.js執行的時候維護着一個事件隊列；程序在執行時進入事件循環等待下一個事件到來，每一個異步I/O請求完成後都會被推送到事件隊列中的等待執行。

好比說：

對於一個簡單的數據庫訪問操做，傳統方式是這樣實現的

res = db.query('SELECT * from some_table');
res.output();

代碼執行到第一行的時候線程會阻塞，等待query返回結果，而後繼續處理。因爲數據庫查詢、磁盤讀寫、網絡通訊等緣由（所謂的I/O）阻塞時間會很是大（相對於CPU始終頻率）。對於高併發的訪問，一方面線程長期阻塞等待，另外一方面爲了應付新情求而不斷添加新線程，會浪費大量系統資源，同時線程的增長也會也會佔用大量的CPU時間來處理內存上下文切換。看看node.js怎麼處理

 

 

db.query('SELECT * from some_table', function(res) {
   res.output();
});

query的第二個參數是一個回調函數，進程執行到db.query的時候不會等待結果返回，而是直接繼續執行下面的語句，直到進入事件循環。當數據庫執行結果返回的時候會將事件發送到事件隊列，等到線程進入事件循環後纔會調用以前的回調函數。

node.js的異步機制是基於事件的，全部的I/O、網絡通訊、數據庫查詢都以非阻塞的方式執行，返回結果由事件循環來處理。node.js在同一時刻只會處理一個事件，完成後當即進入事件循環檢查後面事件。這樣CPU和內存在同一時間集中處理一件事，同時儘可能讓耗時的I/O等操做並行執行。

 

事件循環機制

所謂事件循環是指node.js會把全部的異步操做使用事件機制解決，有個線程在不斷地循環檢測事件隊列。

node.js中全部的邏輯都是事件的回調函數，因此node.js始終在事件循環中，程序入口就是事件循環第一個事件的回調函數。事件的回調函數中可能會發出I/O請求或直接發射（ emit）事件，執行完畢後返回事件循環。事件循環會檢查事件隊列中有沒有未處理的事件，直到程序結束。node.js的事件循環對開發者不可見，由libev庫實現，libev不斷檢查是否有活動的、可供檢測的事件監聽器，直到檢查不到時才退出事件循環，程序結束。

如圖所示

 libuv 是一個高性能事件驅動的程序庫，封裝了 Windows 和 Unix 平臺一些底層特性，爲開發者提供了統一的 API.
所以，node.js 是單線程，異步非阻塞。

但畢竟，如何彌補單線程缺陷？是否是有異步非阻塞，就能夠高枕無憂了？

不是的。

 

1）CPU密集型任務存在短板

如上所述，nodejs的機制是單線程，這個線程裏面，有一個事件循環機制，處理全部的請求。如圖所示。在事件處理過程當中，它會智能地將一些涉及到IO、網絡通訊等耗時比較長的操做，交由worker threads去執行，執行完了再回調，這就是所謂的異步IO非阻塞吧。可是，那些非IO操做，只用CPU計算的操做，它就本身扛了，好比算什麼斐波那契數列之類。它是單線程，這些本身扛的任務要一個接着一個地完成，前面那個沒完成，後面的只能乾等。所以，對CPU要求比較高的CPU密集型任務多的話，就有可能會形成號稱高性能，適合高併發的node.js服務器反應緩慢。

2）沒法利用CPU的多核

最開始，線程只是用於分配單個處理器處理時間的一種機制。但假如操做系統自己支持多個CPU/內核，那麼每一個線程均可以獲得一個不一樣本身的CPU/內核，實現真正的「並行運算」。在這種狀況下，多線程程序能夠提升資源使用效率。Node.js是單線程程序，它只有一個event loop，也只佔用一個CPU/內核。如今大部分服務器都是多CPU或多核的，當Node.js程序的event loop被CPU密集型的任務佔用，致使有其它任務被阻塞時，卻還有CPU/內核處於閒置的狀態，形成資源的浪費。

 

解決方案

利用原生模塊或第三方模塊，開闢進程或子進程，用於處理這些特殊的任務。

3）若是有異常拋出，由於是單線程，整個項目將不可用。但這歸根究竟是代碼的問題，糟糕的代碼，無論什麼體系，都會有問題，即便不崩潰。解決辦法是用pm2等工具來運行？

 

2、nodejs與JavaScript的關係

 

nodejs自己不是開發語言，它是一個工具或者平臺，在服務器端解釋、運行javascript；coffeescript屬於nodejs體系，算是一種新的開發語言，但它的目的在於最後編譯成javascript。

nodejs利用Google V8來解釋運行javascript，可是系統真正執行的代碼是用C++寫的。javascript作的只是調用這些API而已。所以，並沒有執行效率的問題。

 

3、nodejs適用場景

 

 

一、RESTful API

這是適合 Node 的理想狀況，由於您能夠構建它來處理數萬條鏈接。它仍然不須要大量邏輯；它本質上只是從某個數據庫中查找一些值並將它們組成一個響應。因爲響應是少許文本，入站請求也是少許的文本，所以流量不高，一臺機器甚至也能夠處理最繁忙的公司的 API 需求。

二、實時程序

好比聊天服務

聊天應用程序是最能體現 Node.js 優勢的例子：輕量級、高流量而且能良好的應對跨平臺設備上運行密集型數據（雖然計算能力低）。同時，聊天也是一個很是值得學習的用例，由於它很簡單，而且涵蓋了目前爲止一個典型的 Node.js 會用到的大部分解決方案。

三、單頁APP

ajax不少。如今單頁的機制彷佛很流行，好比phonegap作出來的APP，一個頁面包打天下的例子比比皆是。

 

。。。

 

總而言之，NodeJS適合運用在高併發、I/O密集、少許業務邏輯的場景

參考文章

 

關於node.js的誤會

Node.js的線程和進程

http://www.slideshare.net/mysqlops/nodejs-9313477

Node.js軟肋之CPU密集型任務

http://www.ruanyifeng.com/blog/2014/10/event-loop.html

http://segmentfault.com/a/1190000000375619

http://www.cnblogs.com/sysuys/p/3460614.html