起步

在測試中，發(fā)現(xiàn) php-fpm reload 會強制 kill 掉正在處理的請求。網(wǎng)上查了一下，發(fā)現(xiàn)其他人也有這個問題并反饋給了官方：和 https://bugs.php.net/bug.php?id=60961，帖子是 2017 和 2012 年的，到現(xiàn)在還沒解決。

官方幫助手冊還說 reload 是 graceful ，啊哈哈，不要太相信:

man php-fpm
...
SIGINT,SIGTERM
    immediate termination
    SIGQUIT 
graceful stop
    SIGUSR1 
re-open log file
SIGUSR2
    graceful reload of all workers + reload of fpm conf/binary
...

reload 流程簡介

php-fpm 是 master worker 的工作方式。

php-fpm master 進程通過接受用戶發(fā)送的 SIGUSR2 信號實現(xiàn)自身服務的 reload:

kill -USR2 <pid>

主進程（master進程）收到 reload 信號，會向所有子進程發(fā)送 SIGGUIT 信號，同時注冊定時器時間，timeout 的值為 fpm_global_config.process_control_timeout 。在規(guī)定時間之內(nèi)子進程還沒有結束，則子進程將被 kill 。比如 timeout 值設為1秒，如果在 1 秒之內(nèi)還沒有結束，則直接向子進程發(fā)送 SIGKILL 信號，強制殺死。

最后 master 等待所有的子進程結束后，根據(jù)之前保存的啟動參數(shù)重新啟動一個進程，并繼承父進程的 socket 文件描述符。

緩兵之計

注意，這只是緩解的方案，依然不能保證請求不會丟失。這個方案在于 process_control_timeout 這個配置選項，配置文件在 php-fpm.conf (我的是在 /usr/local/etc/php-fpm.conf)中，默認值是 0 ，會立即將子進程 kill 掉，這里我改為了 60s 進行測試：

; Time limit for child processes to wait for a reaction on signals from master.
; Available units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
process_control_timeout = 60s

測試結果，正在處理的請求只要在該時間內(nèi)完成請求，就能正常返回。

這不是 100% 的方案是因為，master 進程要等待所有子進程結束才會重新創(chuàng)建 worker 進程，而 process_control_timeout 等待的時候，worker 進程不接受請求了，因此這段時間內(nèi)新的請求進不來，這些新請求將由 fpm 排隊，nginx 若超時會報 502 給用戶，保險起見，nginx 的超時時間的值應該是 process_control_timeout 的兩倍。

盡管可能會報 502 ，但這樣的處理方式比殺死正在處理的請求讓人接受的多了。

總結

盡管設置了 process_control_timeout ，在上述情況之上，PHP-FPM 在 reload 完成之前不會為新請求提供服務。但是，所有這些新請求將由 fpm 排隊，并在重新加載完成后立即執(zhí)行。最終用戶的結果是，在此期間，他們看到瀏覽器顯示加載中。另一點是設置的超時，也不能保證請求在這個時間內(nèi)處理完，還是需要程序員保證自己的腳本運行時間在合理范圍內(nèi)。

到此這篇關于php-fpm reload 會取消正在處理請求的解決方案的文章就介紹到這了,更多相關php-fpm reload 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論