Magento 2 RabbitMQ 消费者启动后能处理一段时间，随后进程消失，队列消息继续增长。先不要默认它崩溃。消费者可能因为达到 --max-messages 正常退出，也可能被操作系统 OOM Kill、连接中断、业务异常或进程管理器停止。
确认退出是预期还是异常
bin/magento queue:consumers:list
bin/magento queue:consumers:start consumer.name --max-messages=100 -vvv在前台运行一个受控消费者，观察退出码和最后一条日志。max_messages 适合让进程定期重启、释放内存，但前提是 Supervisor、systemd 或其他进程管理器会自动拉起。只配置退出上限却没有守护进程，队列必然停止消费。
从 RabbitMQ 看 Ready 与 Unacked
管理界面或命令行中，Ready 持续增长表示消息没有被取走；Unacked 很高表示消费者已经取得消息但迟迟没有确认。后者通常指向业务处理慢、外部接口等待、数据库锁或消费者卡死。
同时观察 consumer 数量、连接、channel、redelivered 和 publish/deliver rate。连接频繁创建和断开，要检查心跳、网络、TLS、负载均衡空闲超时和 RabbitMQ 日志。
业务异常必须决定重试与失败去向
一条坏消息如果每次抛异常后立即重新入队，可能形成无限重试，占满日志并阻塞同类消息。消费者应区分暂时错误与永久数据错误，设置有限重试、退避和死信策略。消息处理还要幂等：同一消息因连接中断被再次投递时，不能重复扣款、发邮件或创建实体。
Magento 日志中记录 topic、message ID 和异常类别，但不要输出完整客户或支付数据。自定义 handler 应捕获可预期异常并保留上下文，不能只返回成功来吞掉失败消息。
内存增长要用周期指标判断
消费者是长进程。循环中保留大型对象、静态缓存、未释放的实体集合或第三方 SDK 连接，会让 RSS 持续增长。记录处理每 100 条消息后的内存，而不是只看启动值。适当 max-messages 可以降低长期碎片，但仍应修复明显泄漏。
如果进程被系统杀死，查看 kernel/OOM 日志和容器限制。提高 memory_limit 不能解决容器没有可用内存的问题。
Cron 启动消费者也有边界
Magento 可以通过 Cron 运行消费者，配置中是否等待消息、每个 consumer 最大消息数和允许列表都会影响行为。高吞吐生产环境常用独立进程管理器，以获得更稳定的重启、日志和并发控制。并发数不能盲目增加，数据库和外部系统必须承受相同吞吐。
修复后投递正常消息、可重试失败消息和永久失败消息三组测试，确认成功确认、有限重试、死信/失败记录和自动重启都符合设计。最终以队列积压能在正常流量下回落、重复业务为零作为判断。
