死信队列是什么
消息被反复消费仍失败时，如果无限重试会一直占用消费资源、阻塞后续消息，甚至把整条链路拖住。死信队列（DLQ）的做法是把这类消息转移到独立通道隔离保存，主流程继续推进，之后由人工或工具修复原因再重投。它本身不解决问题，只是一个可控的暂存区：如果没有告警、没有查看手段、没有重投工具，死信队列就等同于消息黑洞——消息看起来被处理了，实际永远停在那里。
基本信息
| 触发条件 | 重试次数耗尽、反序列化失败、业务校验持续拒绝 |
|---|---|
| 处理方式 | 告警 → 排查原因 → 修复后重投原队列 |
| 保留策略 | 设置保留期与容量上限，超限转归档，避免无限堆积 |
| 分类 | 区分可重试（依赖故障）与不可重试（数据问题） |
| 权限 | 重投工具限制可操作角色，操作留痕 |
典型使用场景
- 消息格式异常：上游发来的字段缺失或格式不符，反复消费失败
- 依赖长期不可用：下游修复后批量重投积压消息
- 业务校验拒绝：订单状态不允许该操作，需要人工介入处理
- 第三方接口变更：外部返回结构变化导致处理失败
- 批量任务部分失败：失败条目单独隔离，其余正常完成
- 补偿任务失败：补偿动作重试超限后进入死信待人工处置
死信治理要点
死信治理要点
# 1 配置：接收次数上限（如 3 次）、TTL 与目标死信队列
# 2 告警：新死信立即告警，附带消息 ID、失败原因与首次失败时间
# 3 分类：可重试（超时、限流）与不可重试（数据错误）分开处理
# 4 修复：提供查看与重投工具，重投前确认消息未被他处处理
# 5 幂等：接收方按消息 ID 幂等，避免重投造成重复业务
# 6 归档：保留期外的消息转对象存储，满足审计与追溯
# 7 演练：定期在预发环境走一遍重投流程，验证工具与权限可用运维要素
| 要素 | 做法 | 说明 |
|---|---|---|
| 告警 | 新死信即时通知到负责团队 | 无告警的病死信会积压数周 |
| 看板指标 | 死信产生速率、未处理数量、重投成功率 | 用于日常观察与容量评估 |
| 容量护栏 | 死信量突增视为故障信号，回查上游变更 | 突增往往先于业务报障出现 |
| 重投方式 | 原队列重投、延迟重投、改写后投递 | 按失败原因选择合适方式 |
| 权限与审计 | 限制操作角色并记录操作日志 | 避免误重投与责任不清 |
重投前先确认消息未被处理：转发与重投可能造成同一条消息两次生效，接收方必须按消息 ID 幂等，否则修复操作本身会制造重复数据。
保留期要有明确上限：无上限的死信队列会变成第二套消息系统，容量与检索成本随时间上升，同时掩盖真正的消费问题。