Nginx 架構淺析
作者:handsomeli,騰訊 IEG 後臺開發工程師
1.Nginx 基礎架構
nginx 啓動後以 daemon 形式在後臺運行,後臺進程包含一個 master 進程和多個 worker 進程。如下圖所示:
master 與 worker
nginx 是由一個 master 管理進程,多個 worker 進程處理工作的多進程模型。基礎架構設計,如下圖所示:
基礎架構設計
master 負責管理 worker 進程,worker 進程負責處理網絡事件。整個框架被設計爲一種依賴事件驅動、異步、非阻塞的模式。
如此設計的優點:
-
- 可以充分利用多核機器,增強併發處理能力。
-
- 多 worker 間可以實現負載均衡。
-
3.Master 監控並統一管理 worker 行爲。在 worker 異常後,可以主動拉起 worker 進程,從而提升了系統的可靠性。並且由 Master 進程控制服務運行中的程序升級、配置項修改等操作,從而增強了整體的動態可擴展與熱更的能力。
2.Master 進程
2.1 核心邏輯
master 進程的主邏輯在ngx_master_process_cycle
,核心關注源碼:
ngx_master_process_cycle(ngx_cycle_t *cycle)
{
...
ngx_start_worker_processes(cycle, ccf->worker_processes,
NGX_PROCESS_RESPAWN);
...
for ( ;; ) {
if (delay) {...}
ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "sigsuspend");
sigsuspend(&set);
ngx_time_update();
ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
"wake up, sigio %i", sigio);
if (ngx_reap) {
ngx_reap = 0;
ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "reap children");
live = ngx_reap_children(cycle);
}
if (!live && (ngx_terminate || ngx_quit)) {...}
if (ngx_terminate) {...}
if (ngx_quit) {...}
if (ngx_reconfigure) {...}
if (ngx_restart) {...}
if (ngx_reopen) {...}
if (ngx_change_binary) {...}
if (ngx_noaccept) {
ngx_noaccept = 0;
ngx_noaccepting = 1;
ngx_signal_worker_processes(cycle,
ngx_signal_value(NGX_SHUTDOWN_SIGNAL));
}
}
}
由上述代碼,可以理解,master 進程主要用來管理 worker 進程,具體包括如下 4 個主要功能:
-
- 接受來自外界的信號。其中 master 循環中的各項標誌位就對應着各種信號,如:
ngx_quit
代表QUIT
信號,表示優雅的關閉整個服務。
- 接受來自外界的信號。其中 master 循環中的各項標誌位就對應着各種信號,如:
-
- 向各個 worker 進程發送信。比如
ngx_noaccept
代表WINCH
信號,表示所有子進程不再接受處理新的連接,由 master 向所有的子進程發送 QUIT 信號量。
- 向各個 worker 進程發送信。比如
-
- 監控 worker 進程的運行狀態。比如
ngx_reap
代表CHILD
信號,表示有子進程意外結束,這時需要監控所有子進程的運行狀態,主要由ngx_reap_children
完成。
- 監控 worker 進程的運行狀態。比如
-
- 當 woker 進程退出後(異常情況下),會自動重新啓動新的 woker 進程。主要也是在
ngx_reap_children
- 當 woker 進程退出後(異常情況下),會自動重新啓動新的 woker 進程。主要也是在
2.2 熱更
2.2.1 熱重載 - 配置熱更
熱重載
nginx 熱更配置時,可以保持運行中平滑更新配置,具體流程如下:
-
- 更新 nginx.conf 配置文件,向 master 發送 SIGHUP 信號或執行 nginx -s reload
-
2.master 進程使用新配置,啓動新的 worker 進程
-
- 使用舊配置的 worker 進程,不再接受新的連接請求,並在完成已存在的連接後退出
2.2.2 熱升級 - 程序熱更
熱升級
nginx 熱升級過程如下:
-
- 將舊 Nginx 文件換成新 Nginx 文件(注意備份)
-
- 向 master 進程發送 USR2 信號(平滑升級到新版本的 Nginx 程序)
-
3.master 進程修改 pid 文件號,加後綴. oldbin
-
4.master 進程用新 Nginx 文件啓動新 master 進程,此時新老 master/worker 同時存在。
-
- 向老 master 發送 WINCH 信號,關閉舊 worker 進程,觀察新 worker 進程工作情況。若升級成功,則向老 master 進程發送 QUIT 信號,關閉老 master 進程;若升級失敗,則需要回滾,向老 master 發送 HUP 信號(重讀配置文件),向新 master 發送 QUIT 信號,關閉新 master 及 worker。
3.Worker 進程
3.1 核心邏輯
worker 進程的主邏輯在ngx_worker_process_cycle
,核心關注源碼:
ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data)
{
ngx_int_t worker = (intptr_t) data;
ngx_process = NGX_PROCESS_WORKER;
ngx_worker = worker;
ngx_worker_process_init(cycle, worker);
ngx_setproctitle("worker process");
for ( ;; ) {
if (ngx_exiting) {...}
ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "worker cycle");
ngx_process_events_and_timers(cycle);
if (ngx_terminate) {...}
if (ngx_quit) {...}
if (ngx_reopen) {...}
}
}
由上述代碼,可以理解,worker 進程主要在處理網絡事件,通過ngx_process_events_and_timers
方法實現,其中事件主要包括:網絡事件、定時器事件。
3.2 事件驅動 - epoll
worker 進程在處理網絡事件時,依靠 epoll 模型,來管理併發連接,實現了事件驅動、異步、非阻塞等特性。如下圖所示:
infographic-Inside-NGINX_nonblocking
通常海量併發連接過程中,每一時刻(相對較短的一段時間),往往只需要處理一小部分有事件的連接即活躍連接
。基於以上現象,epoll 通過將連接管理
與活躍連接管理
進行分離,實現了高效、穩定的網絡 IO 處理能力。
網絡模型對比
其中,epoll 利用紅黑樹高效的增刪查效率來管理連接
,利用一個雙向鏈表來維護活躍連接
。
epoll 數據結構
3.3 驚羣
由於 worker 都是由 master 進程 fork 產生,所以 worker 都會監聽相同端口。這樣多個子進程在 accept 建立連接時會發生爭搶,帶來著名的 “驚羣” 問題。worker 核心處理邏輯ngx_process_events_and_timers
核心代碼如下:
void ngx_process_events_and_timers(ngx_cycle_t *cycle){
//這裏面會對監聽socket處理
...
if (ngx_accept_disabled > 0) {
ngx_accept_disabled--;
} else {
//獲得鎖則加入wait集合,
if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
return;
}
...
//設置網絡讀寫事件延遲處理標誌,即在釋放鎖後處理
if (ngx_accept_mutex_held) {
flags |= NGX_POST_EVENTS;
}
}
...
//這裏面epollwait等待網絡事件
//網絡連接事件,放入ngx_posted_accept_events隊列
//網絡讀寫事件,放入ngx_posted_events隊列
(void) ngx_process_events(cycle, timer, flags);
...
//先處理網絡連接事件,只有獲取到鎖,這裏纔會有連接事件
ngx_event_process_posted(cycle, &ngx_posted_accept_events);
//釋放鎖,讓其他進程也能夠拿到
if (ngx_accept_mutex_held) {
ngx_shmtx_unlock(&ngx_accept_mutex);
}
//處理網絡讀寫事件
ngx_event_process_posted(cycle, &ngx_posted_events);
}
由上述代碼可知,Nginx 解決驚羣的方法:
-
- 將連接事件與讀寫事件進行分離。連接事件存放爲
ngx_posted_accept_events
,讀寫事件存放爲ngx_posted_events
。
- 將連接事件與讀寫事件進行分離。連接事件存放爲
-
- 設置
ngx_accept_mutex
鎖,只有獲得鎖的進程,纔可以處理連接事件。
- 設置
3.4 負載均衡
worker 間的負載關鍵在於各自接入了多少連接,其中接入連接搶鎖的前置條件是ngx_accept_disabled > 0
,所以ngx_accept_disabled
就是負載均衡機制實現的關鍵閾值。
ngx_int_t ngx_accept_disabled;
ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n;
因此,在 nginx 啓動時,ngx_accept_disabled
的值就是一個負數,其值爲連接總數的 7/8。當該進程的連接數達到總連接數的 7/8 時,該進程就不會再處理新的連接了,同時每次調用'ngx_process_events_and_timers'時,將ngx_accept_disabled
減 1,直到其值低於閾值時,才試圖重新處理新的連接。因此,nginx 各 worker 子進程間的負載均衡僅在某個 worker 進程處理的連接數達到它最大處理總數的 7/8 時纔會觸發,其負載均衡並不是在任意條件都滿足。如下圖所示:
實際工作情況
其中'pid'爲 1211 的進程爲 master 進程,其餘爲 worker 進程
4. 思考
4.1 爲什麼不採用多線程模型管理連接?
-
- 無狀態服務,無需共享進程內存
-
- 採用獨立的進程,可以讓互相之間不會影響。一個進程異常崩潰,其他進程的服務不會中斷,提升了架構的可靠性。
-
- 進程之間不共享資源,不需要加鎖,所以省掉了鎖帶來的開銷。
4.2 爲什麼不採用多線程處理邏輯業務?
-
- 進程數已經等於核心數,再新建線程處理任務,只會搶佔現有進程,增加切換代價。
-
- 作爲接入層,基本上都是數據轉發業務,網絡 IO 任務的等待耗時部分,已經被處理爲非阻塞 / 全異步 / 事件驅動模式,在沒有更多 CPU 的情況下,再利用多線程處理,意義不大。並且如果進程中有阻塞的處理邏輯,應該由各個業務進行解決,比如 openResty 中利用了 Lua 協程,對阻塞業務進行了優化。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/fH8vefmJK4czpQ8dESV-rA