php-fpm reload 会取消正在处理请求的解决方案

起步

在测试中，发现 php-fpm reload 会强制 kill 掉正在处理的请求。网上查了一下，发现其他人也有这个问题并反馈给了官方：和 https://bugs.php.net/bug.php?id=60961，帖子是 2017 和 2012 年的，到现在还没解决。

官方帮助手册还说 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 进程通过接受用户发送的 SIGUSR2 信号实现自身服务的 reload:

kill -USR2 <pid>

主进程（master进程）收到 reload 信号，会向所有子进程发送 SIGGUIT 信号，同时注册定时器时间，timeout 的值为 fpm_global_config.process_control_timeout 。在规定时间之内子进程还没有结束，则子进程将被 kill 。比如 timeout 值设为1秒，如果在 1 秒之内还没有结束，则直接向子进程发送 SIGKILL 信号，强制杀死。

最后 master 等待所有的子进程结束后，根据之前保存的启动参数重新启动一个进程，并继承父进程的 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

测试结果，正在处理的请求只要在该时间内完成请求，就能正常返回。

这不是 100% 的方案是因为，master 进程要等待所有子进程结束才会重新创建 worker 进程，而 process_control_timeout 等待的时候，worker 进程不接受请求了，因此这段时间内新的请求进不来，这些新请求将由 fpm 排队，nginx 若超时会报 502 给用户，保险起见，nginx 的超时时间的值应该是 process_control_timeout 的两倍。

尽管可能会报 502 ，但这样的处理方式比杀死正在处理的请求让人接受的多了。

总结

尽管设置了 process_control_timeout ，在上述情况之上，PHP-FPM 在 reload 完成之前不会为新请求提供服务。但是，所有这些新请求将由 fpm 排队，并在重新加载完成后立即执行。最终用户的结果是，在此期间，他们看到浏览器显示加载中。另一点是设置的超时，也不能保证请求在这个时间内处理完，还是需要程序员保证自己的脚本运行时间在合理范围内。

到此这篇关于php-fpm reload 会取消正在处理请求的解决方案的文章就介绍到这了,更多相关php-fpm reload 内容请搜索Devmax以前的文章或继续浏览下面的相关文章希望大家以后多多支持Devmax！