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

平滑重啟

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

nginx平滑重啟

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

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

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

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

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

nginx平滑升級(jí)

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

1. 發(fā)送USR2信號(hào)

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

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

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

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

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

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

FPM平滑重啟

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

FPM的平滑重啟需要通過(guò)USR2信號(hào)控制，不過(guò)與nginx的平滑重啟過(guò)程有較大的不同。

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

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

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

為了進(jìn)一步驗(yàn)證這個(gè)結(jié)論，編寫(xiě)一個(gè)服務(wù)端sleep腳本

<?php exec("sleep 5"); echo 'done';

用瀏覽器請(qǐng)求這個(gè)地址，并在此期間平滑重啟fpm，請(qǐng)求直接502了。
nginx錯(cuò)誤日志：

[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，也有對(duì)fpm無(wú)法優(yōu)雅的實(shí)現(xiàn)平滑重啟的說(shuō)明。
難道FPM這么low？答案當(dāng)時(shí)是no，實(shí)際上通過(guò) process_control_timeout 參數(shù)可以實(shí)現(xiàn)我們的目標(biāo)。

process_control_timeout

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

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

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

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

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