Nginx信號集有什么用

本篇內容介紹了“Nginx信號集有什么用”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Nginx信號操作在日常運維中是最常見的，也是非常重要的，這個環節如果出現失誤則可能造成業務異常，帶來損失。所以理清楚 Nginx信號集是非常必要的，能幫助我們更好地處理這些工作。

前言

之前工作時候，一臺引流測試機器的一個 ngx_lua 服務突然出現了一些 HTTP/500 響應，從錯誤日志打印的堆棧來看，是不久前新發布的版本里添加的一個 Lua table 不存在，而有代碼向其進行索引導致的。這令人百思不得其解，如果是版本回退導致的，那么為什么使用這個 Lua table 的代碼沒有被回退，偏偏定義這個 table 的代碼被回退了呢？

經過排查發現，當時 Nginx剛剛完成熱更新操作，舊的 master 進程還存在，因為要準備機器重啟，先切掉了引流流量（但有些請求還在），同時系統觸發了 Nginx-s stop，這才導致了這個問題。

場景復現

下面我將使用一個原生的 Nginx，在我的安裝了 fedora26 的虛擬機上復現這個過程，我使用的 Nginx版本是目前***的 1.13.4

首先啟動 Nginx：

alex@Fedora26-64: ~/bin_install/nginx ./sbin/nginx alex@Fedora26-64: ~/bin_install/nginx ps auxf | grep nginx alex      6174  0.0  0.0  28876   428 ?        Ss   14:35   0:00 nginx: master process ./sbin/nginx alex      6175  0.0  0.2  29364  2060 ?        S    14:35   0:00  \_ nginx: worker process

可以看到 master 和 worker 都已經在運行。

接著我們向 master 發送一個 SIGUSR2 信號，當 Nginx核心收到這個信號后，就會觸發熱更新。

alex@Fedora26-64: ~/bin_install/nginx kill -USR2 6174 alex@Fedora26-64: ~/bin_install/nginx ps auxf | grep nginx alex      6174  0.0  0.1  28876  1996 ?        Ss   14:35   0:00 nginx: master process ./sbin/nginx alex      6175  0.0  0.2  29364  2060 ?        S    14:35   0:00  \_ nginx: worker process alex      6209  0.0  0.2  28876  2804 ?        S    14:37   0:00  \_ nginx: master process ./sbin/nginx alex      6213  0.0  0.1  29364  2004 ?        S    14:37   0:00      \_ nginx: worker process

可以看到新的 master 和該 master fork 出來的 worker 已經在運行了，此時我們接著向舊 master 發送一個 SIGWINCH 信號，舊 master 收到這個信號后，會向它的 worker 發送 SIGQUIT，于是舊 master 的 worker 進程就會退出：

alex@Fedora26-64: ~/bin_install/nginx kill -WINCH 6174 alex@Fedora26-64: ~/bin_install/nginx ps auxf | grep nginx alex      6174  0.0  0.1  28876  1996 ?        Ss   14:35   0:00 nginx: master process ./sbin/nginx alex      6209  0.0  0.2  28876  2804 ?        S    14:37   0:00  \_ nginx: master process ./sbin/nginx alex      6213  0.0  0.1  29364  2004 ?        S    14:37   0:00      \_ nginx: worker process

此時只剩下舊的 master，新的 master 和新 master 的 worker 在運行，這和當時線上運行的情況類似。

接著我們使用 stop 命令：

alex@Fedora26-64: ~/bin_install/nginx ./sbin/nginx -s stop alex@Fedora26-64: ~/bin_install/nginx ps auxf | grep nginx alex      6174  0.0  0.1  28876  1996 ?        Ss   14:35   0:00 nginx: master process ./sbin/nginx alex      6301  0.0  0.2  29364  2124 ?        S    14:49   0:00  \_ nginx: worker process

我們會發現，新的 master 和它的 worker 都已經退出，而舊的 master 還在運行，并產生了 worker 出來。這就是當時線上的情況了。

事實上，這個現象和 Nginx自身的設計有關：當舊的 master 準備產生 fork 新的 master 之前，它會把 Nginx.pid 這個文件重命名為 Nginx.pid.oldbin，然后再由 fork 出來的新的 master 去創建新的 Nginx.pid，這個文件將會記錄新 master 的 pid。Nginx認為熱更新完成之后，舊 master 的使命幾乎已經結束，之后它隨時會退出，因此之后的操作都應該由新 master 接管。當然，在舊 master 沒有退出的情況下通過向新 master 發送 SIGUSR2 企圖再次熱更新是無效的，新 master 只會忽略掉這個信號然后繼續它自己的工作。

問題分析

更不巧的是，我們上面提到的這個 Lua table，定義它的 Lua 文件早在運行 init_by_lua 這個 hook 的時候，就已經被 LuaJIT 加載到內存并編譯成字節碼了，那么顯然舊的 master 必然沒有這個 Lua table，因為它加載那部分 Lua 代碼是舊版本的。

而索引該 table 的 Lua 代碼并沒有在 init_by_lua 的時候使用到，這些代碼都是在 worker 進程里被加載起來的，這時候項目目錄里的代碼都是***的，所以 worker 進程加載的都是***的代碼，如果這些 worker 進程處理到相關的請求，就會出現 Lua 運行時錯誤，外部表現則是對應的 HTTP 500。

