Symfony Messenger内存溢出致消息丢失问题排查与优化

• 内存溢出根源：Doctrine默认会将所有持久化过的实体、查询元数据全部存在UnitOfWork内存缓存中，每处理完一批客户数据没有主动清理缓存，累计处理250页约2.5万条数据后，内存占用就会触顶。另外如果开了Doctrine SQL日志、HTTP Client缓存，也会持续占用内存不释放。
• 消息丢失根源：PHP内存溢出属于致命错误，进程会直接终止，完全不会执行Messenger的消息确认、失败消息入队、事务回滚逻辑。使用的Doctrine异步驱动在拉取消息时会先给消息加锁，进程异常退出后锁没有被正常释放，也不会触发重试机制，表现出来就是消息直接丢失。
• 链式派发逻辑的可靠性缺陷：当前实现是在当前页消息处理流程中派生下一页消息，只要派生动作执行前进程崩溃，后续分页的任务根本没进入队列，新启动的worker自然找不到断点位置。

1. 先解决内存异常溢出问题 #

首先在每批客户数据写入完成后，手动清理Doctrine的UnitOfWork缓存，主动触发垃圾回收：

// createCustomers执行完成后追加
$this->entityManager->clear();
gc_collect_cycles();

其次启动worker时直接使用Symfony Messenger原生的内存限制参数，让worker在内存达到阈值前平滑退出，不要等PHP触发致命错误：

php bin/console messenger:consume async --memory-limit=128M

worker会在每处理完一条消息后主动检查内存占用，超过阈值就会走完当前消息的确认、状态标记流程再终止，完全不会出现异常崩溃导致的状态异常。
另外批量处理数据时记得关闭Doctrine的SQL日志，在配置文件中将doctrine.dbal.logging设置为false，SQL日志累计的内存占用在大批量数据场景下非常容易触顶。

2. 解决消息丢失、断点续跑问题 #

放弃当前链式派生下一页消息的逻辑，换成任务状态持久化+单步投递模式：

• 每次触发客户同步任务时，先在数据库新增一条同步任务记录，存储查询URL、所属店铺ID、当前同步页码、任务状态（进行中/已完成/失败），初始页码设为1。
• 投递的消息体里只放同步任务的ID，不直接携带页码、URL这类可变参数。
• 消费者处理消息时，先根据任务ID查询任务记录，拿到当前需要拉取的页码请求API、写入客户数据、清理完Entity Manager缓存后，先更新数据库里的任务记录，将同步页码+1持久化，再派生下一条携带相同任务ID的消息，最后标记当前消息处理完成。
• 新增一个启动时的检查逻辑，每次启动worker先扫描库中状态为“进行中”的同步任务，给这些任务重新投递消费消息，就算之前进程异常退出，也能从数据库记录的最后页码继续同步，不会丢进度。
  同时调整Doctrine队列的锁超时配置，将队列表中锁定消息的超时时间设为30-60秒，就算worker异常退出，超时的锁定消息也会自动释放回可消费队列，不会出现消息“消失”的问题。

3. 避免无效API调用 #

不需要提前把所有分页对应的消息全部预投到队列，原本“遇到已存在客户就停止同步”的逻辑可以完全保留：处理当前分页数据时如果检测到已存在的客户记录，直接将对应同步任务的状态标记为“已完成”，不再派生下一页的消费消息即可，不会产生多余的无效API请求。

内容的提问来源于stack exchange，提问作者ReeceNG