Node.js系列——（4）優點及場景

背景

以前幾篇系列文章簡單介紹了node.js的安裝配置及基本操做：

Node.js系列——（1）安裝配置與基本使用
Node.js系列——（2）發起get/post請求
Node.js系列——（3）鏈接DB

接下來，咱們就來總體認識下node.js

node.js

node.js官網對它的介紹是這樣的：

Node.js 是一個基於 Chrome V8 引擎的 JavaScript 運行環境。
Node.js 使用了一個事件驅動、非阻塞式 I/O 的模型，使其輕量又高效。

V8引擎

V8使用C++開發，並在谷歌瀏覽器中使用。在運行JavaScript以前，相比其它的JavaScript的引擎轉換成字節碼或解釋執行，V8將其編譯成原生機器碼（IA-32, x86-64, ARM, or MIPS CPUs），而且使用瞭如內聯緩存（inline caching）等方法來提升性能。

有了這些功能，JavaScript程序在V8引擎下的運行速度媲美二進制程序。

具體內容可參考：爲何V8引擎這麼快？

事件驅動

傳統技術實現下，當一個請求到達時，會分配一個線程，該線程會佔用內存，當請求的任務作完時，線程纔會退出並釋放內存。但node.js只有一個單線程，全部的鏈接都由這一個線程來處理。

網上流傳着一個生動的例子：

傳統技術下的處理方式——>餐館裏一個服務員接待一桌客人，服務這一桌客人點餐、上菜、陪侍，到客人離開；
node.js的處理方式——>餐館裏只有一個服務員，當有客人來，他就去招待點餐，點餐結束後就去處理其餘事情，能夠去招待其餘客人，也能夠去上菜。

Node.js是單進程單線程的，那他是如何作到高性能的呢？
主要經過事件驅動和異步回調。node中幾乎全部的事件機制都是使用觀察者模式實現的。

說到觀察者模式，就要先明確主題Subject（即被觀察者）和觀察者Observer。

以下圖所示，在node中事件扮演者Subject的角色，而這個事件上的處理函數就是觀察者。還拿上面的餐館服務員的例子來講，客人進入餐館這一動做就是一個事件，當這一事件觸發時，他的觀察者就會進行一系列操做（好比招待入座、點餐等）。

因爲node是單線程的，所以在實際場景中會有不少事件堆積到一塊兒，這也就是事件隊列。

在上圖中所示：
1） 若是有任務或請求到達，會被放入右側的Event Queue（事件隊列）中。事件隊列中每一個任務會存放兩個東西，處理方法和回調方法，即function和callback。

2）事件循環Event Loop會根據事件隊列中的任務列表進行執行，這時分兩種狀況：

• 若是取到的任務是non-Blocking非阻塞的，那麼能夠直接執行而後調用他相對應的回調函數。
• 若是任務是Blocking阻塞的（如IO操做等），就不會直接執行，而是從線程池Thread Pool中取出一個線程來執行，當該線程完成後，就會調用回調函數，接下來的操做跟上一種狀況同樣了。到最後該線程的任務執行完畢，那麼線程所佔用的資源被釋放。

Tips:
當執行過程當中遇到I/O阻塞(讀取文件、查詢數據庫、請求套接字、訪問遠程服務等)時，事件循環線程不會停下等待結果,轉而繼續執行隊列中的下一個任務,不會在事件循環線程中執行。在函數執行時,Node.js在事件隊列中放置回調函數,它的順序根據函數的完成快慢決定。

具體內容參考：Node.js的事件驅動模型

Rest API

Rest API 這部分就不用多說了，node採用這種方式來規範接口和數據的形式，用法也很簡單。

場景

前面說了這麼多node.js的優勢，那是否是任何場景都優先選擇他呢？確定不是的，咱們來看下他的缺點。

一、node.js不適合作CPU密集型的工做
咱們不能說node.js徹底是單線程的，由於當遇到阻塞式的任務時，他會交給其餘線程去處理。但除此以外，node是單線程的。所以，若是是CPU密集的場景下，選擇使用node，沒法使他的優點發揮出來。

二、大量的計算可能會使node單線程暫時失去反應

三、若是有一個Exception影響到了node的核心事件循環，那麼整個實例就會崩潰。