重试 3 次就进死信 vs 重试 8 次再进死信：「自动重试」和「业务补偿」的边界到底谁说了算？

【背景】

我带过一个 40 人的后端团队，负责支付回调 + 订单状态机链路。去年一次故障复盘，我算了一笔账：

• 自动重试配置：3 次，指数退避 1s / 2s / 4s，第 3 次失败进 DLQ（死信队列）；
• 那次故障的根因是下游风控服务发布后一个字段名改错了（risk_level → riskScore），重试 3 次全部 400，DLQ 在 15 分钟内积压了 11,000 条；
• 业务方从第 5 分钟开始打电话，SRE 从第 12 分钟开始查日志，第 28 分钟定位到字段名变更，第 41 分钟回滚 + 手动重放 DLQ；
• 全程用户侧"支付成功但订单状态没更新"的投诉：327 条。

复盘时我提了一个问题：如果重试次数从 3 次改成 8 次，这 15 分钟的 DLQ 积压还能不能避免？ 答案是：不能。因为根因不是"瞬时抖动"，而是"对端状态已经变更"，多重试 5 次只会把 400 从 3 次变成 8 次，DLQ 照样炸，只是炸得更慢。

这件事让我开始认真想：重试是"技术视角"的自愈手段，补偿是"业务视角"的兜底手段，两者的边界到底该由谁、依据什么来划？

【常见分歧：三种做法，三种哲学】

派系 A ——「重试给够，DLQ 只是极端 case」

• 重试 5~8 次，指数退避 base=2s（2s / 4s / 8s / 16s / 32s / 64s），总窗口约 3 分钟；
• 理由：绝大多数瞬时故障（GC、网络抖动、连接池耗尽）在 30s 内自愈，多给几次重试是"免费"的；
• DLQ 只留给"真失败"，人工处理是最后手段；
• 风险：如果根因是"对端状态已变更"（字段改名、权限回收、对端已回滚），多重试 5 次 = 多 5 次无意义调用 + 延迟发现根因。

派系 B ——「3 次就该停，第 4 次大概率是"真失败"」

• 重试 3 次（1s / 2s / 4s），第 3 次失败立刻进 DLQ + 触发告警；
• 理由：瞬时故障的自愈窗口通常在 5~10s 以内，超过 3 次（约 7s）还没恢复，大概率不是"瞬时"问题；
• 继续重试是"用 CPU 和带宽掩盖问题"，而且每次重试都可能产生副作用（非幂等接口）；
• 风险：如果下游真的只是慢（比如批处理任务占满 CPU，10s 后恢复），3 次重试全部失败，本可以自愈的 case 进了 DLQ。

派系 C ——「重试和补偿并行，不是串行」

• 重试在跑的同时，补偿逻辑（回滚、对账、通知）已经开始准备；
• 理由：重试是"乐观"的，补偿是"悲观"的，两者不互斥；
• 风险：如果重试最终成功了，补偿逻辑已经执行了一半，回滚补偿本身又引入新的不一致——"补偿的补偿"问题。

【我的倾向：3 次 + 第 3 次失败后 200ms 内启动"补偿评估"，但不是立刻执行补偿】

具体设计（我们线上跑了 2 年的方案）：

1. 重试策略：3 次，指数退避 1s / 2s / 4s，总窗口约 7s；
2. 第 3 次失败时的动作（不是"进 DLQ 就完了"）：
   • 立刻写一条 failure_event 到内部事件总线（不是 DLQ，DLQ 是最后手段）；
   • failure_event 携带：原始请求快照、3 次重试的时间戳和响应码、调用链 traceId；
   • 触发一个补偿评估器（一个轻量异步任务），在 200ms 内完成以下判断：
     • 错误码是否命中"可重试白名单"（如 503、504、连接超时）→ 如果是，额外给 1 次"宽限重试"（间隔 30s），总计 4 次；
     • 错误码是否命中"不可重试黑名单"（如 400、401、403、422）→ 直接进 DLQ + 告警；
     • 其他错误码 → 进 DLQ，但标记为"待人工评估"，告警级别降一级；
