[[392641]]

1.Nginx 基礎(chǔ)架構(gòu)

nginx 啟動后以 daemon 形式在后臺運行，后臺進(jìn)程包含一個 master 進(jìn)程和多個 worker 進(jìn)程。如下圖所示：

成都創(chuàng)新互聯(lián)公司為企業(yè)級客戶提高一站式互聯(lián)網(wǎng)+設(shè)計服務(wù)，主要包括成都網(wǎng)站制作、成都網(wǎng)站設(shè)計、外貿(mào)營銷網(wǎng)站建設(shè)、重慶APP開發(fā)公司、微信小程序、宣傳片制作、LOGO設(shè)計等，幫助客戶快速提升營銷能力和企業(yè)形象，創(chuàng)新互聯(lián)各部門都有經(jīng)驗豐富的經(jīng)驗，可以確保每一個作品的質(zhì)量和創(chuàng)作周期，同時每年都有很多新員工加入，為我們帶來大量新的創(chuàng)意。 

master與worker

nginx 是由一個 master 管理進(jìn)程，多個 worker 進(jìn)程處理工作的多進(jìn)程模型?；A(chǔ)架構(gòu)設(shè)計，如下圖所示：

基礎(chǔ)架構(gòu)設(shè)計

master 負(fù)責(zé)管理 worker 進(jìn)程，worker 進(jìn)程負(fù)責(zé)處理網(wǎng)絡(luò)事件。整個框架被設(shè)計為一種依賴事件驅(qū)動、異步、非阻塞的模式。

如此設(shè)計的優(yōu)點：

• 1.可以充分利用多核機(jī)器，增強(qiáng)并發(fā)處理能力。
• 2.多 worker 間可以實現(xiàn)負(fù)載均衡。
• 3.Master 監(jiān)控并統(tǒng)一管理 worker 行為。在 worker 異常后，可以主動拉起 worker 進(jìn)程，從而提升了系統(tǒng)的可靠性。并且由 Master 進(jìn)程控制服務(wù)運行中的程序升級、配置項修改等操作，從而增強(qiá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)程主要用來管理 worker 進(jìn)程，具體包括如下 4 個主要功能：

1.接受來自外界的信號。其中 master 循環(huán)中的各項標(biāo)志位就對應(yīng)著各種信號，如：ngx_quit代表QUIT信號，表示優(yōu)雅的關(guān)閉整個服務(wù)。

2.向各個 worker 進(jìn)程發(fā)送信。比如ngx_noaccept代表WINCH信號，表示所有子進(jìn)程不再接受處理新的連接，由 master 向所有的子進(jìn)程發(fā)送 QUIT 信號量。

3.監(jiān)控 worker 進(jìn)程的運行狀態(tài)。比如ngx_reap代表CHILD信號，表示有子進(jìn)程意外結(jié)束，這時需要監(jiān)控所有子進(jìn)程的運行狀態(tài)，主要由ngx_reap_children完成。

4.當(dāng) woker 進(jìn)程退出后(異常情況下)，會自動重新啟動新的 woker 進(jìn)程。主要也是在ngx_reap_children

2.2 熱更

2.2.1 熱重載-配置熱更

熱重載

nginx 熱更配置時，可以保持運行中平滑更新配置，具體流程如下：

• 1.更新 nginx.conf 配置文件，向 master 發(fā)送 SIGHUP 信號或執(zhí)行 nginx -s reload
• 2.master 進(jìn)程使用新配置，啟動新的 worker 進(jìn)程
• 3.使用舊配置的 worker 進(jìn)程，不再接受新的連接請求，并在完成已存在的連接后退出

2.2.2 熱升級-程序熱更

熱升級

nginx 熱升級過程如下：

1.將舊 Nginx 文件換成新 Nginx 文件(注意備份)

2.向 master 進(jìn)程發(fā)送 USR2 信號(平滑升級到新版本的 Nginx 程序)

3.master 進(jìn)程修改 pid 文件號，加后綴.oldbin

4.master 進(jìn)程用新 Nginx 文件啟動新 master 進(jìn)程，此時新老 master/worker 同時存在。

5.向老 master 發(fā)送 WINCH 信號，關(guān)閉舊 worker 進(jìn)程，觀察新 worker 進(jìn)程工作情況。若升級成功，則向老 master 進(jìn)程發(fā)送 QUIT 信號，關(guān)閉老 master 進(jìn)程;若升級失敗，則需要回滾，向老 master 發(fā)送 HUP 信號(重讀配置文件)，向新 master 發(fā)送 QUIT 信號，關(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ò)事件，通過ngx_process_events_and_timers方法實現(xiàn)，其中事件主要包括：網(wǎng)絡(luò)事件、定時器事件。

3.2 事件驅(qū)動-epoll

worker 進(jìn)程在處理網(wǎng)絡(luò)事件時，依靠 epoll 模型，來管理并發(fā)連接，實現(xiàn)了事件驅(qū)動、異步、非阻塞等特性。如下圖所示：

infographic-Inside-NGINX_nonblocking

通常海量并發(fā)連接過程中，每一時刻(相對較短的一段時間)，往往只需要處理一小部分有事件的連接即活躍連接。基于以上現(xiàn)象，epoll 通過將連接管理與活躍連接管理進(jìn)行分離，實現(xiàn)了高效、穩(wěn)定的網(wǎng)絡(luò) IO 處理能力。

