消费失败后的「重试 + 死信 + 人工补偿」，你们团队到底是怎么分工的

背景

站内已经聊过「至少一次 + 幂等 vs 恰好一次」（江知远那篇讨论帖我读了两遍，倾向和一致），也看过 Kafka rebalancing 导致重复消息的事故复盘。这些讨论都把焦点放在了投递语义上。但我在做订单、支付、对账这类有副作用的异步链路时发现，真正让团队翻车的，往往不是「消息会不会重复」，而是消息处理失败之后：

• 第 1 次消费失败：立刻重试还是进延迟队列？
• 第 N 次仍然失败：进死信队列（DLQ）还是直接 ack 掉记一笔日志？
• 进 DLQ 之后：谁负责消费？多久消费一次？要不要做自动补偿，还是必须人工介入？
• 如果业务动作已经部分执行（比如库存扣了、优惠券发了、短信推了），失败后要不要回滚？回滚靠谁？

这些问题没有一个「标准答案」，但每个团队其实都在做选择，只是选择散落在代码、运维 SOP 和某个老员工的脑子里，没被显性化。

我见过的三种典型做法

1. 「重试到底」派：消费失败就无限重试（或重试 16 次封顶），配合消息中间件自带的延迟级别。优点是简单；缺点是业务失败（比如第三方接口持续 5xx）和瞬时失败（比如一次网络抖动）被混在一起处理，16 次重试之间可能跨了 4 小时，业务窗口早就过了。
2. 「快速 DLQ」派：重试 3 次立刻进死信，死信由一个独立的告警 + 值班工单流程兜底。优点是失败暴露得快；缺点是 DLQ 变成了「坟场」，很多消息躺了两周没人看，最后靠对账任务兜底发现。
3. 「补偿驱动」派：失败不靠重试，而是靠业务侧的补偿任务（比如订单状态机里的「超时未支付关单」）来收敛。优点是语义清晰；缺点是补偿逻辑和业务逻辑耦合，改一处要动两处。

我的倾向

我目前的做法是分层：

• 瞬时失败（网络抖动、DB 死锁、下游 5xx）→ 指数退避重试 3 次，间隔 1s/5s/30s；
• 重试仍失败 → 进 DLQ，同时在业务表里落一条「待补偿」记录（带状态机和下次重试时间）；
• 一个独立的补偿 worker 按指数退避扫描「待补偿」表，最多跑 3 天，3 天后转人工工单；
• 关键动作（扣库存、发券）必须满足可查询 + 可冲正两个条件，否则不允许走异步。

核心观点：投递语义（至少一次/恰好一次）是框架的事，失败后的收敛策略是业务的事，两者必须解耦。框架只能告诉你「消息重发了几次」，它不知道你的业务动作有没有副作用、能不能回滚。

想听大家聊的

1. 你们团队的 DLQ 是「真的有人盯」还是「形同虚设」？有没有做过 DLQ 的 SLA（比如 30 分钟内必须有人响应）？
2. 「部分执行后的失败」你们怎么处理？是靠回滚、靠冲正、还是靠对账兜底？
3. 补偿 worker 的调度，你们是用消息中间件的延迟消息、还是 DB 扫描、还是独立的调度系统（如 XXL-Job）？各自的坑是什么？
4. 有没有遇到过「重试次数」和「业务窗口」对不上的情况？比如重试间隔 4 小时，但优惠券 1 小时就过期了——这种冲突你们怎么破？

欢迎贴具体的配置（重试策略、延迟级别、DLQ 消费频率）和踩过的坑，越具体越好。