怎樣探究Nginx中reload的流程

這篇文章將為大家詳細講解有關怎樣探究Nginx中reload的流程，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

 Nginx 的 reload 流程

在更改了 nginx 配置文件時，我們都會執行 nginx -s reload 命令，我們執行這條命令的原因是希望 nginx 不停止服務始終在處理新的請求的同時把 nginx 的配置文件平滑的把舊的 nginx.conf 配置更新為新的 nginx.conf 配置。

這樣一個功能對于 nginx 非常有必要，但是有時候我們會發現在執行 nginx -s reload 命令后，worker 子進程的數量會變多了，這是因為老的配置運行的 worker 進程長時間沒有退出，當使用 stream 做四層反向代理的時候，可能這種場景會更多。

那么下面我們通過分析 nginx 的 reload 流程，來探究下 nginx 到底做了些什么？所謂優雅的退出和立即退出有什么區別？

reload 流程

第一步在修改好 nginx 的配置文件 nginx.conf 后，向 master 進程發送 HUP 信號，這實際上和我們在命令行執行 nginx -s reload 命令效果是一樣的。

那么 master 進程在收到 HUP 信號以后，會在第二步檢查我們的配置文件語法是否正確，也就是說我們并不一定非要在 nginx -s reload 前執行 nginx -t 檢驗下語法是否正確，因為在第二步 nginx 的 master 進程一定會執行這個步驟。

在 nginx 的配置語法全部正確以后，master 進程會打開新的監聽端口，為什么要在 master 進程中打開新的監聽端口？因為我們可能在 nginx.conf 中會引入新的例如 443 或者之前我們沒有打開的的監聽端口，而所有 worker 進程是 master 進程 的子進程，子進程會繼承父進程所有已經打開的端口，這是 linux 操作系統定義的，所以第三步，我們 master 進程打開了可能引入的新的監聽端口。

接下來 mster 進程會用新的 nginx.conf 配置文件來啟動新的 worker 子進程，那么老的 worker 子進程會怎么樣呢？

我們會在第五步在啟動新的 worker 子進程以后，由 master 進程再向老 worker 子進程發送 QUIT 信號，QUIT 信號和 TERM，INT 信號是不一樣的，QUIT 信號是請優雅地關閉子進程，這時候需要關注順序，因為 nginx 需要保證平滑，所以要先啟動新的 worker 子進程，再向老的 worker 子進程發送 QUIT 信號。

那么老的 master 子進程收到 QUIT 信號后，首先關閉監聽句柄，也就是說這個時候新的連接只會到新的 worker 子進程，所以雖然他們之間有時間差，但是時間是非常快速的，那么關閉監聽句柄后，處理完當前連接后就結束進程。

下面看 reload 不停機載入新配置的圖示。

reload 不停機載入新配置

master 進程上原先有四個綠色的 worker 子進程，它們使用了老的配置，當我們更改了 nginx.conf 配置文件后，向 master 發送 SIGHUP 信號或者執行 reload 命令， 然后 master 會用新的配置文件啟動四個新的黃色 worker 子進程，此時是四個老的綠色 worker 子進程和四個新的黃色的 worker 子進程是并存的。那么老的 worker 子進程在正常的情況下會在處理已經建立好的連接上的請求之后關閉這個連接，哪怕這個連接是 keeplive 請求也會正常關閉。

但是異常情況，如果有一些請求出現問題，客戶端長時間無法處理，那么就會導致這個請求長時間停留在這個 worker 子進程當中，那么這個 worker 子進程會長時間存在，因為新的連接已經跑在黃色的 worker 子進程中，所以影響并不會很大，唯一會影響的就是綠色的 worker 子進程會長時間存在，但也只影響已存在的連接，不會影響新的連接。

我們有什么辦法處理呢？在新版本中提供了一個新的配置 worker_shutdown_timeout，也就是說最長等待多長時間，這樣 master 進程啟動新的黃色 worker 進程之后，如果老的 worker 進程一直沒有退出，時間到了之后會強制把老的 worker 進程退出掉。

關于怎樣探究Nginx中reload的流程就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。