網(wǎng)絡(luò)模型對比

其中，epoll 利用紅黑樹高效的增刪查效率來管理連接，利用一個雙向鏈表來維護(hù)活躍連接。

epoll數(shù)據(jù)結(jié)構(gòu)

3.3 驚群

由于 worker 都是由 master 進(jìn)程 fork 產(chǎn)生，所以 worker 都會監(jiān)聽相同端口。這樣多個子進(jìn)程在 accept 建立連接時會發(fā)生爭搶，帶來著名的“驚群”問題。worker 核心處理邏輯ngx_process_events_and_timers核心代碼如下：

 
 
 
 
  
  
  
  
void ngx_process_events_and_timers(ngx_cycle_t *cycle){ 
  
  
  
  
    //這里面會對監(jiān)聽socket處理 
  
  
  
  
    ... 
  
  
  
  
 
  
  
  
  
    if (ngx_accept_disabled > 0) { 
  
  
  
  
            ngx_accept_disabled--; 
  
  
  
  
    } else { 
  
  
  
  
        //獲得鎖則加入wait集合, 
  
  
  
  
        if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) { 
  
  
  
  
            return; 
  
  
  
  
        } 
  
  
  
  
        ... 
  
  
  
  
        //設(shè)置網(wǎng)絡(luò)讀寫事件延遲處理標(biāo)志，即在釋放鎖后處理 
  
  
  
  
        if (ngx_accept_mutex_held) { 
  
  
  
  
            flags |= NGX_POST_EVENTS; 
  
  
  
  
        } 
  
  
  
  
    } 
  
  
  
  
    ... 
  
  
  
  
    //這里面epollwait等待網(wǎng)絡(luò)事件 
  
  
  
  
    //網(wǎng)絡(luò)連接事件，放入ngx_posted_accept_events隊列 
  
  
  
  
    //網(wǎng)絡(luò)讀寫事件，放入ngx_posted_events隊列 
  
  
  
  
    (void) ngx_process_events(cycle, timer, flags); 
  
  
  
  
    ... 
  
  
  
  
    //先處理網(wǎng)絡(luò)連接事件，只有獲取到鎖，這里才會有連接事件 
  
  
  
  
    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ò)讀寫事件 
  
  
  
  
    ngx_event_process_posted(cycle, &ngx_posted_events); 
  
  
  
  
} 
 
 
 

由上述代碼可知，Nginx 解決驚群的方法：

1.將連接事件與讀寫事件進(jìn)行分離。連接事件存放為ngx_posted_accept_events，讀寫事件存放為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ī)制實現(xiàn)的關(guān)鍵閾值。

 
 
 
 
  
  
  
  
ngx_int_t             ngx_accept_disabled; 
  
  
  
  
ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n; 
 
 
 

因此，在 nginx 啟動時，ngx_accept_disabled的值就是一個負(fù)數(shù)，其值為連接總數(shù)的 7/8。當(dāng)該進(jìn)程的連接數(shù)達(dá)到總連接數(shù)的 7/8 時，該進(jìn)程就不會再處理新的連接了，同時每次調(diào)用'ngx_process_events_and_timers'時，將ngx_accept_disabled減 1，直到其值低于閾值時，才試圖重新處理新的連接。因此，nginx 各 worker 子進(jìn)程間的負(fù)載均衡僅在某個 worker 進(jìn)程處理的連接數(shù)達(dá)到它最大處理總數(shù)的 7/8 時才會觸發(fā)，其負(fù)載均衡并不是在任意條件都滿足。如下圖所示：

實際工作情況

其中'pid'為 1211 的進(jìn)程為 master 進(jìn)程，其余為 worker 進(jìn)程

4.思考

4.1 為什么不采用多線程模型管理連接?

1.無狀態(tài)服務(wù)，無需共享進(jìn)程內(nèi)存

2.采用獨立的進(jìn)程，可以讓互相之間不會影響。一個進(jìn)程異常崩潰，其他進(jìn)程的服務(wù)不會中斷，提升了架構(gòu)的可靠性。

3.進(jìn)程之間不共享資源，不需要加鎖，所以省掉了鎖帶來的開銷。

4.2 為什么不采用多線程處理邏輯業(yè)務(wù)?

1.進(jìn)程數(shù)已經(jīng)等于核心數(shù)，再新建線程處理任務(wù)，只會搶占現(xiàn)有進(jìn)程，增加切換代價。

2.作為接入層，基本上都是數(shù)據(jù)轉(zhuǎn)發(fā)業(yè)務(wù)，網(wǎng)絡(luò) IO 任務(wù)的等待耗時部分，已經(jīng)被處理為非阻塞/全異步/事件驅(qū)動模式，在沒有更多 CPU 的情況下，再利用多線程處理，意義不大。并且如果進(jìn)程中有阻塞的處理邏輯，應(yīng)該由各個業(yè)務(wù)進(jìn)行解決，比如 openResty 中利用了 Lua 協(xié)程，對阻塞業(yè)務(wù)進(jìn)行了優(yōu)化。

網(wǎng)站標(biāo)題：讓我一起淺析Nginx 架構(gòu)
文章轉(zhuǎn)載：http://uogjgqi.cn/article/cdigpso.html