http://www.infoq.com/cn/articles/nodejs-asynchronous-io
作者 田永強 發佈於 2012年3月22日
專欄的第五篇文章《Node.js的異步實現》。之前介紹了Node.js的事件機制，也許讀者對此尚會覺得意猶未盡，因爲僅僅只是簡單的事件機制，並不能道盡Node.js的神奇。如果Node.js是一盤別開生面的磁帶，那麼事件與異步分別是其A面和B面，它們共同組成了Node.js的別樣之處。本文將翻轉Node.js到B面，與你共同聆聽。
相關廠商內容
進階xUnit培訓課程，由Jolt大獎著作作者Gerard親自授課，越早報名優惠越多！
京東網架構師何斌，確定QCon杭州分享主題：虛擬化如何支撐京東業務！
oolShell博主，亞馬遜中國研發經理陳皓，確定QCon杭州分享主題：建一支強悍的小團隊！
相關贊助商
QCon杭州2012大會10月25~27，10月10日前報名享受9折優惠，5人以上團購享有更多優惠！
異步I/O
在操作系統中，程序運行的空間分爲內核空間和用戶空間。我們常常提起的異步I/O，其實質是用戶空間中的程序不用依賴內核空間中的I/O操作實際完成，即可進行後續任務。以下僞代碼模仿了一個從磁盤上獲取文件和一個從網絡中獲取文件的操作。異步I/O的效果就是getFileFromNet的調用不依賴於getFile調用的結束。
getFile("file_path");
getFileFromNet("url");
如果以上兩個任務的時間分別爲m和n。採用同步方式的程序要完成這兩個任務的時間總花銷會是m + n。但是如果是採用異步方式的程序，在兩種I/O可以並行的狀況下（比如網絡I/O與文件I/O），時間開銷將會減小爲max(m, n)。
異步I/O的必要性
有的語言爲了設計得使應用程序調用方便，將程序設計爲同步I/O的模型。這意味着程序中的後續任務都需要等待I/O的完成。在等待I/O完成的過程中，程序無法充分利用CPU。爲了充分利用CPU，和使I/O可以並行，目前有兩種方式可以達到目的：
- 多線程單進程
多線程的設計之處就是爲了在共享的程序空間中，實現並行處理任務，從而達到充分利用CPU的效果。多線程的缺點在於執行時上下文交換的開銷較大，和狀態同步（鎖）的問題。同樣它也使得程序的編寫和調用複雜化。 - 單線程多進程
爲了避免多線程造成的使用不便問題，有的語言選擇了單線程保持調用簡單化，採用啓動多進程的方式來達到充分利用CPU和提升總體的並行處理能力。 它的缺點在於業務邏輯複雜時（涉及多個I/O調用），因爲業務邏輯不能分佈到多個進程之間，事務處理時長要遠遠大於多線程模式。
前者在性能優化上還有迴旋的餘地，後者的做法純粹是一種加三倍服務器的行爲。
而且現在的大型Web應用中，單機的情形是十分稀少的，一個事務往往需要跨越網絡幾次才能完成最終處理。如果網絡速度不夠理想，m和n值都將會變大，這時同步I/O的語言模型將會露出其最脆弱的狀態。
這種場景下的異步I/O將會體現其優勢，max(m, n)的時間開銷可以有效地緩解m和n值增長帶來的性能問題。而當並行任務更多的時候，m + n + …與max(m, n, …)之間的孰優孰劣更是一目瞭然。從這個公式中，可以瞭解到異步I/O在分佈式環境中是多麼重要，而Node.js天然地支持這種異步I/O，這是衆多雲計算廠商對其青睞的根本原因。
操作系統對異步I/O的支持
我們聽到Node.js時，我們常常會聽到異步，非阻塞，回調，事件這些詞語混合在一起。其中，異步與非阻塞聽起來似乎是同一回事。從實際效果的角度說，異步和非阻塞都達到了我們並行I/O的目的。但是從計算機內核I/O而言，異步/同步和阻塞/非阻塞實際上時兩回事。
- I/O的阻塞與非阻塞
阻塞模式的I/O會造成應用程序等待，直到I/O完成。同時操作系統也支持將I/O操作設置爲非阻塞模式，這時應用程序的調用將可能在沒有拿到真正數據時就立即返回了，爲此應用程序需要多次調用才能確認I/O操作完全完成。 - I/O的同步與異步
I/O的同步與異步出現在應用程序中。如果做阻塞I/O調用，應用程序等待調用的完成的過程就是一種同步狀況。相反，I/O爲非阻塞模式時，應用程序則是異步的。
異步I/O與輪詢技術
當進行非阻塞I/O調用時，要讀到完整的數據，應用程序需要進行多次輪詢，才能確保讀取數據完成，以進行下一步的操作。
輪詢技術的缺點在於應用程序要主動調用，會造成佔用較多CPU時間片，性能較爲低下。現存的輪詢技術有以下這些：
- read
- select
- poll
- epoll
- pselect
- kqueue
read是性能最低的一種，它通過重複調用來檢查I/O的狀態來完成完整數據讀取。select是一種改進方案，通過對文件描述符上的事件狀態來進行判斷。操作系統還提供了poll、epoll等多路複用技術來提高性能。
輪詢技術滿足了異步I/O確保獲取完整數據的保證。但是對於應用程序而言，它仍然只能算時一種同步，因爲應用程序仍然需要主動去判斷I/O的狀態，依舊花費了很多CPU時間來等待。
上一種方法重複調用read進行輪詢直到最終成功，用戶程序會佔用較多CPU，性能較爲低下。而實際上操作系統提供了select方法來代替這種重複read輪詢進行狀態判斷。select內部通過檢查文件描述符上的事件狀態來進行判斷數據是否完全讀取。但是對於應用程序而言它仍然只能算是一種同步，因爲應用程序仍然需要主動去判斷I/O的狀態，依舊花費了很多CPU時間等待，select也是一種輪詢。
理想的異步I/O模型
理想的異步I/O應該是應用程序發起異步調用，而不需要進行輪詢，進而處理下一個任務，只需在I/O完成後通過信號或是回調將數據傳遞給應用程序即可。
幸運的是，在Linux下存在一種這種方式，它原生提供了一種異步非阻塞I/O方式（AIO）即是通過信號或回調來傳遞數據的。
不幸的是，只有Linux下有這麼一種支持，而且還有缺陷（AIO僅支持內核I/O中的O_DIRECT方式讀取，導致無法利用系統緩存。參見：http://forum.nginx.org/read.php?2,113524,113587#msg-113587
以上都是基於非阻塞I/O進行的設定。另一種理想的異步I/O是採用阻塞I/O，但加入多線程，將I/O操作分到多個線程上，利用線程之間的通信來模擬異步。Glibc的AIO便是這樣的典型http://www.ibm.com/developerworks/linux/library/l-async/。然而遺憾在於，它存在一些難以忍受的缺陷和bug。可以簡單的概述爲：Linux平臺下沒有完美的異步I/O支持。
所幸的是，libev的作者Marc Alexander Lehmann重新實現了一個異步I/O的庫：libeio。libeio實質依然是採用線程池與阻塞I/O模擬出來的異步I/O。
那麼在Windows平臺下的狀況如何呢？而實際上，Windows有一種獨有的內核異步IO方案：IOCP。IOCP的思路是真正的異步I/O方案，調用異步方法，然後等待I/O完成通知。IOCP內部依舊是通過線程實現，不同在於這些線程由系統內核接手管理。IOCP的異步模型與Node.js的異步調用模型已經十分近似。
以上兩種方案則正是Node.js選擇的異步I/O方案。由於Windows平臺和*nix平臺的差異，Node.js提供了libuv來作爲抽象封裝層，使得所有平臺兼容性的判斷都由這一層次來完成，保證上層的Node.js與下層的libeio/libev及IOCP之間各自獨立。Node.js在編譯期間會判斷平臺條件，選擇性編譯unix目錄或是win目錄下的源文件到目標程序中。
下文我們將通過解釋Windows下Node.js異步I/O（IOCP）的簡單例子來探尋一下從JavaScript代碼到系統內核之間都發生了什麼。
Node.js的異步I/O模型
很多同學在遇見Node.js後必然產生過對回調函數究竟如何被調用產生過好奇。在文件I/O這一塊與普通的業務邏輯的回調函數不同在於它不是由我們自己的代碼所觸發，而是系統調用結束後，由系統觸發的。下面我們以最簡單的fs.open方法來作爲例子，探索Node.js與底層之間是如何執行異步I/O調用和回調函數究竟是如何被調用執行的。
fs.open = function(path, flags, mode, callback) {
callback = arguments[arguments.length - 1];
if (typeof(callback) !== 'function') {
callback = noop;
}
mode = modeNum(mode, 438 /*=0666*/);
binding.open(pathModule._makeLong(path),
stringToFlags(flags),
mode,
callback);
};
fs.open的作用是根據指定路徑和參數，去打開一個文件，從而得到一個文件描述符，是後續所有I/O操作的初始操作。
在JavaScript層面上調用的fs.open方法最終都透過node_file.cc調用到了libuv中的uv_fs_open方法，這裏libuv作爲封裝層，分別寫了兩個平臺下的代碼實現，編譯之後，只會存在一種實現被調用。
請求對象
在uv_fs_open的調用過程中，Node.js創建了一個FSReqWrap請求對象。從JavaScript傳入的參數和當前方法都被封裝在這個請求對象中，其中回調函數則被設置在這個對象的oncomplete_sym屬性上。
req_wrap->object_->Set(oncomplete_sym, callback);
對象包裝完畢後，調用QueueUserWorkItem方法將這個FSReqWrap對象推入線程池中等待執行。
QueueUserWorkItem(&uv_fs_thread_proc, req, WT_EXECUTELONGFUNCTION)
QueueUserWorkItem接受三個參數，第一個是要執行的方法，第二個是方法的上下文，第三個是執行的標誌。當線程池中有可用線程的時候調用uv_fs_thread_proc方法執行。該方法會根據傳入的類型調用相應的底層函數，以uv_fs_open爲例，實際會調用到fs__open方法。調用完畢之後，會將獲取的結果設置在req->result上。然後調用PostQueuedCompletionStatus通知我們的IOCP對象操作已經完成。
PostQueuedCompletionStatus((loop)->iocp, 0, 0, &((req)->overlapped))
PostQueuedCompletionStatus方法的作用是向創建的IOCP上相關的線程通信，線程根據執行狀況和傳入的參數判定退出。
至此，由JavaScript層面發起的異步調用第一階段就此結束。
事件循環
在調用uv_fs_open方法的過程中實際上應用到了事件循環。以在Windows平臺下的實現中，啓動Node.js時，便創建了一個基於IOCP的事件循環loop，並一直處於執行狀態。
uv_run(uv_default_loop());
每次循環中，它會調用IOCP相關的GetQueuedCompletionStatus方法檢查是否線程池中有執行完的請求，如果存在，poll操作會將請求對象加入到loop的pending_reqs_tail屬性上。 另一邊這個循環也會不斷檢查loop對象上的pending_reqs_tail引用，如果有可用的請求對象，就取出請求對象的result屬性作爲結果傳遞給oncomplete_sym執行，以此達到調用JavaScript中傳入的回調函數的目的。 至此，整個異步I/O的流程完成結束。其流程如下：
事件循環和請求對象構成了Node.js的異步I/O模型的兩個基本元素，這也是典型的消費者生產者場景。在Windows下通過IOCP的GetQueuedCompletionStatus、PostQueuedCompletionStatus、QueueUserWorkItem方法與事件循環實。對於*nix平臺下，這個流程的不同之處在與實現這些功能的方法是由libeio和libev提供。
參考：
- 《nodejs異步IO的實現》http://cnodejs.org/blog/?p=244
- 《linux AIO （異步IO） 那點事兒》http://cnodejs.org/blog/?p=2426
- 《libev 設計分析》http://cnodejs.org/blog/?p=2489
- 《Node Roadmap》http://nodejs.org/nodeconf.pdf
- 《多路複用select(2)與事件通知poll(2)、epoll(7)內核源碼初探》http://blog.dccmx.com/2011/04/select-poll-epoll-in-kernel/
- 《使用異步 I/O 大大提高應用程序的性能》http://www.ibm.com/developerworks/cn/linux/l-async/
關於作者
田永強，新浪微博@樸靈，前端工程師，曾就職於SAP，現就職於淘寶，花名樸靈，致力於NodeJS和Mobile Web App方面的研發工作。雙修前後端JavaScript，寄望將NodeJS引薦給更多的工程師。興趣：讀萬卷書，行萬里路。個人Github地址：http://github.com/JacksonTian。
感謝崔康對本文的審校。
給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至[email protected]。也歡迎大家通過新浪微博（@InfoQ）或者騰訊微博（@InfoQ）關注我們，並與我們的編輯和其他讀者朋友交流。