nginx訊號集實例分析

場景復現

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

先啟動nginx

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

接著我們向 master 發送一個 sigusr2 訊號，當 nginx 核心收到這個訊號後，就會觸發熱更新。

可以看到新的master 和該master fork 出來的worker 已經在運作了，此時我們接著向舊master 發送一個sigwinch 訊號，舊master 收到這個訊號後，會向它的worker 發送sigquit，所以舊master 的worker 程序就會退出：

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

接著我們使用stop 指令：

我們會發現，新的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 官方提供的腳本。

這段程式碼引自 nginx 官方的 /etc/init.d/nginx 。

nginx 訊號集

接下來我們來全面梳理下 nginx 訊號集，這裡不會涉及到原始碼細節，有興趣的同學可以自行閱讀相關原始碼。

我們有兩種方式來向 master 程序發送訊號，一種是透過 nginx -s signal 來操作，另一種是透過 kill 指令手動傳送。

第一種方式的原理是，產生一個新進程，該進程透過nginx.pid 檔案得到master 進程的pid，然後把對應的訊號傳送到master，之後退出，這個行程稱為signaller。

第二種方式要求我們了解 nginx -s signal 到真實訊號的對應。下表是它們的對應關係：

operation signal

reload sighup
reopen sigusr1
stop sigterm
quit sigquit
hot update sigusr2 & sigwinch & sigquit
hot update sigusr2 & sigwinch & sigquit##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 官方就提供了一個方案：

這裡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 這個系統調用，使用新的nginx elf 檔案替換目前的進程映像，成為新的master 進程。新 master 進程起來之後，就會進行設定檔解析等操作，然後 fork 出新的 worker 程序開始工作。

接著我們向舊的 master 發送 sigwinch 訊號，然後舊的 master 進程則會向它的 worker 進程發送 sigquit 訊息，從而使得 worker 進程退出。向 master 程序發送 sigwinch 和 sigquit 都會使得 worker 程序退出，但是前者不會讓 master 程序也退出。

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

worker 程式如何處理來自master 的訊號訊息

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

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

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

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

signal effect
sigint 強制退出
sigterm 強制退出
sigquit 優雅退出
sigusr1 重新開啟檔案

以上是nginx訊號集實例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！