吸收了這個教訓之后，我們需要更加合理地關閉我們的 Nginx服務。 所以一個更加合理的 Nginx服務啟動關閉腳本是必需的，網上流傳的一些腳本并沒有對這個現象做處理，我們更應該參考 Nginx官方提供的腳本。

stop() {     echo -n $"Stopping $prog: "     killproc $prog -QUIT     retval=$?     echo     [ $retval -eq 0 ] && rm -f $lockfile     return $retval }

這段代碼引自 Nginx官方的 /etc/init.d/Nginx[1] 。

Nginx信號集

接下來我們來全面梳理下 Nginx信號集，這里不會涉及到源碼細節，感興趣的同學可以自行閱讀相關源碼。

我們有兩種方式來向 master 進程發送信號，一種是通過 Nginx-s signal 來操作，另一種是通過 kill 命令手動發送。

***種方式的原理是，產生一個新進程，該進程通過 Nginx.pid 文件得到 master 進程的 pid，然后把對應的信號發送到 master，之后退出，這種進程被稱為 signaller。

第二種方式要求我們了解 Nginx-s signal 到真實信號的映射。下表是它們的映射關系：

stop vs quit

stop 發送 SIGTERM 信號，表示要求強制退出，quit 發送 SIGQUIT，表示優雅地退出。 具體區別在于，worker 進程在收到 SIGQUIT 消息（注意不是直接發送信號，所以這里用消息替代）后，會關閉監聽的套接字，關閉當前空閑的連接（可以被搶占的連接），然后提前處理所有的定時器事件，***退出。沒有特殊情況，都應該使用 quit 而不是 stop。

reload

master 進程收到 SIGHUP 后，會重新進行配置文件解析、共享內存申請，等一系列其他的工作，然后產生一批新的 worker 進程，***向舊的 worker 進程發送 SIGQUIT 對應的消息，最終無縫實現了重啟操作。

reopen

master 進程收到 SIGUSR1 后，會重新打開所有已經打開的文件（比如日志），然后向每個 worker 進程發送 SIGUSR1 信息，worker 進程收到信號后，會執行同樣的操作。reopen 可用于日志切割，比如 Nginx官方就提供了一個方案：

$ mv access.log access.log.0 $ kill -USR1 `cat master.nginx.pid` $ sleep 1 $ gzip access.log.0    # do something with access.log.0

這里 sleep 1 是必須的，因為在 master 進程向 worker 進程發送 SIGUSR1 消息到 worker 進程真正重新打開 access.log 之間，有一段時間窗口，此時 worker 進程還是向文件 access.log.0 里寫入日志的。通過 sleep 1s，保證了 access.log.0 日志信息的完整性（如果沒有 sleep 而直接進行壓縮，很有可能出現日志丟失的情況）。

hot update

某些時候我們需要進行二進制熱更新，Nginx在設計的時候就包含了這種功能，不過無法通過 Nginx提供的命令行完成，我們需要手動發送信號。

通過上面的問題復現，大家應該已經了解到如何進行熱更新了，我們首先需要給當前的 master 進程發送 SIGUSR2，之后 master 會重命名 Nginx.pid 到 Nginx.pid.oldbin，然后 fork 一個新的進程，新進程會通過 execve 這個系統調用，使用新的 NginxELF 文件替換當前的進程映像，成為新的 master 進程。新 master 進程起來之后，就會進行配置文件解析等操作，然后 fork 出新的 worker 進程開始工作。

接著我們向舊的 master 發送 SIGWINCH 信號，然后舊的 master 進程則會向它的 worker 進程發送 SIGQUIT 信息，從而使得 worker 進程退出。向 master 進程發送 SIGWINCH 和 SIGQUIT 都會使得 worker 進程退出，但是前者不會使得 master 進程也退出。

***，如果我們覺得舊的 master 進程使命完成，就可以向它發送 SIGQUIT 信號，讓其退出了。

worker 進程如何處理來自 master 的信號消息

實際上，master 進程再向 worker 進程通訊，不是使用 kill 函數，而是使用了通過管道實現的 Nginxchannel，master 進程向管道一端寫入信息（比如信號信息），worker 進程則從另外一端收取信息，Nginxchannel 事件，在 worker 進程剛剛起來的時候，就被加入事件調度器中（比如 epoll，kqueue），所以當有數據從 master 發來時，即可被事件調度器通知到。

Nginx這么設計是有理由的，作為一個優秀的反向代理服務器，Nginx追求的就是***的高性能，而 signal handler 會中斷 worker 進程的運行，使得所有的事件都被暫停一個時間窗口，這對性能是有一定損失的。

很多人可能會認為當 master 進程向 worker 進程發送信息之后，worker 進程立刻會有對應操作回應，然而 worker 進程是非常繁忙的，它不斷地處理著網絡事件和定時器事件，當調用 Nginxchannel 事件的 handler 之后，Nginx僅僅只是處理了一些標志位。真正執行這些動作是在一輪事件調度完成之后。所以這之間存在一個時間窗口，尤其是業務復雜且流量巨大的時候，這個窗口就有可能被放大，這也就是為什么 Nginx官方提供的日志切割方案里要求 sleep 1s 的原因。

當然，我們也可以繞過 master 進程，直接向 worker 進程發送信號，worker 可以處理的信號有

“Nginx信號集有什么用”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！