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 程序傳送訊號而已。

相關推薦