進程結構圖

Nginx 是多進程結構，多進程結構設計是為了保證 Nginx 的高可用高可靠，包含：

master 進程：父進程，負責 worker 進程的管理

worker 進程：子進程，worker 進程一般配置與服務器 CPU 核數相同，worker 進程用來處理具體請求。

cache 進程：也是子進程，包括 cache manager 和 cache loader 進程，主要是反向代理做緩存使用。

注：多進程相對于多線程之所以能夠保證高可用與高可靠是因為進程間地址空間是獨立的，進程間的任務不會相互影響，相對多線程更加耗費 CPU 資源。而多線程共享一個進程的地址空間，其中一個線程任務失敗會影響到其它線程任務。

假設我們的 Nginx 服務的用戶是 nginx，我們可以使用如下命令查看當前運行的 Nginx 服務的 master 進程和 worker 進程，而且可以看到 4 個 worker 進程的父進程 ID 都是 master 的進程 ID(1325)。

[root@master ~]# ps -ef | grep nginx | grep -v grep | grep -v php-fpm
root       1325      1  0 11:28 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx      1332   1325  0 11:28 ?        00:00:00 nginx: worker process
nginx      1334   1325  0 11:28 ?        00:00:00 nginx: worker process
nginx      1335   1325  0 11:28 ?        00:00:00 nginx: worker process
nginx      1336   1325  0 11:28 ?        00:00:00 nginx: worker process

我們可以通過 lsof -i:nginx 端口號 來查看我們的 master 和 worker 進程。

[root@master ~]# lsof -i:80
COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
nginx   1325  root    6u  IPv4  22282      0t0  TCP *:http (LISTEN)
nginx   1332 nginx    6u  IPv4  22282      0t0  TCP *:http (LISTEN)
nginx   1334 nginx    6u  IPv4  22282      0t0  TCP *:http (LISTEN)
nginx   1335 nginx    6u  IPv4  22282      0t0  TCP *:http (LISTEN)
nginx   1336 nginx    6u  IPv4  22282      0t0  TCP *:http (LISTEN)

利用信號量管理 Nginx 進程

管理 Nginx 進程可以這些方式：master 進程、worker 進程、命令行

使用信號量管理 master 和 worker(不推薦使用發送信號量的方式來管理 worker 進程，worker 進程應該交給 master 進程來管理和維護)。

Master 進程

監控 worker 進程 CHLD

管理 worker 進程

接收信號 TERM、INTQUITHUPUSR1USR2WINCH

示例：

通過 kill 命令殺死 master 進程

kill -s SIGTERM 1325

通過 kill 命令讓 Nginx 重新讀取文件，這樣會關閉就得 worker 進程，生成新的 worker 進程，master 進程(ID)依舊保持不變

kill -s SIGHUP 1325

Worker 進程

接收信號 TERM、INTQUITUSR1WINCH

雖然可以，但是不推薦使用信號量方式直接管理 worker 進程，worker 進程應該交給 master 進程來管理和維護

示例：

使用 kill 命令殺死一個 worker 進程，這樣會殺死一個 worker 進程，linux 會殺掉的 worker 進程的父進程(master 進程)發送 SIGCHLD 信號量，所以 master 進程監測到我們某一個子進程可能出了問題，會啟動一個新的 worker 進程，維護 worker 進程的數量。

kill -s SIGTERM 1332

命令行

reload：HUP

reopen：USR2

stop：TERM

quit：QUIT

可以使用 nginx -h 查看幫助命令

[itbsl@master ~]$ nginx -h
nginx version: nginx/1.18.0
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]
Options:
  -?,-h         : this help
  -v            : show version and exit
  -V            : show version and configure options then exit
  -t            : test configuration and exit
  -T            : test configuration, dump it and exit
  -q            : suppress non-error messages during configuration testing
  -s signal     : send signal to a master process: stop, quit, reopen, reload
  -p prefix     : set prefix path (default: /usr/local/nginx-1.18.0/)
  -c filename   : set configuration file (default: conf/nginx.conf)
  -g directives : set global directives out of configuration file

參數說明：

-?,-h：查看幫助

-v：查看 Nginx 版本

-V：查看 Nginx 版本和編譯選項

-t：檢查配置文件語法是否正確

-T：檢查配置文件語法是否正確，并打印

-q：在檢查配置文件時不顯示非錯誤消息

-s：給 master 進程發送信號，可以發送:stop、quit、reopen、reload

-c：指定配置文件

-g：設置配置文件之外的全局指令

配置文件重載原理

我們知道了可以通過給 nginx 的 master 進程發送 SIGHUP 信號，或者使用 nginx -s reload 命令來達到重新載入配置文件，從而使 nginx 平滑升級。那我們執行這樣一個命令之后，對 nginx 本身來說背后發生了什么事情呢，它是如何保證新老請求如何平滑過渡的?

reload 重載配置文件的流程

向 master 進程發送 HUP 信號(reload 命令)

master 進程檢查配置語法是否正確

master 進程打開監聽端口(在修改配置文件的端口情況下，可能)

master 進程使用新的配置文件啟動新的 worker 子進程

master 進程向老的 worker 子進程發送 QUIT 信號

舊的 worker 進程關閉監聽句柄，處理完當前連接后關閉進程

如果用圖示來描述的話大概如下圖所示

圖示解析：

1.左邊綠色的狀態是執行 nginx -s reload 命令之前的狀態，按照我個人主機的配置時一個 master 進程和 4 個 worker 子進程。

2.為了模擬執行 nginx -s reload 命令后原來的 worker 進程會處理完請求后再被殺掉，我模擬一個需要很久才能處理完任務并響應的接口，是的，我在代碼里 sleep 15 秒，也就是說這個接口響應需要 15 秒，時間弄長點方便我們來觀察中間態，注意，在執行 reload 命令前請求該接口

<?php
    sleep(15);
    echo json_encode(['msg' => 'hello world']);die();

3.我們已經知道了 master 進程會把任務交給 worker 子進程處理，目前只有一個任務，所以當前只需要一個 worker 進程需要處理任務。

4.執行 reload 命令，master 進程會創建 4 個(與你配置有關)新的 worker 進程(上圖中的黃色 worker 進程)，關閉掉舊的空閑 worker 進程(綠色 worker 進程)，而正在處理請求的舊 worker 進程不會立即關閉，而是會等請求處理完畢就關閉。

5.剩下的最后一個舊 worker 進程任務處理完畢也被關掉，最后剩下的都是使用新 nginx.conf 配置產生的新 worker 進程，可以看下面的這張圖，那個處于 is shutting down 的舊 worker 進程就是因為處理上面 sleep 15 秒的任務接口還沒處理完畢，所以依然能夠被看到。

通過上述相信大家對Nginx進程管理與重載原理已經有所了解，如果您想了解更多相關知識，不妨來關注一下動力節點的Java在線學習，里面的課程內容全面，從入門到精通，適合沒有基礎的小白學習，希望對大家能夠有所幫助。