Nginx 的進程結構，你明白嗎？

Nginx 進程結構

這篇文章咱們來看下 Nginx 的進程結構，Nginx 其實有兩種進程結構：

• 單進程結構
• 多進程結構

單進程結構實際上不適用於生產環境，只適合咱們作開發調試使用。由於在生產環境中咱們必須保持 Nginx 足夠健壯以及 Nginx 能夠利用多核的一個特性，而單進程的 Nginx 是作不到這一點的，因此默認的配置中都是打開爲多進程的 Nginx。

咱們來看一下，多進程的 Nginx 結構中它的進程模型是怎樣的。

多進程中的 Nginx 進程架構以下圖所示，會有一個父進程（Master Process），它會有不少子進程（Child Processes），這些子進程會分爲兩類：

• worker 進程
• cache 相關的進程

爲何 Nginx 採用多進程結構而不是多線程結構呢？

由於 Nginx 最核心的一個目的是要保持高可用性、高可靠性，而當 Nginx 若是使用的是多線程結構的時候，由於線程之間是共享同一個地址空間的，因此當某一個第三方模塊引起了一個地址空間致使的段錯誤時、在地址越界出現時，會致使整個 Nginx 進程所有掛掉。而當採用多進程模型時，每每不會出現這樣的問題。從上圖能夠看到 Nginx 在作進程設計時，一樣遵循了實現高可用、高可靠這樣的一個目的。

好比說在 master 進程中，一般第三方模塊是不會在 master 部分加入本身的功能代碼的。雖然 Nginx 在設計時，容許第三方模塊在 master 進程中添加本身獨有的、自定義的一些方法，可是一般沒有第三方模塊這麼作。

master 進程被設計用來的目的是作 worker 進程的管理的，也就是全部的 worker 進程是處理真正的請求的，而 master 進程負責監控每一個 worker 進程是否是在正常的工做、需不須要作從新載入配置文件、需不須要作熱部署。

而 cache （緩存）是在多個 worker 進程間共享的，並且緩存不只要被 worker 進程使用，還要被 cache manager 和 cache loader進程 使用。cache manager 和 cache loader 也是爲反向代理時，後端發來的動態請求作緩存所使用的，cache loader 只是用來作緩存的載入、cache manager 用來作緩存的管理。實際上每一個請求處理時，使用到緩存仍是由 worker 進程來進行的。

這些進程間的通信，都是使用共享內存來解決的。能夠看到cache manager 和 cache loader各有一個進程，master 進程由於是父進程，因此確定只有一個。那麼 worker 進程爲何會有不少呢？這是由於 Nginx 採用了事件驅動引擎之後，他但願每個 worker 進程從頭至尾佔有一顆CPU，因此每每不止要把 worker 進程的數量配置與咱們服務器上的 CPU核數一致之外，還須要把每個worker進程與某一顆CPU核綁定在一塊兒，這樣能夠更好的使用每顆CPU核上面的CPU緩存來減小緩存失效的命中率。

以上就是 Nginx 的進程結構的介紹，瞭解這些後更有助於咱們去配置 Nginx。

剛纔咱們介紹了 Nginx 使用了多進程模型，由 master 做爲父進程啓動許多子進程，也知道了 Nginx 父子進程之間是經過信號來管理的，接下來經過一個實例給你們直觀的看下父子進程以及信號之間是如何工做的。

Nginx 的進程結構實例

首先啓動 Nginx，並在 Nginx 中啓動了兩個 worker 進程，經過 ps 命令能夠看到當前進程 PID 和父進程 PID，有一個 nginx master 進程是由 root 用戶起的，進程 PID 是 2368。還有兩個 worker 進程和 cache 進程，它們是由 2368 進程起來的。它們的進程 PID 分別爲 8652，8653，8655。

如今咱們使用 ./sbin/nginx -s reload 命令，會把以前的 worker 進程和 cache 進程優雅的退出，而後再使用的新的配置項啓動新的 worker 進程，這裏咱們並無改變配置，可是咱們能夠看到老的三個子進程會退出，並生成新的子進程。

能夠看到，以前的三個子進程，如今已經都不在了，反而由 2368 新起了 8657，8658，8660 三個子進程。

[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4751  4688  0 11:41 pts/0    00:00:00 grep --color=auto nginx
nginx     8652  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8653  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8655  2368  0 Nov12 ?        00:00:00 nginx: cache manager process
[root@wupx nginx]# ./sbin/nginx -s reload
[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4753  4688  0 11:43 pts/0    00:00:00 grep --color=auto nginx
nginx     8657  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8658  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8660  2368  0 Nov12 ?        00:00:00 nginx: cache manager process

執行命令以後能夠看到 worker 的 PID 已經變化了（以前講過 ./sbin/nginx -s reload 跟 kill -SIGHUP 做用是同樣的。）。

kill -SIGTERM 是向現有的 worker 進程發送退出的信號，對應的 worker 進程就會退出；進程在退出時，會自動向父進程 master 發送一個退出信號，master 就知道他的子進程退出了，而後新起一個 worker 進程。

[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4753  4688  0 11:43 pts/0    00:00:00 grep --color=auto nginx
nginx     8657  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8658  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8660  2368  0 Nov12 ?        00:00:00 nginx: cache manager process
[root@wupx nginx]# kill -SIGTERM 8658
[root@wupx nginx]# ps -ef|grep nginx
root      2368     1  0 Sep21 ?        00:00:00 nginx: master process /usr/sbin/nginx
root      4753  4688  0 11:44 pts/0    00:00:00 grep --color=auto nginx
nginx     8657  2368  0 Nov12 ?        00:00:00 nginx: worker process
nginx     8660  2368  0 Nov12 ?        00:00:00 nginx: cache manager process
nginx     8663  2368  0 Nov12 ?        00:00:00 nginx: worker process

經過實例演示，咱們能夠看到 Nginx 的進程結構以及 Nginx 使用信號的方式，其實命令行中的許多子命令就是再向 master 進程發送信號而已。