MQ消息在目标队列、回退队列与死信队列间无限循环问题咨询

先帮你拆解第二个场景的核心问题，再逐一给出针对性的解决办法：

为什么会出现无限循环？ #

这个现象本质是队列容量限制触发了默认的消息回退逻辑，再结合未确认消息的特性共同导致的：

1. 分流路径被彻底堵死：你的QB和DLQ深度都是5，处理前10条消息后，两个队列都已填满。后续消息达到回退阈值3时，队列系统发现既无法移入QB（已满），也无法移入DLQ（已满），大部分消息队列的默认行为是将消息放回原队列Q1，并重置回退计数。这就导致消息被应用再次获取、抛出异常、回退，重复这个流程，形成无限循环。
2. 停止应用后消息回退至Q1：你的应用在获取消息后抛出异常，没有发送消息确认（Ack），这些消息处于「被消费者获取但未确认」的状态。当应用停止时，队列会自动将所有未确认的消息放回原队列Q1——这是队列保证消息不丢失的核心机制。

解决方法 #

你可以从以下几个维度入手解决问题：

1. 调整队列容量（最直接的临时方案） #

根据业务预期的毒消息数量，扩大QB和DLQ的深度，避免因队列满导致消息无法分流。比如如果预计会有15条毒消息，可以将QB和DLQ的深度调整到至少10以上，确保分流路径畅通。

2. 配置DLQ溢出处理策略 #

如果你的队列系统（如IBM MQ、RabbitMQ等）支持，配置DLQ满时的处理规则：

• 若业务允许少量丢失，可设置为丢弃超出容量的消息（不推荐关键业务场景）；
• 若需要保留最新的毒消息，可设置为覆盖旧消息（比如FIFO模式下删除最早的消息）；
• 配置告警机制，当DLQ容量达到阈值时及时通知管理员清理，避免被填满。

3. 优化应用的毒消息处理逻辑 #

不要完全依赖队列的自动回退机制，在应用中主动判断消息的回退计数：

• 获取消息的BackoutCount属性（不同队列系统名称可能略有差异）；
• 当回退计数达到3时，直接将消息转存到数据库或其他持久化存储，然后发送确认，避免消息再次进入回退流程；
• 对于确定的毒消息（比如格式错误），直接记录日志后确认，不再重复处理。

4. 增加DLQ的监控与消费 #

部署专门的DLQ消费应用，或者设置定时任务，及时处理DLQ中的消息：

• 定期检查DLQ中的消息，修复可恢复的错误后重新发送到业务队列；
• 清理无法修复的毒消息，释放DLQ的容量。

5. 调整应用异常处理逻辑 #

区分可恢复异常和不可恢复异常：

• 对于网络波动等可恢复异常，使用有限次数重试，而不是直接抛出异常触发回退；
• 对于格式错误、业务逻辑无法处理的不可恢复异常，直接确认消息并记录到毒消息存储，避免占用队列资源。

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