超过最大传递次数后Service Bus消息未移入DLQ的问题排查

问题场景 #

已为Service Bus队列启用死信队列（DLQ），配置最大传递次数：5、无限制消息TTL，但消息重试超过最大传递次数后被直接移除，未移入DLQ；仅设置较短TTL时，消息才会正常进入DLQ。

队列配置详情：

• 最大传递次数：5
• 消息TTL：无限制
• 消息锁定时长：1分钟
• 重复检测：已启用
• 重复检测窗口：23小时（适配长批处理任务）
• 过期消息死信：已启用
• 定价方案：Basic

测试流程：

1. 发送消息触发批处理任务
2. 接收器锁定消息并启动长任务处理
3. 终止进程模拟系统故障
4. 重启进程后消息重新投递，通过SB Explorer观察重试计数递增
5. 重复终止重启操作5次，使传递次数超过阈值

测试结果：消息超过最大传递次数后被移除，未进入DLQ。

核心原因 #

1. Basic层功能局限性：Service Bus Basic层不支持「因最大传递次数超限自动死信」的完整逻辑，仅在消息过期或被主动调用死信方法时，才会将消息移入DLQ。
2. 重复检测与TTL的交互冲突：启用长窗口（23小时）重复检测后，无限制TTL的消息在传递次数超限后，会被重复检测逻辑标记为重复投递，最终被直接丢弃，而非触发死信流程。只有当消息TTL到期触发过期死信时，才会绕过该逻辑进入DLQ。

解决方案 #

方案1：调整重复检测配置 #

• 若业务无需长窗口重复检测，可关闭重复检测功能，或缩短重复检测窗口至1小时以内。关闭后，最大传递次数超限的消息会按照预期移入DLQ。

方案2：升级至Standard层 #

• Standard层完整支持「最大传递次数超限自动死信」的逻辑，且重复检测与DLQ的交互逻辑更完善，能适配长批处理任务的场景，彻底解决该兼容性问题。

方案3：手动主动死信 #

• 在消息接收器中，通过读取消息的DeliveryCount属性跟踪传递次数，当DeliveryCount达到配置的最大传递次数阈值时，调用DeadLetterAsync方法主动将消息移入DLQ，避免消息被系统丢弃。

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