Symfony Messenger Worker 怎样限制单次处理数量

Symfony Messenger 的 Worker 默认会持续运行，直到收到停止信号或进程本身退出。要限制“单次启动最多处理多少条消息”，使用 messenger:consume --limit；要控制运行时长和资源回收，再分别使用 --time-limit 与 --memory-limit。三个参数解决的是不同边界，退出后应由 Supervisor 或 systemd 拉起新的 Worker。

官方地址：https://symfony.com/doc/current/messenger.html

为什么 Worker 不能无限常驻

现场通常是这样的：队列可以正常接收消息，Worker 也没有立即报错，但进程长时间不退出，内存逐渐上涨，部署时还容易留下旧消费者。此时先不要把“持续运行”当成异常。Symfony Messenger 的消费命令本来就是常驻 Worker，真正需要设计的是它何时退出、退出后由谁重新启动。

一条消息会经过 Receiver、Message 和 Handler 等组件。Worker 负责持续消费，Supervisor 或 systemd 负责托管进程；这两层职责不要混在 Handler 里。Handler 只处理业务消息，不能靠业务代码的某个分支来替代 Worker 生命周期策略。

用 --limit 控制单次处理数量

--limit 表示 Worker 处理达到指定消息数后退出。它回答的是“这一轮最多处理多少条”，不是“整个队列最多允许多少条”。例如部署时希望进程处理 100 条后回收，可以这样启动：

# 处理 100 条消息后退出，把新进程交给进程管理器拉起
php bin/console messenger:consume async --limit=100 -vv

# 只设置消息数上限，不把它误写成队列容量上限
php bin/console messenger:consume async --limit=100

如果队列暂时没有足够消息，Worker 不会因为“还没达到 100”就凭空完成任务；它仍然受消费等待、停止信号和其他生命周期条件影响。--limit 也不负责限制并行 Worker 的总数，多个消费者需要由 Supervisor 或 systemd 单独配置。

把三个生命周期参数分工写清楚

消息数量、运行时间和内存增长是三种不同的风险。把它们写在同一条命令里并不表示它们含义相同，而是让 Worker 在任一退出条件满足时结束当前进程：

生产环境可以把它们组合起来：

# 用三类边界约束一轮 Worker，具体数值按任务耗时和资源预算调整
php bin/console messenger:consume async \
  --limit=100 \
  --time-limit=3600 \
  --memory-limit=256M \
  -vv

这里不要把 --memory-limit 当作 PHP 全局内存配置的替代品，也不要认为 --time-limit 会在每一条消息中途强行切断业务代码。它们是 Worker 的生命周期边界；长消息仍应设计幂等、可重试和安全停止。

让 Supervisor 或 systemd 接管退出后的重启

Worker 达到限制后退出，只有在外部进程管理器负责重启时，这个策略才会形成闭环。最小的 Supervisor 配置可以把命令、进程数量和自动重启放在一起：

[program:messenger-worker]
; 每个进程处理固定消息数，退出后由 Supervisor 重新拉起
command=php /srv/app/bin/console messenger:consume async --limit=100 --time-limit=3600 --memory-limit=256M
; 让异常退出或达到生命周期上限的进程自动重启
autorestart=true
; 同时运行的消费者数量按队列吞吐和下游承载能力调整
numprocs=2
; 把标准输出交给日志系统，避免业务日志散落在进程目录
stdout_logfile=/var/log/messenger-worker.log

如果使用 systemd，核心思路相同：ExecStart 启动 Messenger Worker，Restart=always 负责拉起新进程。修改 unit 文件后记得执行 daemon-reload，再重启对应服务。不要把“重启成功”写成消息已经处理成功；真正的处理结果仍由消息确认、失败处理和业务幂等保证。

按场景选择参数，避免只改一个数字

• 开发环境：先用较小的 --limit，方便观察 Handler 是否留下连接、缓存或文件资源。
• 常规生产任务：用 --limit 做周期回收，再加 --time-limit 防止低流量时进程长期不轮换。
• 内存敏感任务：补充 --memory-limit，并由 Supervisor 或 systemd 负责新进程接替。
• 耗时很长的消息：不要只降低 limit；先检查传输层的可见性、消息幂等和安全停止策略。

排查时可以按“命令参数—Worker 退出—进程管理器重启—消息业务结果”四层记录。这样能区分是限制参数没有生效、进程管理器没有接管，还是 Handler 本身失败，避免看到 Worker 退出就误判为丢消息。

相关问题

只设置 --limit，不设置 --time-limit 可以吗？

可以。它只按处理数量设置退出条件；如果低流量时消息数长期达不到上限，进程仍可能持续运行。需要周期轮换时，再加时间边界。

Worker 达到 --memory-limit 后会丢掉当前消息吗？

不能用这个参数替代消息确认和失败策略。应按传输组件的语义设计幂等与重试，并让进程管理器负责新 Worker 的接替；具体行为以当前 Symfony 版本和传输实现文档为准。

为什么设置了 --limit，进程却没有立刻退出？

先确认参数传给了实际运行的 messenger:consume 命令，再看 Worker 是否真的处理到了指定数量；同时检查是否已有停止信号、长消息或外部进程管理器在重启它。