一、Nginx基礎架構
Nginx啟動后以daemon形式在后台運行，后台進程包含一個master進程和多個worker進程。如下圖所示：
Nginx是由一個master管理進程，多個worker進程處理工作的多進程模型。基礎架構設計，如下圖所示：
Master負責管理worker進程，worker進程負責處理網絡事件。整個框架被設計為一種依賴事件驅動、異步、非阻塞的模式。
如此設計的優點有：
-
可以充分利用多核機器，增強並發處理能力。
-
多worker間可以實現負載均衡。
-
Master監控並統一管理worker行為。在worker異常后，可以主動拉起worker進程，從而提升了系統的可靠性。並且由Master進程控制服務運行中的程序升級、配置項修改等操作，從而增強了整體的動態可擴展與熱更的能力。
二、Master進程
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_debug(NGX_LOG_DEBUG_EVENT, cycle->log, , "sigsuspend"); sigsuspend(&set);
ngx_time_update();
ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, , "wake up, sigio %i", sigio);
if (ngx_reap) { ngx_reap = ; ngx_log_debug(NGX_LOG_DEBUG_EVENT, cycle->log, , "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 = ; ngx_noaccepting = 1; ngx_signal_worker_processes(cycle,
ngx_signal_value(NGX_SHUTDOWN_SIGNAL)); } } }
由上述代碼，可以理解，master進程主要用來管理worker進程，具體包括如下4個主要功能：
1）接受來自外界的信號。其中master循環中的各項標志位就對應着各種信號，如：ngx_quit代表QUIT信號，表示優雅的關閉整個服務。
2）向各個worker進程發送信。比如ngx_noaccept代表WINCH信號，表示所有子進程不再接受處理新的連接，由master向所有的子進程發送QUIT信號量。
3）監控worker進程的運行狀態。比如ngx_reap代表CHILD信號，表示有子進程意外結束，這時需要監控所有子進程的運行狀態，主要由ngx_reap_children完成。
4）當woker進程退出后（異常情況下），會自動重新啟動新的woker進程。主要也是在ngx_reap_children。
2. 熱更
1）熱重載-配置熱更
Nginx熱更配置時，可以保持運行中平滑更新配置，具體流程如下：
- 更新nginx.conf配置文件，向master發送SIGHUP信號或執行nginx -s reload
- Master進程使用新配置，啟動新的worker進程
-
使用舊配置的worker進程，不再接受新的連接請求，並在完成已存在的連接后退出
2）熱升級-程序熱更
Nginx熱升級過程如下：
- 將舊Nginx文件換成新Nginx文件（注意備份）
- 向master進程發送USR2信號（平滑升級到新版本的Nginx程序）
- master進程修改pid文件號，加后綴.oldbin
- master進程用新Nginx文件啟動新master進程，此時新老master/worker同時存在。
-
向老master發送WINCH信號，關閉舊worker進程，觀察新worker進程工作情況。若升級成功，則向老master進程發送QUIT信號，關閉老master進程；若升級失敗，則需要回滾，向老master發送HUP信號（重讀配置文件），向新master發送QUIT信號，關閉新master及worker。
三、Worker進程
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_debug(NGX_LOG_DEBUG_EVENT, cycle->log, , "worker cycle");
ngx_process_events_and_timers(cycle);
if (ngx_terminate) {...}
if (ngx_quit) {...}
if (ngx_reopen) {...} }}
由上述代碼，可以理解，worker進程主要在處理網絡事件，通過ngx_process_events_and_timers方法實現，其中事件主要包括：網絡事件、定時器事件。
2. 事件驅動-epoll
Worker進程在處理網絡事件時，依靠epoll模型，來管理並發連接，實現了事件驅動、異步、非阻塞等特性。如下圖所示：
通常海量並發連接過程中，每一時刻（相對較短的一段時間），往往只需要處理一小部分有事件的連接即活躍連接。基於以上現象，epoll通過將連接管理與活躍連接管理進行分離，實現了QQ賬號轉讓地圖高效、穩定的網絡IO處理能力。
其中，epoll利用紅黑樹高效的增刪查效率來管理連接，利用一個雙向鏈表來維護活躍連接。
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 > ) { 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解決驚群的方法：
1）將連接事件與讀寫事件進行分離。連接事件存放為ngx_posted_accept_events，讀寫事件存放為ngx_posted_events。
2）設置ngx_accept_mutex鎖，只有獲得鎖的進程，才可以處理連接事件。
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進程。
四、思考
1. 為什么不采用多線程模型管理連接？
- 無狀態服務，無需共享進程內存
- 采用獨立的進程，可以讓互相之間不會影響。一個進程異常崩潰，其他進程的服務不會中斷，提升了架構的可靠性。
-
進程之間不共享資源，不需要加鎖，所以省掉了鎖帶來的開銷。
2. 為什么不采用多線程處理邏輯業務？
- 進程數已經等於核心數，再新建線程處理任務，只會搶占現有進程，增加切換代價。
-
作為接入層，基本上都是數據轉發業務，網絡IO任務的等待耗時部分，已經被處理為非阻塞/全異步/事件驅動模式，在沒有更多CPU的情況下，再利用多線程處理，意義不大。並且如果進程中有阻塞的處理邏輯，應該由各個業務進行解決，比如openResty中利用了Lua協程，對阻塞業務進行了優化。