前言

這應該是Nodejs的運行原理的第7篇分享，這篇過后，短時間內不會再分享Nodejs的運行原理，會停更一段時間，PS：不是不更，而是會開挖新的坑，最近有在研究RPG Maker MV，區(qū)塊鏈，云計算，可能會更新一些相關文章，或者相關教學。

回到正題，異步編程的難點在于請求與響應不是按順序發(fā)生的。以http server 為例，異步編程賦予了server 高并發(fā)的品質，而且他可以以很小的資源代價，不斷地接受和處理請求。但是快速處理請求不表示快速地返回請求=>高并發(fā)不等同于快速反饋。

在Nodejs中，libuv則為異步編程的實現提供了可能。libuv為builtin modules 提供了API，這些API用來支撐請求和數據的返回的異步處理方式。

這一篇分享，我們主要討論libuv的運行原理，從兩個角度出發(fā)：

1) libuv的架構

2) 案例，從細節(jié)的角度看libuv是如何對待不同I/O請求，按照不同的方式來完成異步請求和數據返回的。

Libuv的架構

從左往右可分為兩部分，Network I/O的相關請求，另一部分File I/O，DNS Ops和User Code組成。

上圖展示了libuv細節(jié)的流程，圖中代碼很簡單，包括2個部分：

1. server.listen()是用來創(chuàng)建TCP server時，通常放在最后一步執(zhí)行的代碼。主要指定服務器工作的端口以及回調函數。

2. fs.open()是用異步的方式打開一個文件。

選擇兩個示例很簡單，因為libuv架構圖可視：libuv對 Network I/O和 File I/O采用不同的機制。

上圖右半部分，主要分成兩個部分：

1. 主線程：主線程也是node啟動時執(zhí)行的現成。node啟動時，會完成一系列的初始化動作，啟動V8 engine，進入下一個循環(huán)。

2. 線程池：線程池的數量可以通過環(huán)境變量UV_THREADPOOL_SIZE配置，最大不超過128個，默認為4個。

Network I/O

V8 engine執(zhí)行從server.listen() 開始，調用builtin module Tcp_wrap 的過程。

在創(chuàng)建TCP鏈接的過程中，libuv直接參與Tcp_wrap.cc函數中的 TCPWrap::listen() 調用uv_listen()開始到執(zhí)行uv_io_start()結束?？雌饋砗芏虝旱倪^程，其實是類似linux kernel的中斷處理機制。

uv_io_start()負載將handle插入到處理的water queue中。這樣的好處是請求能夠立即得到處理。中斷處理機制里面的下半部分與數據處理操作相似，交由主線程去完成處理。

代碼邏輯很簡單，查看loop中是否包含handle，如果有遍歷default loop。

File I/O

這里我們研究一下 File I/O。

同Network I/O一樣，我們的應用所依賴的fs模塊，后面有一個builtin module Node_file.cc作為支撐。 Node_file.cc包含了各種我們常用的文件操作的接口，例如open, read, write, chmod,chown等。但同時，它們都支持異步模式。 我們通過Node_file.cc中的Open()函數來研究一下具體的實現細節(jié)。

如果你用類似source insight之類的代碼閱讀工具跟蹤一下代碼調用順序，會很容易發(fā)現對于異步模式，Open()函數會在一系列輔助操作之后，進入函數uv_fs_open(),并且傳入了一個FSReqWrap的對象。

FSReqWrap()，從名字可以看得出來，這是一個wrap,且是與FS相關的請求。也就是說，它基于某一個現成的機制來實現與FS相關的請求操作。這個現成的機制就是ReqWrap。好吧，它也是個wrap。乘你還沒瘋的時候，看一下圖6吧。這里完整展示了FSReqWrap類繼承關系。

除了FSReqWrap，還有其它Wrap,例如PipeConnectWrap，TCPConnectWrap等等。每個Wrap均為一種請求類型服務。 但是這些wrap，都是node自身的行為，而與libuv相關的是什么呢？上圖中表示出了FSReqWrap關鍵的數據結構 uv_fs_s req__。

讓我們把目光回到uv_fs_open()。在調用這個函數時， req__作為其一個重要的參數被傳遞進去。而在uv_fs_open()內部，req__則被添加到work queue的末尾中去。圖3 thread pool中的thread會去領取這些request進行處理。 每個request很像一個粘貼板，它將event loop, work queue，每個請求的處理函數(work())，以及請求結束處理函數(done())綁定在一起。綁定的操作在uv__work_submit()中完成。 例如對于這里的req__，綁定在它身上的work()為uv__fs_work(), done()為uv__fs_done()。

這里有一個比較有意思的問題值得額外看一下。我們的thread pool是在什么時候建立的呢？

答案是：在第一次異步調用uv__work_submit()時。

每個thead的入口函數是 Threadpool.c中的worker()。工作邏輯比較簡單，依次取出work queue中的請求，執(zhí)行綁定在該請求上的work()函數。 前面我們提到的綁定在請求上的done()函數在哪里執(zhí)行呢？這也是一個比較有意思的操作。libuv通過uv_async_send()通知event loop去執(zhí)行相應的callback函數，也即我們綁定在request上的done()函數。uv__work_done()用于完成這樣的操作。

uv_async_send()與主線程之間通過PIPE通信。

我在這一小節(jié)以一個FSReqWrap以及Open()函數為例，描述了libuv處理這種File I/O請求時所涉及的各種操作：

建立thread pool(只建立一次) 在每個請求req__上綁定與其相關的event loop, work queue, work(), done() thread worker()用來處理work queue里面的每個請求，并執(zhí)行work() 通過uv_async_send()通知event loop執(zhí)行done()

以上就是關于本次相關的知識點內容，感謝大家對腳本之家的支持。

最新評論