消息队列死信队列设计：从异常分类到自动补偿

死信队列不是垃圾桶，是故障诊断室

消费失败的消息去哪？多数团队的答案是一个从没人看过的死信队列（DLQ）——消息堆积、无人处理、直到磁盘爆了才发现。死信队列的正确设计：每条死信都有明确的分类、告警路径与补偿预案。它不是「失败消息的堆放地」，是消费链路的最后一道质量防线。

一、什么消息会进死信

先分类再处理——不同原因的死信，处置完全不同：

1. 业务异常（消息本身有问题）：格式错误、字段缺失、业务规则不满足——重试没用，需要人工修复或直接丢弃；
2. 瞬时异常（环境抖动）：下游超时、数据库死锁、网络闪断——重试大概率成功，但超过重试上限后进死信；
3. 毒消息（Poison Message）：反复让消费者崩溃的消息（如触发 OOM 的超大 payload、死循环逻辑）——继续消费会阻塞整个分区，必须立刻隔离；
4. 消费超时：处理时间超过最大允许时长——可能是消费者性能问题或消息本身需要拆分。

设计要点：死信消息必须携带元数据（原始 topic、分区、offset、失败原因、异常堆栈、重试次数、首次失败时间）——没有这些，死信就是黑盒。

二、重试策略：不进死信前的三级过滤

```

消息消费失败 → 本地重试 3 次（立即，间隔 0s/1s/2s）

→ 仍然失败 → 进重试 topic（延迟递增：10s/30s/1min/5min/30min）

→ 超过最大重试次数 → 进死信 topic

```

1. 本地重试：瞬时异常（网络抖动、短暂超时）在这一层消化，不进重试队列；
2. 延迟重试 topic：独立于主 topic，按延迟等级分层（RocketMQ 延迟消息天然支持 / Kafka 用重试 topic + 时间轮）——注意重试期间主 topic 的消费不能停，否则一条毒消息阻塞整个分区；
3. 重试次数与死信阈值：可重试异常给 10~16 次重试机会；业务异常（不可重试）直接进死信不重试——别用 10 次重试去测一条格式错误的消息。

三、死信的监控与告警

1. 堆积告警：死信 topic 的消息数超过阈值（如 100 条）触发告警——按业务重要性分级（核心链路电话告警）；
2. 分类看板：按失败原因分组统计——某类异常突增通常是下游故障的前兆信号（比下游自己的告警更早）；
3. SLA 定义：每类死信写明响应时限（核心链路 30 分钟内介入，非核心 24 小时）。

四、补偿通路：从死信恢复的三种方式

1. 一键重放：修复下游故障后，把死信消息按原始 topic 重发——消费者必须幂等（同一消息消费两次结果一致），否则重放会引发重复入账；
2. 修复后重放：业务异常类死信，修复消息体（改字段、补数据）后再重放——需要工具链支持（消息编辑器或脚本化处理）；
3. 人工兜底：无法自动补偿的死信（数据已过期、业务已关闭）走人工处理流程——记录处理结果，不是直接丢弃。

关键设计：重放操作必须幂等且可审计——谁在什么时间重放了哪些消息、处理结果是什么，写进操作日志。

五、实战架构

```

消费者 → 本地重试(3) → 重试 topic(分层延迟, 最多 10 次) → 死信 topic

↓

监控告警（分类 + 堆积）

↓

诊断工具（查看元数据 + 异常）

↓

补偿工具（重放 / 修复后重放 / 人工）

```

工具链配套：没有诊断工具的死信队列等于没有——至少提供一个 Web 界面能查看死信列表、按原因过滤、预览消息内容、一键重放。自建可用 Kafka UI / RocketMQ Console 改造；云上用消息队列自带控制台。

死信队列的成熟标志：任何一条消息丢失都能追溯到它进了死信、被谁处理、处理结果如何。做到这个，消息系统的「至少一次送达」才真正闭环。