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

本篇內(nèi)容主要講解“nginx平滑重啟和FPM平滑重啟是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“nginx平滑重啟和FPM平滑重啟是什么”吧!

平滑重啟

GR是Graceful Restart（平滑重啟）的簡稱，是一種在協(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ù)洹⒙酚珊蜁捫畔ⅲ┩?，在盡量短的時(shí)間內(nèi)使該設(shè)備恢復(fù)到重啟前的狀態(tài)。在整個(gè)協(xié)議重啟過程中不會產(chǎn)生路由振蕩，報(bào)文轉(zhuǎn)發(fā)路徑也沒有任何改變，整個(gè)系統(tǒng)可以不間斷地轉(zhuǎn)發(fā)數(shù)據(jù)。這個(gè)過程即稱為平滑重啟。

nginx平滑重啟

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

注：在POSIX兼容的平臺上，SIGUSR1和SIGUSR2是發(fā)送給一個(gè)進(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個(gè)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，此時(shí)nginx.pid內(nèi)容已經(jīng)發(fā)生變化，并且在logs目錄下生成了nginx.pid.oldbin文件，記錄舊master pid.

2. 向舊master發(fā)送WINCH信號，nginx woker會優(yōu)雅地停止服務(wù)，即：停止接收新的請求，但是不會終止已經(jīng)在處理的請求。一段時(shí)間后，舊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的時(shí)候帶 –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)一步驗(yàn)證這個(gè)結(jié)論，編寫一個(gè)服務(wù)端sleep腳本

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

用瀏覽器請求這個(gè)地址，并在此期間平滑重啟fpm，請求直接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，也有對fpm無法優(yōu)雅的實(shí)現(xiàn)平滑重啟的說明。
難道FPM這么low？答案當(dāng)時(shí)是no，實(shí)際上通過 process_control_timeout 參數(shù)可以實(shí)現(xiàn)我們的目標(biāo)。

process_control_timeout

設(shè)置子進(jìn)程接受主進(jìn)程復(fù)用信號的超時(shí)時(shí)間?？捎脝挝唬簊（秒），m（分），h（小時(shí)）或者 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í)候就需要設(shè)定php-fpm留給fastcgi進(jìn)程響應(yīng)信號的時(shí)間，如果超時(shí)了，php-fpm會想其他辦法（例如選擇其他fastcgi進(jìn)程），這個(gè)就是process_control_timeout參數(shù)的作用。

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

到此，相信大家對“nginx平滑重啟和FPM平滑重啟是什么”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！