本篇文章帶大家了解一下平滑重啟，詳細介紹一下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腳本
登入後複製
用浏览器请求这个地址，并在此期间平滑重启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"
phpbug#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视频教程》
以上是聊聊nginx平滑重啟和FPM平滑重啟的詳細內容。更多資訊請關注PHP中文網其他相關文章！
