前言

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

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

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

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

1) libuv的架構(gòu)

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

Libuv的架構(gòu)

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

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

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

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

選擇兩個(gè)示例很簡單，因?yàn)閘ibuv架構(gòu)圖可視：libuv對 Network I/O和 File I/O采用不同的機(jī)制。

上圖右半部分，主要分成兩個(gè)部分：

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

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

Network I/O

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

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

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

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

File I/O

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

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

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

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

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

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

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

答案是：在第一次異步調(diào)用uv__work_submit()時(shí)。

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

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

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

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

以上就是關(guān)于本次相關(guān)的知識點(diǎn)內(nèi)容，感謝大家對腳本之家的支持。

最新評論