起步
在测试中，发现 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 内容请搜索阿兔在线工具以前的文章或继续浏览下面的相关文章希望大家以后多多支持阿兔在线工具！
