nodejs與JAVA應(yīng)對(duì)高并發(fā)的對(duì)比

脫離帶寬內(nèi)存與計(jì)算量來討論并發(fā)是沒有意義的

因?yàn)椴l(fā)數(shù)受帶寬及其它很多因素影響，不能單就node.js來說并發(fā)多高。

如果無限帶寬，無限計(jì)算力，無限存……

你可以認(rèn)為node.js并發(fā)數(shù)也是無限的，但這沒有意義，在同樣的情況下，就算是IIS，并發(fā)數(shù)也可以認(rèn)為是無限的。

node.js的優(yōu)勢嚴(yán)格來說不是并發(fā)而是“非阻塞”

它是通過非阻塞來達(dá)到高并發(fā)的目標(biāo)的，我們用node.js也是用它的非阻塞這個(gè)特點(diǎn)。

在優(yōu)化線程池，以及端口復(fù)用等技術(shù)的基礎(chǔ)上，對(duì)于簡單的業(yè)務(wù)處，使用其它的模型也可以達(dá)到高并發(fā)的目標(biāo)，但在面臨業(yè)務(wù)邏輯耗時(shí)長的問題時(shí)，node.js的優(yōu)勢就比較明顯。

如果一個(gè)事務(wù)請求涉及三個(gè)業(yè)務(wù)邏輯，比如登錄(login)這個(gè)事務(wù)，

假設(shè)我們定義它有三個(gè)業(yè)務(wù)邏輯：

• verify：驗(yàn)證用戶是否合法（用戶名，密碼什么的）；
• user：獲取身份信息（權(quán)限什么的）；
• modules：返回他可用的業(yè)務(wù)接口列表(商品管理，用戶管理，訂單審核等）

我們假設(shè)：

只有1完成了才可以進(jìn)行2，2完成了才可以進(jìn)行3，上述每個(gè)業(yè)務(wù)邏輯都需要1秒去完成（客戶的登錄請求這個(gè)事務(wù)需要3秒才能完成）。

同時(shí)，我們也假設(shè)，這三個(gè)業(yè)務(wù)邏輯服務(wù)都是在其它的服務(wù)器上，它們的并發(fā)數(shù)無上限。

然后，我們在“一瞬間”我向這個(gè)服務(wù)發(fā)出1000個(gè)login請求

那么，我們來看看node.js與純java的不同。

nodejs調(diào)用它們來完成,因?yàn)樗欠亲枞?，它調(diào)了verify后，不再等待它返回結(jié)果，就可以處理另一個(gè)事務(wù)請求了，當(dāng)verify請求有返回結(jié)果時(shí)，它再來處理結(jié)果，決定是否調(diào)用user……，整個(gè)過程，只在一個(gè)進(jìn)程中就完成了。

它收到這1000個(gè)請求后，在這個(gè)進(jìn)程中向verify發(fā)出了1000個(gè)請求，過了一秒，收到回應(yīng)又有900個(gè)驗(yàn)證成功，它返回了100個(gè)登錄失敗的信息，并向user發(fā)出了900個(gè)請求，又過了一秒，返回了900個(gè)modules的結(jié)果。

這樣的結(jié)果，在客戶端看來，發(fā)出請求后1秒，收到了100個(gè)登錄失敗，又過了兩秒，收到了900個(gè)可用功能列表（因?yàn)楫惒綑C(jī)制，它還會(huì)稍微長一點(diǎn)點(diǎn)，假設(shè)是3.003秒吧）

現(xiàn)在，在帶寬與計(jì)算力不受限的情況下，同樣的內(nèi)存，看看純Java是怎么個(gè)情況。如果使用純java來做這個(gè)事，java不使用異步模式的話，一個(gè)線程響應(yīng)一個(gè)請求。

java同樣“一瞬間”收到了1000個(gè)請求，java開啟了1000個(gè)線程去響應(yīng)它們,然后這1000個(gè)線程在第一秒里都在等待verify，第一秒結(jié)束時(shí)，返回100個(gè)登錄失敗，關(guān)閉了100個(gè)線程，又過了兩秒，900個(gè)線程得到了各自的modules結(jié)果，并返回給客戶端。

對(duì)于客戶端來說，感覺就是3秒，沒有那個(gè)0.003。

同一套業(yè)務(wù)邏輯，實(shí)現(xiàn)一個(gè)webservice中間接口，中間涉及memcached和mogodb的一些操作。

分別在Node.js和JAVA平臺(tái)實(shí)現(xiàn)，java代碼部署在Tomcat 7.0上，用Apache jmeter進(jìn)行壓力測試。

得到的測試結(jié)果很是出乎意料，Node.js的高并發(fā)優(yōu)勢為什么沒有體現(xiàn)出來呢？？？

**操作系統(tǒng)：**CentOS 6.4（虛擬機(jī)）
**內(nèi)存：**1.5G
**CPU：**單核
并發(fā)數(shù) 100
**ramp-up period(in seconds)**1執(zhí)行次數(shù) 10

以下是測試結(jié)果：Lable #Sample Average Median 90%Line Min Max Error% Throughput KB/secNode.js HTTP請求 1000 333 369 485 1 956 0.0 183.3180568285976 40.995932630614114
Tomcat HTTP請求 1000 48 9 188 2 563 0.0 183.4862385321101 58.414564220183486

可以看到Node.js的平均執(zhí)行時(shí)間為333毫秒，Tomcat的執(zhí)行時(shí)間為48毫秒，Tomcat比Node.js快了近7倍！

• 補(bǔ)充1：即使是測試接口直接返回，不涉及后續(xù)的操作，Tomcat也比Node.js快了很多，求各位大神給個(gè)解釋。
• 補(bǔ)充2：修改jmeter 的 ramp-up period的測試條件，比如這個(gè)值增大（如10秒），node.js的執(zhí)行效率變高了，但這么想來也是違背了高并發(fā)的特性

拋磚引玉，一起探討問題。

如果你也感興趣，不妨拿出點(diǎn)時(shí)間來寫一段程序測試一下，我希望能得到不一樣的結(jié)果。

好，至此，node.js與純java的區(qū)別已經(jīng)很明顯了。純java在不使用非阻塞機(jī)制的情況下，它需要開啟1000個(gè)線程（或者進(jìn)程，這個(gè)成本更高）而node.js則需要更多的時(shí)間。

在內(nèi)存受限的情況下，node.js就有優(yōu)勢了。

假設(shè)一個(gè)進(jìn)程需要1M內(nèi)存，為了能同時(shí)開1000進(jìn)程，你需要額外的1G內(nèi)存來給它。

而對(duì)于node.js，它可能只需要20M來完成這個(gè)事，代價(jià)就是每個(gè)客戶端都需要多等那么一小會(huì)。

嚴(yán)格來說，并不提倡在node.js中實(shí)現(xiàn)業(yè)務(wù)邏輯，node.js最好是只用于 以非阻塞模式連接多個(gè)阻塞模

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。