没有 DLQ 的 workflow,失败任务会污染主队列;只有 DLQ 但没有分诊规则,失败任务会永久堆积。真正可运营的系统需要“隔离 + 分诊 + 恢复”闭环。
DLQ 设计目标
- 隔离不可自动恢复任务
- 保留足够证据支持复盘
- 提供受控回放入口
DLQ 的核心不是存储,而是恢复治理。
分诊分层
| 类别 | 处理方式 |
|---|---|
| 数据问题 | 补充字段后重放 |
| 依赖问题 | 等待外部恢复再重试 |
| 策略问题 | 规则修正后批量回放 |
| 代码缺陷 | 修复版本后灰度回放 |
把不同问题混在同一重试策略里,通常会造成二次故障。
失败案例:DLQ 批量重放触发风暴
某团队在外部依赖尚未恢复时批量回放 DLQ,导致同类失败再次挤爆队列。修复后引入“回放前置条件”和并发闸门,恢复过程稳定许多。
Checklist
- DLQ 入队原因结构化
- 每类失败有分诊 owner
- 回放前必须校验前置条件
- 批量回放支持并发限流
- DLQ 老化任务有升级机制
延伸阅读:


