Python 和 Ruby 也有這樣的框架，但因為在實際使用中會不可避免地用到含有同步代碼的庫，因此沒能成長起來，而在 Node.js 之前，JavaScript 的服務器端編程幾乎是空白，所以 Node.js 才得以建立起了一個所有 IO 均為異步的代碼庫。

大部分 Web 應用的瓶頸都在 IO, 即讀寫磁盤，讀寫網(wǎng)絡，讀寫數(shù)據(jù)庫。使用怎樣的策略等待這段時間，就成了改善性能的關鍵點。

PHP 的策略：多進程運行，直接原地等待 IO 完成。缺點：多個進程會消耗多份內(nèi)存，進程間難以共享數(shù)據(jù)。
C/C++ 通常的策略：多線程運行，程序自己維護鎖的狀態(tài)。缺點：開發(fā)成本高，容易出錯，不易調(diào)試。
Python(Tornado): 多個請求在單個進程中輪流執(zhí)行，遇到 IO 時切換到另一個請求。缺點：對于單個請求而言，依然沒有最高效地利用時間。
何謂「最高效地利用時間」？比如現(xiàn)在有兩個不相關的數(shù)據(jù)庫查詢，在 PHP 中通常會先執(zhí)行一個，執(zhí)行完成后再執(zhí)行第二個(總時間是 a + b). 顯然這不是最高效的，應該同時執(zhí)行兩個查詢，時間是 max(a, b).

Python 和其他支持多線程的語言的問題就在于，在語言層面，程序員很難告訴虛擬機，應當將兩個操作同時執(zhí)行，即使有辦法，也相當麻煩，大多數(shù)人懶得去用(也不值得去用)。而因為 Node.js 喪心病狂地強制所有 IO 異步執(zhí)行，Node.js 的程序員也可以說是輕車熟路，配合一些改善代碼可讀性庫(promise, async), 可以很輕松地讓不相干的操作并行執(zhí)行。

上面講了異步 IO 的實現(xiàn)，那么異步 IO 的優(yōu)勢究竟體現(xiàn)在哪里呢。實際上異步 IO 并不能神奇地減輕服務器的壓力，該加服務器還是一樣要加服務器，只不過異步 IO 會減少單個請求的時間，去掉單個請求中那些無意義的等待時間。所以單位時間內(nèi)處理的請求沒有變化，但每個請求的處理時間卻減少了。從這個角度，服務器也節(jié)約了一些資源——即維持每個請求的連接消耗的內(nèi)存。

最新評論