建站
咨詢
售后
建站咨詢
新聞中心
圖片來自包圖網(wǎng)
成都網(wǎng)站建設(shè)、成都做網(wǎng)站的關(guān)注點不是能為您做些什么網(wǎng)站，而是怎么做網(wǎng)站，有沒有做好網(wǎng)站，給創(chuàng)新互聯(lián)公司一個展示的機會來證明自己，這并不會花費您太多時間，或許會給您帶來新的靈感和驚喜。面向用戶友好，注重用戶體驗，一切以用戶為中心。
Nginx 基礎(chǔ)架構(gòu)
Nginx 啟動后以 daemon 形式在后臺運行，后臺進程包含一個 master 進程和多個 worker 進程。
如下圖所示：
master 與 worker
Nginx 是由一個 master 管理進程，多個 worker 進程處理工作的多進程模型。
基礎(chǔ)架構(gòu)設(shè)計，如下圖所示：
基礎(chǔ)架構(gòu)設(shè)計
master 負責管理 worker 進程，worker 進程負責處理網(wǎng)絡(luò)事件。整個框架被設(shè)計為一種依賴事件驅(qū)動、異步、非阻塞的模式。
如此設(shè)計的優(yōu)點：
- 可以充分利用多核機器，增強并發(fā)處理能力。
- 多 worker 間可以實現(xiàn)負載均衡。
- Master 監(jiān)控并統(tǒng)一管理 worker 行為。在 worker 異常后，可以主動拉起 worker 進程，從而提升了系統(tǒng)的可靠性。
并且由 Master 進程控制服務(wù)運行中的程序升級、配置項修改等操作，從而增強了整體的動態(tài)可擴展與熱更的能力。
Master 進程
①核心邏輯
master 進程的主邏輯在 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 進程主要用來管理 worker 進程，具體包括如下 4 個主要功能：
- 接受來自外界的信號。其中 master 循環(huán)中的各項標志位就對應(yīng)著各種信號，如：ngx_quit 代表 QUIT 信號，表示優(yōu)雅的關(guān)閉整個服務(wù)。
- 向各個 worker 進程發(fā)送信。比如 ngx_noaccept 代表 WINCH 信號，表示所有子進程不再接受處理新的連接，由 master 向所有的子進程發(fā)送 QUIT 信號量。
- 監(jiān)控 worker 進程的運行狀態(tài)。比如 ngx_reap 代表 CHILD 信號，表示有子進程意外結(jié)束，這時需要監(jiān)控所有子進程的運行狀態(tài)，主要由 ngx_reap_children 完成。
- 當 woker 進程退出后(異常情況下)，會自動重新啟動新的 woker 進程。主要也是在 ngx_reap_children。
②熱更
熱重載-配置熱更：
熱重載
- Nginx 熱更配置時，可以保持運行中平滑更新配置，具體流程如下：
- 更新 nginx.conf 配置文件，向 master 發(fā)送 SIGHUP 信號或執(zhí)行 nginx -s reload
- master 進程使用新配置，啟動新的 worker 進程
使用舊配置的 worker 進程，不再接受新的連接請求，并在完成已存在的連接后退出
熱升級-程序熱更：
熱升級
Nginx 熱升級過程如下：
- 將舊 Nginx 文件換成新 Nginx 文件(注意備份)
- 向 master 進程發(fā)送 USR2 信號(平滑升級到新版本的 Nginx 程序)
- master 進程修改 pid 文件號，加后綴 .oldbin
- master 進程用新 Nginx 文件啟動新 master 進程，此時新老 master/worker 同時存在。
- 向老 master 發(fā)送 WINCH 信號，關(guān)閉舊 worker 進程，觀察新 worker 進程工作情況。
若升級成功，則向老 master 進程發(fā)送 QUIT 信號，關(guān)閉老 master 進程;若升級失敗，則需要回滾，向老 master 發(fā)送 HUP 信號(重讀配置文件)，向新 master 發(fā)送 QUIT 信號，關(guān)閉新 master 及 worker。
Worker 進程
①核心邏輯
worker 進程的主邏輯在 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 進程主要在處理網(wǎng)絡(luò)事件，通過 ngx_process_events_and_timers 方法實現(xiàn)，其中事件主要包括：網(wǎng)絡(luò)事件、定時器事件。
②事件驅(qū)動-epoll
worker 進程在處理網(wǎng)絡(luò)事件時，依靠 epoll 模型，來管理并發(fā)連接，實現(xiàn)了事件驅(qū)動、異步、非阻塞等特性。
如下圖所示：
圖
infographic-Inside-NGINX_nonblocking
通常海量并發(fā)連接過程中，每一時刻(相對較短的一段時間)，往往只需要處理一小部分有事件的連接即活躍連接。
基于以上現(xiàn)象，epoll 通過將連接管理與活躍連接管理進行分離，實現(xiàn)了高效、穩(wěn)定的網(wǎng)絡(luò) IO 處理能力。
網(wǎng)絡(luò)模型對比
其中，epoll 利用紅黑樹高效的增刪查效率來管理連接，利用一個雙向鏈表來維護活躍連接。
epoll 數(shù)據(jù)結(jié)構(gòu)
③驚群
由于 worker 都是由 master 進程 fork 產(chǎn)生，所以 worker 都會監(jiā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ò)讀寫事件延遲處理標志，即在釋放鎖后處理
- 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);
- //釋放鎖，讓其他進程也能夠拿到
- if (ngx_accept_mutex_held) {
- ngx_shmtx_unlock(&ngx_accept_mutex);
- }
- //處理網(wǎng)絡(luò)讀寫事件
- ngx_event_process_posted(cycle, &ngx_posted_events);
- }
由上述代碼可知，Nginx 解決驚群的方法：
- 將連接事件與讀寫事件進行分離。連接事件存放為 ngx_posted_accept_events，讀寫事件存放為 ngx_posted_events。
- 設(shè)置 ngx_accept_mutex 鎖，只有獲得鎖的進程，才可以處理連接事件。
④負載均衡
worker 間的負載關(guān)鍵在于各自接入了多少連接，其中接入連接搶鎖的前置條件是 ngx_accept_disabled > 0，所以 ngx_accept_disabled 就是負載均衡機制實現(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 的值就是一個負數(shù)，其值為連接總數(shù)的 7/8。
當該進程的連接數(shù)達到總連接數(shù)的 7/8 時，該進程就不會再處理新的連接了。
同時每次調(diào)用'ngx_process_events_and_timers'時，將 ngx_accept_disabled 減 1，直到其值低于閾值時，才試圖重新處理新的連接。
因此，Nginx 各 worker 子進程間的負載均衡僅在某個 worker 進程處理的連接數(shù)達到它最大處理總數(shù)的 7/8 時才會觸發(fā)，其負載均衡并不是在任意條件都滿足。
如下圖所示：
實際工作情況
其中'pid'為 1211 的進程為 master 進程，其余為 worker 進程。
思考
為什么不采用多線程模型管理連接?
①無狀態(tài)服務(wù)，無需共享進程內(nèi)存。
②采用獨立的進程，可以讓互相之間不會影響。一個進程異常崩潰，其他進程的服務(wù)不會中斷，提升了架構(gòu)的可靠性。
③進程之間不共享資源，不需要加鎖，所以省掉了鎖帶來的開銷。
為什么不采用多線程處理邏輯業(yè)務(wù)?
①進程數(shù)已經(jīng)等于核心數(shù)，再新建線程處理任務(wù)，只會搶占現(xiàn)有進程，增加切換代價。
②作為接入層，基本上都是數(shù)據(jù)轉(zhuǎn)發(fā)業(yè)務(wù)，網(wǎng)絡(luò) IO 任務(wù)的等待耗時部分，已經(jīng)被處理為非阻塞/全異步/事件驅(qū)動模式，在沒有更多 CPU 的情況下，再利用多線程處理，意義不大。
并且如果進程中有阻塞的處理邏輯，應(yīng)該由各個業(yè)務(wù)進行解決，比如 OpenResty 中利用了 Lua 協(xié)程，對阻塞業(yè)務(wù)進行了優(yōu)化。
作者：handsomeli，騰訊 IEG 后臺開發(fā)工程師
編輯：陶家龍
出處：轉(zhuǎn)載自公眾號騰訊技術(shù)工程(ID：Tencent_TEG)
標題名稱：Nginx，永遠滴神！
轉(zhuǎn)載來于：http://m.fisionsoft.com.cn/article/djdipcs.html
