【发布时间】:2020-12-10 00:14:38
【问题描述】:
我正面临 Symfony Messenger 组件的奇怪行为。我根据documentation 进行设置,并按照here 的指示在每次部署时发出messenger:stop-workers 信号。然而,我们的系统中出现了一个错误,我追溯到 Messenger 工作人员正在使用旧版本的代码。
经过进一步调查,我们的设置中会发生以下情况:
- 工作人员正在运行,由主管管理。
- 只是为了调试这个特殊情况,我在终端
app/console messenger:consume --env=prod -vv async中启动了一个新工作人员,看看会发生什么 - 我发出停止命令
app/console messenger:stop-workers --env=prod - 我现在希望这两个工作人员都将停止(并且主管将重新启动它正在处理的工作人员)。但是,这不会发生。 “调试”工作人员确实停止了,但在主管下运行的工作人员什么也不做。
主管管理的工作人员被限制为 1 小时的处理时间,之后它们会停止并重新启动。我可以在supervisord.log 中看到这很好用。每小时都有关于进程停止和启动的日志条目。但是他们并没有停止messenger:stop-workers 命令。
我正在寻找关于为什么会发生这种情况的想法。我阅读了workers的实现,关闭信号是通过缓存发送的,但我没有发现我们的配置有任何问题。
【问题讨论】:
-
supervisorctl restart all部署不是一个选项? -
这是一个选项,这就是我现在所做的,以解决当前的问题。但这(或至少感觉)不太优雅,因为它杀死了工作进程,而不是按照预期的方式发送停止信号。如果这被证明是进行部署的最佳方式,那么 Symfony 文档具有误导性,应该更新,因为它根本没有警告这一点。
-
也许这会有所帮助:在幕后,这个命令会向每个工作人员发送一个应该退出的信号。但是工人很聪明:他们不会立即退出,他们会完成他们正在处理的任何消息然后退出:优雅的退出。为了发送这个信号,Symfony 实际上在缓存系统中设置了一个标志——每个工作人员都会检查这个标志。如果你有一个多服务器设置,你需要确保你的 Symfony “应用程序缓存” 存储在 Redis 或 Memcache 之类的东西而不是 fs 中,以便每个人都可以读取这些密钥。 symfonycasts.com/screencast/messenger/deploy-restarting