專欄的第五篇文章《Node.js的異步實現》。之前介紹了Node.js的事件機制，也許讀者對此尚會覺得意猶未盡，因為僅僅只是簡單的事件機制，并不能道盡Node.js的神奇。如果Node.js是一盤別開生面的磁帶，那么事件與異步分別是其A面和B面，它們共同組成了Node.js的別樣之處。本文將翻轉Node.js到B面，與你共同聆聽。 ## 異步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](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/](http://www.ibm.com/developerworks/linux/library/l-async/)。然而遺憾在于，它存在一些難以忍受的[缺陷和bug](http://davmac.org/davpage/linux/async-io.html)。可以簡單的概述為：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](http://msdn.microsoft.com/en-us/library/windows/desktop/ms684957(v=vs.85).aspx)方法將這個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](http://msdn.microsoft.com/en-us/library/windows/desktop/aa365458(v=vs.85).aspx)方法的作用是向創建的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](http://cnodejs.org/blog/?p=244) * 《linux AIO （異步IO） 那點事兒》[http://cnodejs.org/blog/?p=2426](http://cnodejs.org/blog/?p=2426) * 《libev 設計分析》[http://cnodejs.org/blog/?p=2489](http://cnodejs.org/blog/?p=2489) * 《Node Roadmap》[http://nodejs.org/nodeconf.pdf](http://nodejs.org/nodeconf.pdf) * 《多路復用select(2)與事件通知poll(2)、epoll(7)內核源碼初探》[http://blog.dccmx.com/2011/04/select-poll-epoll-in-kernel/](http://blog.dccmx.com/2011/04/select-poll-epoll-in-kernel/) * 《使用異步 I/O 大大提高應用程序的性能》[http://www.ibm.com/developerworks/cn/linux/l-async/](http://www.ibm.com/developerworks/cn/linux/l-async/)