php-fpm允许查尔兹进程正常重启，通常使用reload关键字代替init脚本上的restart，发送USR 2信号。
因此，通过执行优雅重启，您不应丢失任何正在运行的事务。在每个子进程的当前请求管理结束后，子进程将被杀死。如果您不需要真实的的重启，**这应该足够了。我做了一些测试，例如，重载足以：

• 清空APC缓存
• 更改日志文件路径
• 更改最小/最大/开始子设置

所以我还没有发现需要真实的重新启动的情况。除了重新加载不能启动停止的服务。
如果你想确保当你想重新加载一个池时其他池不会被重新加载，你必须管理几个php-fpm守护进程，每个守护进程管理一个池，这意味着要写几个init脚本和主配置文件。
使用restart关键字更危险，特别是因为init脚本可能会在停止步骤中杀死长时间运行的子进程。对于使用多个PID和配置文件管理的多个守护进程，您甚至可以获得带有--exec选项的start-stop-daemon命令（在debian中就是这种情况）并且这将杀死所有运行相同php-fpm可执行文件的守护进程（如果运行多个php-fpm进程，在停止具有正确PID的正确守护进程后，会向所有其他并行php-fpm守护进程发送kill-9，这非常糟糕）。
所以使用reload关键字（USR 2信号）是必须的。

虽然已经有了一个最佳答案，但我写这封信是为了提供最佳答案中遗漏的更多信息。

• 在执行reload之后，PHP-FPM将等待直到所有请求都被处理，但不会超过process_control_timeout，如果达到process_control_timeout，将出现502错误
• 在等待所有的请求被处理时，PHP-FPM将不会处理任何新的请求，而是将它们排队。因为只有在所有旧的请求被处理之后，才会创建一个新的重载进程。

这就引出了一些事实和问题

• 说到零停机时间，延迟处理算吗？
• 服务器能够排队多少个请求？
• 当然，延迟处理意味着页面会在用户端卡住。

我试过在一个laravel项目中重载php-fpm，并且启用了opcache，但是每次付款都被停止。