死信队列

无法处理的消息转入死信通道隔离保存,主流程继续推进;死信要有告警、查看手段与重投工具,否则等同于消息黑洞。

触发重试耗尽、反序列化失败、业务校验持续拒绝
处理死信告警、人工或工具修复后重投原队列
保留设置保留期与容量上限,避免无限堆积
  • 接入:配置死信策略(接收次数上限、TTL 与目标队列)
  • 告警:新死信即告警,附消息 ID、失败原因与首次时间
  • 分类:区分可重试(依赖故障)与不可重试(数据问题)
  • 修复:提供查看与重投工具,重投前确认未被处理
  • 归档:保留期外转对象存储,满足审计与追溯
  • 演练:定期在预发环境走一遍重投流程,验证工具与权限可用
重投方式原队列重投、延迟重投(等待依赖恢复)、旁路改写后投递
看板指标死信产生速率、未处理数量与重投成功率作为日常观察项
容量护栏死信量突增作为故障信号,检查上游变更与消费异常
权限控制重投工具限制可操作角色,操作日志留痕
死信重投要防重:重投前确认消息未被处理,接收方按消息 ID 幂等。

易错点

  • 死信无告警,积压数周无人知晓
  • 重投工具缺乏幂等保障,修复操作产生重复数据

数据来源与参考

  • microservices.io:Dead Letter Channel
  • AWS 文档:SQS 死信队列
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