本篇文章帶大家了解一下平滑重啟，詳細(xì)介紹一下nginx平滑重啟和FPM平滑重啟，希望能夠給大家提供幫助！

平滑重啟

GR是Graceful Restart（平滑重啟）的簡稱，是一種在協(xié)議重啟時保證轉(zhuǎn)發(fā)業(yè)務(wù)不中斷的機(jī)制。
GR機(jī)制的核心在于：當(dāng)某設(shè)備進(jìn)行協(xié)議重啟時，能夠通知其周邊設(shè)備在一定時間內(nèi)將到該設(shè)備的鄰居關(guān)系和路由保持穩(wěn)定。在協(xié)議重啟完畢后，周邊設(shè)備協(xié)助其進(jìn)行信息（包括支持GR的路由/MPLS相關(guān)協(xié)議所維護(hù)的各種拓?fù)?、路由和會話信息）同步，在盡量短的時間內(nèi)使該設(shè)備恢復(fù)到重啟前的狀態(tài)。在整個協(xié)議重啟過程中不會產(chǎn)生路由振蕩，報文轉(zhuǎn)發(fā)路徑也沒有任何改變，整個系統(tǒng)可以不間斷地轉(zhuǎn)發(fā)數(shù)據(jù)。這個過程即稱為平滑重啟。

nginx平滑重啟

nginx進(jìn)程分為master主進(jìn)程和worker工作進(jìn)程，nginx的平滑重啟通過信號HUB控制。

注：在POSIX兼容的平臺上，SIGUSR1和SIGUSR2是發(fā)送給一個進(jìn)程的信號，它表示了用戶定義的情況。

為了詳細(xì)分析nginx的平滑重啟過程，我們持續(xù)監(jiān)控nginx進(jìn)程變化。
發(fā)送HUP信號

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

通過觀察，可以分析出大致的平滑重啟過程為：
1. master使用新配置 fork出n-1個worker及新master
2. 新worker處理新情求，舊worker執(zhí)行完退出
3. master重新加載配置，期間使用新master接管服務(wù)
4. master加載配置完畢，新master切換為worker工作模式
平滑重啟完，master進(jìn)程號并不會發(fā)生變化。

nginx平滑升級

HUP僅用于平滑重啟，加載配置等，如果要平滑升級nginx版本，重新加載編譯的二進(jìn)制文件，需要借助于USR2信號。

1. 發(fā)送USR2信號

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

觀察到nginx進(jìn)程，fork出新master及worker，此時nginx.pid內(nèi)容已經(jīng)發(fā)生變化，并且在logs目錄下生成了nginx.pid.oldbin文件，記錄舊master pid.

2. 向舊master發(fā)送WINCH信號，nginx woker會優(yōu)雅地停止服務(wù)，即：停止接收新的請求，但是不會終止已經(jīng)在處理的請求。一段時間后，舊nginx的所有worker進(jìn)程全部退出，只剩下master進(jìn)程，而用戶請求全部都由新的nginx進(jìn)程處理。

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

3、向舊master發(fā)送QUIT信號，舊nginx進(jìn)程完全退出，至此平滑升級完成。

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

FPM平滑重啟

FPM（FastCGI 進(jìn)程管理器）用于替換 PHP FastCGI 的大部分附加功能，php5.3.3之后已經(jīng)集成FPM，在./configure的時候帶 –enable-fpm參數(shù)即可開啟PHP-FPM。

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

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

通過持續(xù)觀察fpm進(jìn)程可以看到，F(xiàn)PM平滑重啟，需要等子進(jìn)程完全退出后，才會啟動新的master及子進(jìn)程，隨后舊master退出。
使用strace進(jìn)一步分析

發(fā)現(xiàn)master通知所有子進(jìn)程退出，包含正在處理請求的子進(jìn)程。

為了進(jìn)一步驗證這個結(jié)論，編寫一個服務(wù)端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無法優(yōu)雅的實現(xiàn)平滑重啟的說明。
難道FPM這么low？答案當(dāng)時是no，實際上通過 process_control_timeout 參數(shù)可以實現(xiàn)我們的目標(biāo)。

process_control_timeout

設(shè)置子進(jìn)程接受主進(jìn)程復(fù)用信號的超時時間?？捎脝挝唬簊（秒），m（分），h（小時）或者 d（天）。默認(rèn)單位：s（秒）。默認(rèn)值：0（關(guān)閉）。

原則上，php-fpm會選擇空閑的fastcgi進(jìn)程去處理請求，在處理之前，php-fpm會給fastcgi發(fā)送信號，用來讓fastcgi進(jìn)程準(zhǔn)備好接受請求處理。但是fastcgi進(jìn)程并不總是能夠處理請求，也就是不能總是響應(yīng)該信號（比如出現(xiàn)假死的情況），這時候就需要設(shè)定php-fpm留給fastcgi進(jìn)程響應(yīng)信號的時間，如果超時了，php-fpm會想其他辦法（例如選擇其他fastcgi進(jìn)程），這個就是process_control_timeout參數(shù)的作用。

這個參數(shù)缺省是 0，也就是不生效，修改為10，重新驗證，502已經(jīng)不會再出現(xiàn)。

結(jié)論：缺省情況下，PHP-FPM 無法保證平滑的執(zhí)行 reload 操作，必須設(shè)置一個合理的 process_control_timeout 才行，同時需要注意的是其值不能設(shè)置的過大，否則系統(tǒng)可能出現(xiàn)嚴(yán)重的請求堵塞問題。

推薦學(xué)習(xí)：《PHP視頻教程》