參考《Node.js開(kāi)發(fā)指南 ByVoid》
一敲长、異步式 I/O 與事件驅(qū)動(dòng)
1.Page4:
Node.js 最大的特點(diǎn)就是采用異步式 I/O 與事件驅(qū)動(dòng)的架構(gòu)設(shè)計(jì)贪壳。對(duì)于高并發(fā)的解決方案挪圾，傳統(tǒng)的架構(gòu)是多線程模型宾尚，也就是為每個(gè)業(yè)務(wù)邏輯提供一個(gè)系統(tǒng)線程盲泛，通過(guò)系統(tǒng)線程切換來(lái)彌補(bǔ)同步式 I/O 調(diào)用時(shí)的時(shí)間開(kāi)銷疗隶。Node.js 使用的是單線程模型霞扬，對(duì)于所有 I/O 都采用異步式的請(qǐng)求方式糕韧，避免了頻繁的上下文切換枫振。Node.js 在執(zhí)行的過(guò)程中會(huì)維護(hù)一個(gè)事件隊(duì)列，程序在執(zhí)行時(shí)進(jìn)入事件循環(huán)等待下一個(gè)事件到來(lái)萤彩，每個(gè)異步式 I/O 請(qǐng)求完成后會(huì)被推送到事件隊(duì)列粪滤，等待程序進(jìn)程進(jìn)行處理。例如雀扶，對(duì)于簡(jiǎn)單而常見(jiàn)的數(shù)據(jù)庫(kù)查詢操作杖小，按照傳統(tǒng)方式實(shí)現(xiàn)的代碼如下：
res = db.query('SELECT * from some_table');
res.output();
以上代碼在執(zhí)行到第一行的時(shí)候，線程會(huì)阻塞愚墓，等待數(shù)據(jù)庫(kù)返回查詢結(jié)果予权，然后再繼續(xù)處理。然而浪册，由于數(shù)據(jù)庫(kù)查詢可能涉及磁盤(pán)讀寫(xiě)和網(wǎng)絡(luò)通信扫腺，其延時(shí)可能相當(dāng)大（長(zhǎng)達(dá)幾個(gè)到幾百毫秒，相比CPU的時(shí)鐘差了好幾個(gè)數(shù)量級(jí)）村象，線程會(huì)在這里阻塞等待結(jié)果返回笆环。對(duì)于高并發(fā)的訪問(wèn)，一方面線程長(zhǎng)期阻塞等待厚者，另一方面為了應(yīng)付新請(qǐng)求而不斷增加線程躁劣，因此會(huì)浪費(fèi)大量系統(tǒng)資源，同時(shí)線程的增多也會(huì)占用大量的 CPU 時(shí)間來(lái)處理內(nèi)存上下文切換库菲，
而且還容易遭受低速連接攻擊账忘。看看Node.js是如何解決這個(gè)問(wèn)題的：
db.query('SELECT * from some_table', function(res) {
res.output();
});
這段代碼中 db.query 的第二個(gè)參數(shù)是一個(gè)函數(shù)熙宇，我們稱為 回調(diào)函數(shù) 鳖擒。進(jìn)程在執(zhí)行到db.query 的時(shí)候，不會(huì)等待結(jié)果返回奇颠，而是直接繼續(xù)執(zhí)行后面的語(yǔ)句败去，直到進(jìn)入事件循環(huán)放航。當(dāng)數(shù)據(jù)庫(kù)查詢結(jié)果返回時(shí)烈拒，會(huì)將事件發(fā)送到事件隊(duì)列，等到線程進(jìn)入事件循環(huán)以后广鳍，才會(huì)調(diào)用之前的回調(diào)函數(shù)繼續(xù)執(zhí)行后面的邏輯荆几。
2.Page 31
單線程事件驅(qū)動(dòng)的異步式 I/O 比傳統(tǒng)的多線程阻塞式 I/O 究竟好在哪里呢？簡(jiǎn)而言之赊时，異步式 I/O 就是少了多線程的開(kāi)銷吨铸。對(duì)操作系統(tǒng)來(lái)說(shuō)，創(chuàng)建一個(gè)線程的代價(jià)是十分昂貴的祖秒，需要給它分配內(nèi)存诞吱、列入調(diào)度舟奠，同時(shí)在線程切換的時(shí)候還要執(zhí)行內(nèi)存換頁(yè)，CPU 的緩存被清空房维，切換回來(lái)的時(shí)候還要重新從內(nèi)存中讀取信息沼瘫，破壞了數(shù)據(jù)的局部性。
當(dāng)然咙俩，異步式編程的缺點(diǎn)在于不符合人們一般的程序設(shè)計(jì)思維耿戚，容易讓控制流變得晦澀難懂，給編碼和調(diào)試都帶來(lái)不小的困難阿趁。習(xí)慣傳統(tǒng)編程模式的開(kāi)發(fā)者在剛剛接觸到大規(guī)模的異步式應(yīng)用時(shí)往往會(huì)無(wú)所適從膜蛔，但慢慢習(xí)慣以后會(huì)好很多。盡管如此脖阵，異步式編程還是較為困難皂股，不過(guò)可喜的是現(xiàn)在已經(jīng)有了不少專門解決異步式編程問(wèn)題的庫(kù)（如 async ），參見(jiàn)6.2.2節(jié)独撇。
三屑墨、事件 Page 33
Node.js 所有的異步 I/O 操作在完成時(shí)都會(huì)發(fā)送一個(gè)事件到事件隊(duì)列。在開(kāi)發(fā)者看來(lái)纷铣，事件由 EventEmitter 對(duì)象提供卵史。前面提到的 fs.readFile 和 http.createServer 的回調(diào)函數(shù)都是通過(guò) EventEmitter 來(lái)實(shí)現(xiàn)的。下面我們用一個(gè)簡(jiǎn)單的例子說(shuō)明 EventEmitter的用法：
//event.js
var EventEmitter = require('events').EventEmitter;
var event = new EventEmitter();
event.on('some_event', function() {
console.log('some_event occured.');
});
setTimeout(function() {
event.emit('some_event');
}, 1000);
運(yùn)行這段代碼搜立，1秒后控制臺(tái)輸出了 some_event occured. 以躯。其原理是 event 對(duì)象注冊(cè)了事件 some_event 的一個(gè)監(jiān)聽(tīng)器，然后我們通過(guò) setTimeout 在1000毫秒以后向event 對(duì)象發(fā)送事件 some_event 啄踊，此時(shí)會(huì)調(diào)用 some_event 的監(jiān)聽(tīng)器忧设。我們將在 4.3.1節(jié)中詳細(xì)討論 EventEmitter 對(duì)象的用法。
Node.js 在什么時(shí)候會(huì)進(jìn)入事件循環(huán)呢颠通？答案是 Node.js 程序由事件循環(huán)開(kāi)始址晕，到事件循環(huán)結(jié)束，所有的邏輯都是事件的回調(diào)函數(shù)顿锰，所以 Node.js 始終在事件循環(huán)中谨垃，程序入口就是事件循環(huán)第一個(gè)事件的回調(diào)函數(shù)。事件的回調(diào)函數(shù)在執(zhí)行的過(guò)程中硼控，可能會(huì)發(fā)出 I/O 請(qǐng)求或直接發(fā)射（emit）事件刘陶，執(zhí)行完畢后再返回事件循環(huán)，事件循環(huán)會(huì)檢查事件隊(duì)列中有沒(méi)有未處理的事件牢撼，直到程序結(jié)束匙隔。
四、循環(huán)的陷阱 Page135
Node.js 的異步機(jī)制由事件和回調(diào)函數(shù)實(shí)現(xiàn)熏版，一開(kāi)始接觸可能會(huì)感覺(jué)違反常規(guī)纷责，但習(xí)慣以后就會(huì)發(fā)現(xiàn)還是很簡(jiǎn)單的捍掺。然而這之中其實(shí)暗藏了不少陷阱，一個(gè)很容易遇到的問(wèn)題就是循環(huán)中的回調(diào)函數(shù)再膳，初學(xué)者經(jīng)常容易陷入這個(gè)圈套乡小。讓我們從一個(gè)例子開(kāi)始說(shuō)明這個(gè)問(wèn)題。
//forloop.js
var fs = require('fs');
var files = ['a.txt', 'b.txt', 'c.txt'];
for (var i = 0; i < files.length; i++) {
fs.readFile(files[i], 'utf-8', function(err, contents) {
console.log(files[i] + ': ' + contents);
});
}
這段代碼的功能很直觀饵史，就是依次讀取文件 a.txt满钟、b.txt、c.txt胳喷，并輸出文件名和內(nèi)容湃番。假設(shè)這三個(gè)文件的內(nèi)容分別是 AAA、BBB 和 CCC吭露，那么我們期望的輸出結(jié)果就是：
a.txt: AAA
b.txt: BBB
c.txt: CCC
可是我們運(yùn)行這段代碼的結(jié)果是怎樣的呢吠撮？竟然是這樣的結(jié)果：
undefined: AAA
undefined: BBB
undefined: CCC
這個(gè)結(jié)果說(shuō)明文件內(nèi)容正確輸出了，而文件名卻不對(duì)讲竿，也就意味著泥兰， contents 的結(jié)果是正確的，但 files[i] 的值是 undefined 题禀。這怎么可能呢鞋诗，文件名不正確卻能讀取文件內(nèi)容？既然難以直觀地理解迈嘹，我們就把 files[i]分解并打印出來(lái)看看削彬，在讀取文件的回調(diào)函數(shù)中分別輸出 files 、 i 和 files[i] 秀仲。
//forloopi.js
var fs = require('fs');
var files = ['a.txt', 'b.txt', 'c.txt'];
for (var i = 0; i < files.length; i++) {
fs.readFile(files[i], 'utf-8', function(err, contents) {
console.log(files);
console.log(i);
console.log(files[i]);
});
}
運(yùn)行修改后的代碼融痛，結(jié)果如下：
[ 'a.txt', 'b.txt', 'c.txt' ]
3
undefined
[ 'a.txt', 'b.txt', 'c.txt' ]
3
undefined
[ 'a.txt', 'b.txt', 'c.txt' ]
3
undefined
看到這里是不是有點(diǎn)啟發(fā)了呢？三次輸出的 i 的值都是 3神僵，超出了 files 數(shù)組的下標(biāo)范圍雁刷，因此 files[i] 的值就是 undefined 了。這種情況通常會(huì)在 for 循環(huán)結(jié)束時(shí)發(fā)生保礼，例如 for (var i = 0; i < files.length; i++) 沛励，退出循環(huán)時(shí) i 的值就是files.length 的值。既然 i 的值是 3氓英，那么說(shuō)明了事實(shí)上 fs.readFile 的回調(diào)函數(shù)中訪問(wèn)到的 i 值都是循環(huán)退出以后的侯勉，因此不能分辨鹦筹。而 files[i] 作為 fs.readFile 的第一個(gè)參數(shù)在循環(huán)中就傳遞了铝阐，所以文件可以被定位到，而且可以顯示出文件的內(nèi)容☆砉眨現(xiàn)在問(wèn)題就明朗了：原因是3次讀取文件的回調(diào)函數(shù)事實(shí)上是同一個(gè)實(shí)例徘键，其中引用到的 i值是上面循環(huán)執(zhí)行結(jié)束后的值练对，因此不能分辨。如何解決這個(gè)問(wèn)題呢吹害？我們可以利用JavaScript 函數(shù)式編程的特性螟凭，手動(dòng)建立一個(gè)閉包：
//forloopclosure.js
var fs = require('fs');
var files = ['a.txt', 'b.txt', 'c.txt'];
for (var i = 0; i < files.length; i++) {
(function(i) {
fs.readFile(files[i], 'utf-8', function(err, contents) {
console.log(files[i] + ': ' + contents);
});
})(i);
}
上面代碼在 for 循環(huán)體中建立了一個(gè)匿名函數(shù)，將循環(huán)迭代變量 i 作為函數(shù)的參數(shù)傳遞并調(diào)用它呀。由于運(yùn)行時(shí)閉包的存在螺男，該匿名函數(shù)中定義的變量（包括參數(shù)表）在它內(nèi)部的函數(shù)（ fs.readFile 的回調(diào)函數(shù)）執(zhí)行完畢之前都不會(huì)釋放，因此我們?cè)谄渲性L問(wèn)到的 i 就分別是不同的閉包實(shí)例纵穿，這個(gè)實(shí)例是在循環(huán)體執(zhí)行的過(guò)程中創(chuàng)建的下隧，保留了不同的值。事實(shí)上以上這種寫(xiě)法并不常見(jiàn)谓媒，因?yàn)樗档土顺绦虻目勺x性淆院，故不推薦使用。大多數(shù)情況下我們可以用數(shù)組的 forEach 方法解決這個(gè)問(wèn)題：
//callbackforeach.js
var fs = require('fs');
var files = ['a.txt', 'b.txt', 'c.txt'];
files.forEach(function(filename) {
fs.readFile(filename, 'utf-8', function(err, contents) {
console.log(filename + ': ' + contents);
});
});
6.2.2 解決控制流難題
除了循環(huán)的陷阱句惯，Node.js 異步式編程還有一個(gè)顯著的問(wèn)題土辩，即深層的回調(diào)函數(shù)嵌套。在這種情況下抢野，我們很難像看基本控制流結(jié)構(gòu)一樣一眼看清回調(diào)函數(shù)之間的關(guān)系拷淘，因此當(dāng)程序規(guī)模擴(kuò)大時(shí)必須采取手段降低耦合度，以實(shí)現(xiàn)更加優(yōu)美指孤、可讀的代碼辕棚。這個(gè)問(wèn)題本身沒(méi)有立竿見(jiàn)影的解決方法，只能通過(guò)改變?cè)O(shè)計(jì)模式邓厕，時(shí)刻注意降低邏輯之間的耦合關(guān)系來(lái)解決逝嚎。除此之外，還有許多項(xiàng)目試圖解決這一難題详恼。async 是一個(gè)控制流解耦模塊补君，它提供了async.series 、 async.parallel 昧互、 async.waterfall 等函數(shù)挽铁，在實(shí)現(xiàn)復(fù)雜的邏輯時(shí)使用這些函數(shù)代替回調(diào)函數(shù)嵌套可以讓程序變得更清晰可讀且易于維護(hù)，但你必須遵循它的編程風(fēng)格敞掘。
streamlinejs和jscex則采用了更高級(jí)的手段叽掘，它的思想是“變同步為異步”，實(shí)現(xiàn)了一個(gè)JavaScript 到JavaScript 的編譯器玖雁，使用戶可以用同步編程的模式寫(xiě)代碼更扁，編譯后執(zhí)行時(shí)卻是異步的。eventproxy 的思路與前面兩者區(qū)別更大，它實(shí)現(xiàn)了對(duì)事件發(fā)射器的深度封裝浓镜，采用一種完全基于事件松散耦合的方式來(lái)實(shí)現(xiàn)控制流的梳理溃列。無(wú)論是以上哪種解決手段，都不是“非侵入性的”膛薛，也就是說(shuō)它對(duì)你編程模式的影響是非常大的听隐，你幾乎不可能無(wú)代價(jià)地在使用了一種模式很久以后從容地?fù)Q成另一種模式，或者直接糅合使用兩種模式哄啄。而且它們都是在解決了深層嵌套的回調(diào)函數(shù)可讀性問(wèn)題的同時(shí)雅任，引入了其他復(fù)雜的語(yǔ)法，帶來(lái)了另一種可讀性的降低咨跌。所以椿访，是否使用，使用哪種方案虑润，在決定之前是需要仔細(xì)斟酌研究的成玫。
