站長資訊網本篇文章帶大家了解一下平滑重啟，詳細介紹一下nginx平滑重啟和FPM平滑重啟，希望能夠給大家提供幫助！
平滑重啟
GR是Graceful Restart（平滑重啟）的簡稱，是一種在協議重啟時保證轉發業務不中斷的機制。
GR機制的核心在于：當某設備進行協議重啟時，能夠通知其周邊設備在一定時間內將到該設備的鄰居關系和路由保持穩定。在協議重啟完畢后，周邊設備協助其進行信息（包括支持GR的路由/MPLS相關協議所維護的各種拓撲、路由和會話信息）同步，在盡量短的時間內使該設備恢復到重啟前的狀態。在整個協議重啟過程中不會產生路由振蕩，報文轉發路徑也沒有任何改變，整個系統可以不間斷地轉發數據。這個過程即稱為平滑重啟。
nginx平滑重啟
nginx進程分為master主進程和worker工作進程，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 'done';
用瀏覽器請求這個地址，并在此期間平滑重啟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已經不會再出現。
結論：缺省情況下，PHP-FPM 無法保證平滑的執行 reload 操作，必須設置一個合理的 process_control_timeout 才行，同時需要注意的是其值不能設置的過大，否則系統可能出現嚴重的請求堵塞問題。
推薦學習：《PHP視頻教程》
