.jpg)
平滑重啟
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)程可以劃分為主進(jìn)程和工作進(jìn)程兩種，它的平滑重啟是通過(guò)信號(hào)HUB進(jìn)行控制的。
注：在POSIX兼容的平臺(tái)上，SIGUSR1和SIGUSR2是發(fā)送給一個(gè)進(jìn)程的信號(hào)，它表示了用戶(hù)定義的情況。
為了詳細(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)程，而用戶(hù)請(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í)間。可用單位：s（秒），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)。
.png)
