Nodejs探秘之深入理解單線程實現高並發原理
前言
從Node.js進入我們的視野時,我們所知道的它就由這些關鍵字組成 事件驅動、非阻塞I/O、高效、輕量,它在官網中也是這麼描述自己的。
Node.js® is a JavaScript runtime built on Chrome’s V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.
於是在我們剛接觸Nodejs時,會有所疑問:
1、為什麼在瀏覽器中運行的Javascript能與操作系統進行如此底層的交互?
2、nodejs 真的是單線程嗎?
3、如果是單線程,他是如何處理高並發請求的?
4、nodejs 事件驅動是如何實現的?
看到這些問題,是否有點頭大,別急,帶著這些問題我們來慢慢看這篇文章。
架構一覽
上面的問題,都挺底層的,所以我們從 Node.js 本身入手,先來看看 Node.js 的結構。
Node.js 標準庫,這部分是由 Javascript編寫的,即我們使用過程中直接能調用的 API。在源碼中的 lib 目錄下可以看到。
Node bindings,這一層是 Javascript與底層 C/C++ 能夠溝通的關鍵,前者通過 bindings 調用後者,相互交換數據。實現在 node.cc
這一層是支撐 Node.js 運行的關鍵,由 C/C++ 實現。
V8:Google 推出的 Javascript VM,也是 Node.js 為什麼使用的是 Javascript的關鍵,它為 Javascript提供瞭在非瀏覽器端運行的環境,它的高效是 Node.js 之所以高效的原因之一。
Libuv:它為 Node.js 提供瞭跨平臺,線程池,事件池,異步 I/O 等能力,是 Node.js 如此強大的關鍵。
C-ares:提供瞭異步處理 DNS 相關的能力。
http_parser、OpenSSL、zlib 等:提供包括 http 解析、SSL、數據壓縮等其他的能力。
與操作系統交互
舉個簡單的例子,我們想要打開一個文件,並進行一些操作,可以寫下面這樣一段代碼:
var fs = require('fs');fs.open('./test.txt', "w", function(err, fd) { //..do something});
這段代碼的調用過程大致可描述為:lib/fs.js → src/node_file.cc → uv_fs
lib/fs.js
async function open(path, flags, mode) { mode = modeNum(mode, 0o666); path = getPathFromURL(path); validatePath(path); validateUint32(mode, 'mode'); return new FileHandle( await binding.openFileHandle(pathModule.toNamespacedPath(path), stringToFlags(flags), mode, kUsePromises)); }
src/node_file.cc
static void Open(const FunctionCallbackInfo& args) { Environment* env = Environment::GetCurrent(args); const int argc = args.Length(); if (req_wrap_async != nullptr) { // open(path, flags, mode, req) AsyncCall(env, req_wrap_async, args, "open", UTF8, AfterInteger, uv_fs_open, *path, flags, mode); } else { // open(path, flags, mode, undefined, ctx) CHECK_EQ(argc, 5); FSReqWrapSync req_wrap_sync; FS_SYNC_TRACE_BEGIN(open); int result = SyncCall(env, args[4], &req_wrap_sync, "open", uv_fs_open, *path, flags, mode); FS_SYNC_TRACE_END(open); args.GetReturnValue().Set(result); } }
uv_fs
/* Open the destination file. */ dstfd = uv_fs_open(NULL, &fs_req, req->new_path, dst_flags, statsbuf.st_mode, NULL); uv_fs_req_cleanup(&fs_req);
Node.js 深入淺出上的一幅圖:
具體來說,當我們調用 fs.open 時,Node.js 通過 process.binding 調用 C/C++ 層面的 Open 函數,然後通過它調用 Libuv 中的具體方法 uv_fs_open,最後執行的結果通過回調的方式傳回,完成流程。
我們在 Javascript中調用的方法,最終都會通過 process.binding 傳遞到 C/C++ 層面,最終由他們來執行真正的操作。Node.js 即這樣與操作系統進行互動。
單線程
在傳統web 服務模型中,大多都使用多線程來解決並發的問題,因為I/O 是阻塞的,單線程就意味著用戶要等待,顯然這是不合理的,所以創建多個線程來響應用戶的請求。
Node.js 對http 服務的模型:
Node.js的單線程指的是主線程是“單線程”,由主要線程去按照編碼順序一步步執行程序代碼,假如遇到同步代碼阻塞,主線程被占用,後續的程序代碼執行就會被卡住。實踐一個測試代碼:
var http = require('http');function sleep(time) { var _exit = Date.now() + time * 1000; while( Date.now() < _exit ) {} return ; }var server = http.createServer(function(req, res){ sleep(10); res.end('server sleep 10s'); }); server.listen(8080);
下面為代碼塊的堆棧圖:
先將index.js的代碼改成這樣,然後打開瀏覽器,你會發現瀏覽器在10秒之後才做出反應,打出Hello Node.js。
JavaScript是解析性語言,代碼按照編碼順序一行一行被壓進stack裡面執行,執行完成後移除然後繼續壓下一行代碼塊進去執行。上面代碼塊的堆棧圖,當主線程接受瞭request後,程序被壓進同步執行的sleep執行塊(我們假設這裡就是程序的業務處理),如果在這10s內有第二個request進來就會被壓進stack裡面等待10s執行完成後再進一步處理下一個請求,後面的請求都會被掛起等待前面的同步執行完成後再執行。
那麼我們會疑問:為什麼一個單線程的效率可以這麼高,同時處理數萬級的並發而不會造成阻塞呢?就是我們下面所說的——–事件驅動。
事件驅動/事件循環
Event Loop is a programming construct that waits for and dispatches events or messages in a program.
1、每個Node.js進程隻有一個主線程在執行程序代碼,形成一個執行棧(execution context stack)。
2、主線程之外,還維護瞭一個”事件隊列”(Event queue)。當用戶的網絡請求或者其它的異步操作到來時,node都會把它放到Event Queue之中,此時並不會立即執行它,代碼也不會被阻塞,繼續往下走,直到主線程代碼執行完畢。
3、主線程代碼執行完畢完成後,然後通過Event Loop,也就是事件循環機制,開始到Event Queue的開頭取出第一個事件,從線程池中分配一個線程去執行這個事件,接下來繼續取出第二個事件,再從線程池中分配一個線程去執行,然後第三個,第四個。主線程不斷的檢查事件隊列中是否有未執行的事件,直到事件隊列中所有事件都執行完瞭,此後每當有新的事件加入到事件隊列中,都會通知主線程按順序取出交EventLoop處理。當有事件執行完畢後,會通知主線程,主線程執行回調,線程歸還給線程池。
4、主線程不斷重復上面的第三步。
我們所看到的node.js單線程隻是一個js主線程,本質上的異步操作還是由線程池完成的,node將所有的阻塞操作都交給瞭內部的線程池去實現,本身隻負責不斷的往返調度,並沒有進行真正的I/O操作,從而實現異步非阻塞I/O,這便是node單線程和事件驅動的精髓之處瞭。
Node.js 中的事件循環**的實現:**
Node.js采用V8作為js的解析引擎,而I/O處理方面使用瞭自己設計的libuv,libuv是一個基於事件驅動的跨平臺抽象層,封裝瞭不同操作系統一些底層特性,對外提供統一的API,事件循環機制也是它裡面的實現。 在src/node.cc中:
Environment* CreateEnvironment(IsolateData* isolate_data, Local context, int argc, const char* const* argv, int exec_argc, const char* const* exec_argv) { Isolate* isolate = context->GetIsolate(); HandleScope handle_scope(isolate); Context::Scope context_scope(context); auto env = new Environment(isolate_data, context, v8_platform.GetTracingAgent()); env->Start(argc, argv, exec_argc, exec_argv, v8_is_profiling); return env; }
這段代碼建立瞭一個node執行環境,可以看到第三行的uv_default_loop(),這是libuv庫中的一個函數,它會初始化uv庫本身以及其中的default_loop_struct,並返回一個指向它的指針default_loop_ptr。 之後,Node會載入執行環境並完成一些設置操作,然後啟動event loop
{ SealHandleScope seal(isolate); bool more; env.performance_state()->Mark( node::performance::NODE_PERFORMANCE_MILESTONE_LOOP_START); do { uv_run(env.event_loop(), UV_RUN_DEFAULT); v8_platform.DrainVMTasks(isolate); more = uv_loop_alive(env.event_loop()); if (more) continue; RunBeforeExit(&env); // Emit `beforeExit` if the loop became alive either after emitting // event, or after running some callbacks. more = uv_loop_alive(env.event_loop()); } while (more == true); env.performance_state()->Mark( node::performance::NODE_PERFORMANCE_MILESTONE_LOOP_EXIT); } env.set_trace_sync_io(false); const int exit_code = EmitExit(&env); RunAtExit(&env);
more用來標識是否進行下一輪循環。 env->event_loop()會返回之前保存在env中的default_loop_ptr,uv_run函數將以指定的UV_RUN_DEFAULT模式啟動libuv的event loop。如果當前沒有I/O事件也沒有定時器事件,則uv_loop_alive返回false。
Event Loop的執行順序
根據Node.js官方介紹,每次事件循環都包含瞭6個階段,對應到 libuv 源碼中的實現,如下圖所示:
- timers 階段:這個階段執行timer(setTimeout、setInterval)的回調
- I/O callbacks 階段:執行一些系統調用錯誤,比如網絡通信的錯誤回調
- idle, prepare 階段:僅node內部使用
- poll 階段:獲取新的I/O事件, 適當的條件下node將阻塞在這裡
- check 階段:執行setImmediate()的回調
- close callbacks 階段:執行socket的close事件回調。
核心函數uv_run:源碼 核心源碼
int uv_run(uv_loop_t* loop, uv_run_mode mode) { int timeout; int r; int ran_pending;//首先檢查我們的loop還是否活著//活著的意思代表loop中是否有異步任務//如果沒有直接就結束 r = uv__loop_alive(loop); if (!r) uv__update_time(loop);//傳說中的事件循環,你沒看錯瞭啊!就是一個大while while (r != 0 && loop->stop_flag == 0) { //更新事件階段 uv__update_time(loop); //處理timer回調 uv__run_timers(loop); //處理異步任務回調 ran_pending = uv__run_pending(loop);//沒什麼用的階段 uv__run_idle(loop); uv__run_prepare(loop); //這裡值得註意瞭 //從這裡到後面的uv__io_poll都是非常的不好懂的 //先記住timeout是一個時間 //uv_backend_timeout計算完畢後,傳遞給uv__io_poll //如果timeout = 0,則uv__io_poll會直接跳過 timeout = 0; if ((mode == UV_RUN_ONCE && !ran_pending) || mode == UV_RUN_DEFAULT) timeout = uv_backend_timeout(loop); uv__io_poll(loop, timeout); //就是跑setImmediate uv__run_check(loop); //關閉文件描述符等操作 uv__run_closing_handles(loop); if (mode == UV_RUN_ONCE) { /* UV_RUN_ONCE implies forward progress: at least one callback must have * been invoked when it returns. uv__io_poll() can return without doing * I/O (meaning: no callbacks) when its timeout expires - which means we * have pending timers that satisfy the forward progress constraint. * * UV_RUN_NOWAIT makes no guarantees about progress so it's omitted from * the check. */ uv__update_time(loop); uv__run_timers(loop); } r = uv__loop_alive(loop); if (mode == UV_RUN_ONCE || mode == UV_RUN_NOWAIT) break; } /* The if statement lets gcc compile it to a conditional store. Avoids * dirtying a cache line. */ if (loop->stop_flag != 0) loop->stop_flag = 0; return r; }
代碼中我已經寫得很詳細瞭,相信不熟悉c代碼的各位也能輕易搞懂,沒錯,事件循環就是一個大while而已!神秘的面紗就此揭開。
uv__io_poll階段
這個階段設計得非常巧妙,這個函數第二個參數是一個timeout參數,而這個timeOut由來自uv_backend_timeout函數,我們進去一探究竟!
源碼
int uv_backend_timeout(const uv_loop_t* loop) { if (loop->stop_flag != 0) return 0; if (!uv__has_active_handles(loop) && !uv__has_active_reqs(loop)) return 0; if (!QUEUE_EMPTY(&loop->idle_handles)) return 0; if (!QUEUE_EMPTY(&loop->pending_queue)) return 0; if (loop->closing_handles) return 0; return uv__next_timeout(loop); }
原來是一個多步if函數,我們一個一個分析
1. stop_flag:這個標記是 0的時候,意味著事件循環跑完這一輪就退出瞭,返回的時間是0
2. !uv__has_active_handles和!uv__has_active_reqs:看名字都知道,如果沒有任何的異步任務(包括timer和異步I/O),那timeOut時間一定就是0瞭
3. QUEUE_EMPTY(idle_handles)和QUEUE_EMPTY(pending_queue):異步任務是通過註冊的方式放進瞭pending_queue中,無論是否成功,都已經被註冊,如果什麼都沒有,這兩個隊列就是空,所以沒必要等瞭。
4. closing_handles:我們的循環進入瞭關閉階段,沒必要等待瞭
以上所有條件判斷來判斷去,為的就是等這句話return uv__next_timeout(loop);這句話,告訴瞭uv__io_poll說:你到底停多久,接下來,我們繼續看這個神奇的uv__next_timeout是怎麼獲取時間的。
int uv__next_timeout(const uv_loop_t* loop) { const struct heap_node* heap_node; const uv_timer_t* handle; uint64_t diff; heap_node = heap_min((const struct heap*) &loop->timer_heap); if (heap_node == NULL) return -1; /* block indefinitely */ handle = container_of(heap_node, uv_timer_t, heap_node); if (handle->timeout time) return 0;//這句代碼給出瞭關鍵性的指導 diff = handle->timeout - loop->time;//不能大於最大的INT_MAX if (diff > INT_MAX) diff = INT_MAX; return diff; }
等待結束以後,就會進入check 階段.然後進入closing_handles階段,至此一個事件循環結束。 因為是源碼解析,所以具體的我就不多說,大傢隻可以看官方文檔
總結
1、Nodejs與操作系統交互,我們在 Javascript中調用的方法,最終都會通過 process.binding 傳遞到 C/C++ 層面,最終由他們來執行真正的操作。Node.js 即這樣與操作系統進行互動。
2、nodejs所謂的單線程,隻是主線程是單線程,所有的網絡請求或者異步任務都交給瞭內部的線程池去實現,本身隻負責不斷的往返調度,由事件循環不斷驅動事件執行。
3、Nodejs之所以單線程可以處理高並發的原因,得益於libuv層的事件循環機制,和底層線程池實現。
4、Event loop就是主線程從主線程的事件隊列裡面不停循環的讀取事件,驅動瞭所有的異步回調函數的執行,Event loop總共7個階段,每個階段都有一個任務隊列,當所有階段被順序執行一次後,event loop 完成瞭一個 tick。
以上就是Nodejs探秘之深入理解單線程實現高並發原理的詳細內容,更多關於Nodejs的資料請關註WalkonNet其它相關文章!