讓我一起淺析Nginx 架構(gòu)
1.Nginx 基礎(chǔ)架構(gòu)
nginx 啟動(dòng)后以 daemon 形式在后臺(tái)運(yùn)行,后臺(tái)進(jìn)程包含一個(gè) master 進(jìn)程和多個(gè) worker 進(jìn)程。如下圖所示:
master與worker
nginx 是由一個(gè) master 管理進(jìn)程,多個(gè) worker 進(jìn)程處理工作的多進(jìn)程模型。基礎(chǔ)架構(gòu)設(shè)計(jì),如下圖所示:
基礎(chǔ)架構(gòu)設(shè)計(jì)
master 負(fù)責(zé)管理 worker 進(jìn)程,worker 進(jìn)程負(fù)責(zé)處理網(wǎng)絡(luò)事件。整個(gè)框架被設(shè)計(jì)為一種依賴事件驅(qū)動(dòng)、異步、非阻塞的模式。
如此設(shè)計(jì)的優(yōu)點(diǎn):
- 1.可以充分利用多核機(jī)器,增強(qiáng)并發(fā)處理能力。
- 2.多 worker 間可以實(shí)現(xiàn)負(fù)載均衡。
- 3.Master 監(jiān)控并統(tǒng)一管理 worker 行為。在 worker 異常后,可以主動(dòng)拉起 worker 進(jìn)程,從而提升了系統(tǒng)的可靠性。并且由 Master 進(jìn)程控制服務(wù)運(yùn)行中的程序升級(jí)、配置項(xiàng)修改等操作,從而增強(qiáng)了整體的動(dòng)態(tài)可擴(kuò)展與熱更的能力。
2.Master 進(jìn)程
2.1 核心邏輯
master 進(jìn)程的主邏輯在ngx_master_process_cycle,核心關(guān)注源碼:
- 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 進(jìn)程主要用來(lái)管理 worker 進(jìn)程,具體包括如下 4 個(gè)主要功能:
1.接受來(lái)自外界的信號(hào)。其中 master 循環(huán)中的各項(xiàng)標(biāo)志位就對(duì)應(yīng)著各種信號(hào),如:ngx_quit代表QUIT信號(hào),表示優(yōu)雅的關(guān)閉整個(gè)服務(wù)。
2.向各個(gè) worker 進(jìn)程發(fā)送信。比如ngx_noaccept代表WINCH信號(hào),表示所有子進(jìn)程不再接受處理新的連接,由 master 向所有的子進(jìn)程發(fā)送 QUIT 信號(hào)量。
3.監(jiān)控 worker 進(jìn)程的運(yùn)行狀態(tài)。比如ngx_reap代表CHILD信號(hào),表示有子進(jìn)程意外結(jié)束,這時(shí)需要監(jiān)控所有子進(jìn)程的運(yùn)行狀態(tài),主要由ngx_reap_children完成。
4.當(dāng) woker 進(jìn)程退出后(異常情況下),會(huì)自動(dòng)重新啟動(dòng)新的 woker 進(jìn)程。主要也是在ngx_reap_children
2.2 熱更
2.2.1 熱重載-配置熱更
熱重載
nginx 熱更配置時(shí),可以保持運(yùn)行中平滑更新配置,具體流程如下:
- 1.更新 nginx.conf 配置文件,向 master 發(fā)送 SIGHUP 信號(hào)或執(zhí)行 nginx -s reload
- 2.master 進(jìn)程使用新配置,啟動(dòng)新的 worker 進(jìn)程
- 3.使用舊配置的 worker 進(jìn)程,不再接受新的連接請(qǐng)求,并在完成已存在的連接后退出
2.2.2 熱升級(jí)-程序熱更
熱升級(jí)
nginx 熱升級(jí)過(guò)程如下:
1.將舊 Nginx 文件換成新 Nginx 文件(注意備份)
2.向 master 進(jìn)程發(fā)送 USR2 信號(hào)(平滑升級(jí)到新版本的 Nginx 程序)
3.master 進(jìn)程修改 pid 文件號(hào),加后綴.oldbin
4.master 進(jìn)程用新 Nginx 文件啟動(dòng)新 master 進(jìn)程,此時(shí)新老 master/worker 同時(shí)存在。
5.向老 master 發(fā)送 WINCH 信號(hào),關(guān)閉舊 worker 進(jìn)程,觀察新 worker 進(jìn)程工作情況。若升級(jí)成功,則向老 master 進(jìn)程發(fā)送 QUIT 信號(hào),關(guān)閉老 master 進(jìn)程;若升級(jí)失敗,則需要回滾,向老 master 發(fā)送 HUP 信號(hào)(重讀配置文件),向新 master 發(fā)送 QUIT 信號(hào),關(guān)閉新 master 及 worker。
3.Worker 進(jìn)程
3.1 核心邏輯
worker 進(jìn)程的主邏輯在ngx_worker_process_cycle,核心關(guān)注源碼:
- 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 進(jìn)程主要在處理網(wǎng)絡(luò)事件,通過(guò)ngx_process_events_and_timers方法實(shí)現(xiàn),其中事件主要包括:網(wǎng)絡(luò)事件、定時(shí)器事件。
3.2 事件驅(qū)動(dòng)-epoll
worker 進(jìn)程在處理網(wǎng)絡(luò)事件時(shí),依靠 epoll 模型,來(lái)管理并發(fā)連接,實(shí)現(xiàn)了事件驅(qū)動(dòng)、異步、非阻塞等特性。如下圖所示:
infographic-Inside-NGINX_nonblocking
通常海量并發(fā)連接過(guò)程中,每一時(shí)刻(相對(duì)較短的一段時(shí)間),往往只需要處理一小部分有事件的連接即活躍連接?;谝陨犀F(xiàn)象,epoll 通過(guò)將連接管理與活躍連接管理進(jìn)行分離,實(shí)現(xiàn)了高效、穩(wěn)定的網(wǎng)絡(luò) IO 處理能力。
網(wǎng)絡(luò)模型對(duì)比
其中,epoll 利用紅黑樹(shù)高效的增刪查效率來(lái)管理連接,利用一個(gè)雙向鏈表來(lái)維護(hù)活躍連接。
epoll數(shù)據(jù)結(jié)構(gòu)
3.3 驚群
由于 worker 都是由 master 進(jìn)程 fork 產(chǎn)生,所以 worker 都會(huì)監(jiān)聽(tīng)相同端口。這樣多個(gè)子進(jìn)程在 accept 建立連接時(shí)會(huì)發(fā)生爭(zhēng)搶,帶來(lái)著名的“驚群”問(wèn)題。worker 核心處理邏輯ngx_process_events_and_timers核心代碼如下:
- void ngx_process_events_and_timers(ngx_cycle_t *cycle){
- //這里面會(huì)對(duì)監(jiān)聽(tīng)socket處理
- ...
- if (ngx_accept_disabled > 0) {
- ngx_accept_disabled--;
- } else {
- //獲得鎖則加入wait集合,
- if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
- return;
- }
- ...
- //設(shè)置網(wǎng)絡(luò)讀寫(xiě)事件延遲處理標(biāo)志,即在釋放鎖后處理
- if (ngx_accept_mutex_held) {
- flags |= NGX_POST_EVENTS;
- }
- }
- ...
- //這里面epollwait等待網(wǎng)絡(luò)事件
- //網(wǎng)絡(luò)連接事件,放入ngx_posted_accept_events隊(duì)列
- //網(wǎng)絡(luò)讀寫(xiě)事件,放入ngx_posted_events隊(duì)列
- (void) ngx_process_events(cycle, timer, flags);
- ...
- //先處理網(wǎng)絡(luò)連接事件,只有獲取到鎖,這里才會(huì)有連接事件
- ngx_event_process_posted(cycle, &ngx_posted_accept_events);
- //釋放鎖,讓其他進(jìn)程也能夠拿到
- if (ngx_accept_mutex_held) {
- ngx_shmtx_unlock(&ngx_accept_mutex);
- }
- //處理網(wǎng)絡(luò)讀寫(xiě)事件
- ngx_event_process_posted(cycle, &ngx_posted_events);
- }
由上述代碼可知,Nginx 解決驚群的方法:
1.將連接事件與讀寫(xiě)事件進(jìn)行分離。連接事件存放為ngx_posted_accept_events,讀寫(xiě)事件存放為ngx_posted_events。
2.設(shè)置ngx_accept_mutex鎖,只有獲得鎖的進(jìn)程,才可以處理連接事件。
3.4 負(fù)載均衡
worker 間的負(fù)載關(guān)鍵在于各自接入了多少連接,其中接入連接搶鎖的前置條件是ngx_accept_disabled > 0,所以ngx_accept_disabled就是負(fù)載均衡機(jī)制實(shí)現(xiàn)的關(guān)鍵閾值。
- ngx_int_t ngx_accept_disabled;
- ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n;
因此,在 nginx 啟動(dòng)時(shí),ngx_accept_disabled的值就是一個(gè)負(fù)數(shù),其值為連接總數(shù)的 7/8。當(dāng)該進(jìn)程的連接數(shù)達(dá)到總連接數(shù)的 7/8 時(shí),該進(jìn)程就不會(huì)再處理新的連接了,同時(shí)每次調(diào)用'ngx_process_events_and_timers'時(shí),將ngx_accept_disabled減 1,直到其值低于閾值時(shí),才試圖重新處理新的連接。因此,nginx 各 worker 子進(jìn)程間的負(fù)載均衡僅在某個(gè) worker 進(jìn)程處理的連接數(shù)達(dá)到它最大處理總數(shù)的 7/8 時(shí)才會(huì)觸發(fā),其負(fù)載均衡并不是在任意條件都滿足。如下圖所示:
實(shí)際工作情況
其中'pid'為 1211 的進(jìn)程為 master 進(jìn)程,其余為 worker 進(jìn)程
4.思考
4.1 為什么不采用多線程模型管理連接?
1.無(wú)狀態(tài)服務(wù),無(wú)需共享進(jìn)程內(nèi)存
2.采用獨(dú)立的進(jìn)程,可以讓互相之間不會(huì)影響。一個(gè)進(jìn)程異常崩潰,其他進(jìn)程的服務(wù)不會(huì)中斷,提升了架構(gòu)的可靠性。
3.進(jìn)程之間不共享資源,不需要加鎖,所以省掉了鎖帶來(lái)的開(kāi)銷。
4.2 為什么不采用多線程處理邏輯業(yè)務(wù)?
1.進(jìn)程數(shù)已經(jīng)等于核心數(shù),再新建線程處理任務(wù),只會(huì)搶占現(xiàn)有進(jìn)程,增加切換代價(jià)。
2.作為接入層,基本上都是數(shù)據(jù)轉(zhuǎn)發(fā)業(yè)務(wù),網(wǎng)絡(luò) IO 任務(wù)的等待耗時(shí)部分,已經(jīng)被處理為非阻塞/全異步/事件驅(qū)動(dòng)模式,在沒(méi)有更多 CPU 的情況下,再利用多線程處理,意義不大。并且如果進(jìn)程中有阻塞的處理邏輯,應(yīng)該由各個(gè)業(yè)務(wù)進(jìn)行解決,比如 openResty 中利用了 Lua 協(xié)程,對(duì)阻塞業(yè)務(wù)進(jìn)行了優(yōu)化。