nginx平滑重啟和FPM平滑重啟是什麼

平滑重啟

GR是Graceful Restart（平滑重啟）的簡稱，是一種在協定重新啟動時保證轉送業務不會中斷的機制。
GR機制的核心在於：當某設備進行協定重新啟動時，能夠通知其周邊設備在一定時間內將到該設備的鄰居關係和路由保持穩定。在協定重新啟動後，週邊設備協助其進行資訊（包括支援GR的路由/MPLS相關協定所維護的各種拓樸、路由和會話資訊）同步，在盡量短的時間內使該設備恢復到重新啟動前的狀態。在整個協定重新啟動過程中不會產生路由振盪，封包轉送路徑也沒有任何改變，整個系統可以不間斷地轉送資料。這個過程即稱為平滑重啟。

nginx平滑重啟

Nginx進程可以劃分為主進程和工作進程兩種，它的平滑重啟是透過訊號HUB進行控制的。

註：在POSIX相容的平台上，SIGUSR1和SIGUSR2是傳送給一個行程的訊號，它表示了使用者定義的情況。

為了詳細分析nginx的平滑重啟過程，我們持續監控nginx進程變化。
發送HUP訊號

kill -HUP `cat /home/git/nginx/logs/nginx.pid`

#透過觀察，可以分析出大致的平滑重啟流程為：
1. master使用新配置fork出n-1個worker及新master
2. 新worker處理新情求，舊worker執行完退出
3. master重新載入配置，期間使用新master接管服務
4. master載入配置完畢，新master切換為worker工作模式
平滑重啟完，master進程號並不會改變。

nginx平滑升級

HUP僅用於平滑重啟，載入設定等，如果要平滑升級nginx版本，重新載入編譯的二進位文件，需要藉助於USR2訊號.

1. 傳送USR2訊號

kill -USR2 `cat /home/git/nginx/logs/nginx.pid`

#觀察到nginx流程，fork出新master及worker，此時nginx.pid內容已經發生變化，並且在logs目錄下生成了nginx.pid.oldbin文件，記錄舊master pid.

2. 向舊master發送WINCH信號，nginx woker會優雅地停止服務，即：停止接收新的請求，但是不會終止已經在處理的請求。一段時間後，所有舊nginx的worker進程全部退出，只剩下master進程，而使用者請求全部都由新的nginx進程處理。

kill -WINCH `cat /home/git/nginx/logs/nginx.pid.oldbin`

3、向舊master發送QUIT訊號，舊nginx進程完全退出，至此平滑升級完成。

kill -QUIT `cat /home/git/nginx/logs/nginx.pid.oldbin`

FPM平滑重啟

FPM（FastCGI 進程管理器）用於取代PHP FastCGI 的大部分附加功能，php5 .3.3之後已經整合FPM，在./configure的時候帶–enable-fpm參數即可開啟PHP-FPM。

FPM的平滑重啟需要透過USR2訊號控制，不過與nginx的平滑重啟過程有較大的不同。

kill -USR2 `cat /home/git/php/var/run/php-fpm.pid`

透過持續觀察fpm進程可以看到，FPM平滑重啟，需要等子進程完全退出後，才會啟動新的master及子進程，隨後舊master退出。
使用strace進一步分析

發現master通知所有子程序退出，包含正在處理請求的子程序。

為了進一步驗證這個結論，編寫一個服務端sleep腳本

<?php
exec("sleep 5");
echo &#39;done&#39;;

用瀏覽器請求這個位址，並在此期間平滑重啟fpm，請求直接502了。
nginx錯誤日誌：

[error] 29841#0: *1646 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /test.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "localhost"

php bug#60961，也有對fpm無法優雅的實現平滑重啟的說明。
難道FPM這麼low？答案當時是no，實際上透過 process_control_timeout 參數可以實現我們的目標。

process_control_timeout

#

設定子程序接受主程序復用訊號的逾時時間。可用單位：s（秒），m（分），h（小時）或 d（天）。預設單位：s（秒）。預設值：0（關閉）。

原則上，php-fpm會選擇空閒的fastcgi進程去處理請求，在處理之前，php-fpm會給fastcgi發送訊號，用來讓fastcgi進程準備好接受請求處理。但是fastcgi進程並不總是能夠處理請求，也就是不能總是回應該訊號（例如出現假死的情況），這時候就需要設定php-fpm留給fastcgi進程回應訊號的時間，如果逾時了，php -fpm會想其他辦法（例如選擇其他fastcgi進程），這就是process_control_timeout參數的作用。

這個參數缺省是 0，也就是不生效，修改為10，重新驗證，502已經不會再出現。

以上是nginx平滑重啟和FPM平滑重啟是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！