3. DLQ 消费：不是"等人工去捞"，而是有一个定时任务每 5 分钟扫一次 DLQ，自动重放标记为"宽限重试"的条目；真正需要人工的（黑名单命中）才推工单。

为什么是 3 次而不是 5 次或 8 次？ 核心数字：我们统计了过去 12 个月的 2.3 万次重试事件，其中：

• 第 1 次重试就成功的：71.2%；
• 第 2 次重试才成功的：18.4%；
• 第 3 次重试才成功的：6.1%；
• 3 次都失败的：4.3%（其中 82% 是"对端状态已变更"类，继续重试无意义）。

也就是说，3 次重试已经覆盖了 95.7% 的"瞬时故障"场景，第 4 次及以后的重试，ROI 急剧下降。

【补充一个之前没展开的坑：宽限重试（第 4 次）的真实 ROI】

2025 Q1 我们给"宽限重试"（第 3 次失败 + 30s 后第 4 次）单独打了一个 tag，跑了 4 个月，1,284 次宽限重试里成功了 41 次（3.2%）。拆开看这 41 次的根因：

• 28 次（68%）是"下游 GC 抖动 30s 内恢复"类（Full GC 20~40s，第 4 次刚好赶上恢复窗口）；
• 9 次（22%）是"连接池耗尽后 30s 内归还"类（HikariCP pending 排队，30s 后连接归还）；
• 4 次（10%）是"网络抖动"（跨机房链路丢包，30s 内恢复）。

关键结论：宽限重试的 ROI 是 3.2%，但这 3.2% 全部是"下游会自己恢复"的场景——也就是说，宽限重试救的不是"对端状态变更"（那 82% 的黑名单 case 它救不了），救的是"对端只是慢"。所以宽限重试必须和错误码白名单绑定（只对 503/504/超时给），不能对所有错误码无差别给——否则 82% 的黑名单 case 会被白白多等 30s，DLQ 积压时间被拉长。

【另一个坑：补偿评估器本身会失败】

之前说"200ms 内启动补偿评估器"，这个 200ms 是乐观值。我们 2024 年 Q4 一次事件总线积压（Kafka 消费 lag 涨到 200k），补偿评估器的实际启动延迟到了 8~15s。这 8~15s 里，业务方已经打电话了，SRE 已经在查日志了，但"补偿评估"还没跑。

落地建议：补偿评估器必须有超时兜底——如果 5s 内没启动，直接走"保守路径"（进 DLQ + 告警），不要等评估器。宁可"误进 DLQ"（人工 5 分钟处理），也不要"评估器卡住"（业务方等 15 分钟）。这条写进 runbook 里：补偿评估器超时 5s = 视为失败，走 DLQ。

【想听大家聊的：】

1. 你们的 DLQ 平均积压时间是多少？ 从"进 DLQ"到"人工处理完"，中位数和 P95 分别是多少？如果 P95 > 30 分钟，你的补偿策略是不是该提前介入？

2. 补偿逻辑的触发条件，你们卡在哪几个参数上？ 是重试次数、时间窗口、错误码白名单、还是业务 key 的"未确认消息量"？有没有"重试成功但数据已脏"的 case（比如第 2 次重试成功，但第 1 次重试已经在下游写了一半）？

3. 派系 C（重试和补偿并行）你们试过吗？ 如果试过，"补偿的补偿"问题怎么解的？有没有用"补偿幂等键"来兜底？

4. 一个更尖锐的问题：你的团队里，"重试次数"这个参数是谁定的？是写代码的开发者、SRE、还是业务方？如果三个人定出来的数字不一样，最终以谁为准？

5. 新加一条：你们的"补偿评估器"（或等价的"失败分类器"）本身有没有监控？它自己的启动延迟、处理延迟、失败率，你们有没有单独的告警？还是说它"挂了"你们都不知道，直到业务方打电话？

这个话题没有标准答案，但一定有"踩坑后的共识"。欢迎把你们的数字和 case 贴出来，尤其是那些"重试成功了但数据不对"的——这种 case 最值钱。