分布式任务失败后如何重试？重试设计要注意什么？

简化版

分布式任务失败后可以按固定次数、延迟退避、人工重跑或补偿任务进行重试。重试设计要区分可重试和不可重试错误，控制次数和间隔，保证任务幂等，并配合告警、死信记录和人工处理入口。

详细版

任务失败重试不能无脑立即重试。合理设计包括：

1. 错误分类：网络超时、临时限流适合重试；参数错误、数据非法不适合反复重试。
2. 次数限制：避免无限重试打爆下游。
3. 退避策略：例如 1 分钟、5 分钟、30 分钟逐步延迟。
4. 幂等保障：重试可能重复执行，业务必须幂等。
5. 告警机制：超过重试次数后通知负责人。
6. 失败记录：保存任务参数、错误堆栈、执行节点和 TraceId。
7. 人工补偿：提供后台重跑、跳过、修正参数入口。

核心原则：重试是为了处理临时故障，不是掩盖业务错误。

完整版教学

一、为什么重试不能简单粗暴

失败重试看起来简单：失败了再跑一次。但在分布式系统里，无脑重试可能把小故障放大。

比如下游支付渠道已经限流，任务还在每秒疯狂重试，就会让限流更严重。又比如参数本身错误，重试一百次也不会成功，只会制造告警噪声和资源浪费。

所以重试设计第一步不是写循环，而是判断错误是否值得重试。

二、哪些错误适合重试

可以把错误分成三类：

错误类型	是否适合重试	示例
临时故障	适合	网络抖动、连接超时、下游短暂 503
资源限制	谨慎重试	下游限流、数据库繁忙
永久错误	不适合	参数非法、业务状态不允许、数据不存在

临时故障重试有意义，永久错误应该直接失败并告警或进入人工处理。

三、重试间隔如何设计

常见重试策略有固定间隔、指数退避和分级延迟。

固定间隔简单，但容易形成流量脉冲。例如 1000 个任务同时失败，1 分钟后又同时重试，会再次冲击下游。

指数退避更平滑：

第 1 次：1 分钟后
第 2 次：5 分钟后
第 3 次：15 分钟后
第 4 次：30 分钟后

还可以加入随机抖动，避免大量任务在同一时刻重试。

四、重试和幂等必须绑定

只要有重试，就必须考虑重复执行。

例如一个转账补偿任务调用外部接口时，请求已经到达外部系统，但本地等待响应超时。本地不知道对方是否处理成功，如果直接重试，可能造成重复转账。

这类场景要使用业务流水号。外部系统根据同一个流水号保证只处理一次；本地也要记录流水状态，重试时查询或复用同一流水。

五、超过重试次数怎么办

超过重试次数后，不应该静默丢弃。常见处理方式包括：

1. 标记任务最终失败。
2. 写入失败表或死信队列。
3. 触发告警，通知 owner。
4. 提供人工查看和重跑入口。
5. 对关键任务建立对账和补偿机制。

例如支付对账任务失败，不能只是日志里打一行错误。它关系到资金，应进入异常账单池，由系统自动补偿或人工确认。

六、常见误区与追问

这道题要紧扣「任务失败重试」本身回答，不能把它混成泛泛的分布式任务调度套话。面试官通常会沿着“为什么需要、流程怎么走、失败怎么兜、代价是什么”继续追问，所以回答要覆盖调度触发、分片分配、抢占锁、失败重试、超时控制、幂等和高可用。

回答层次	要讲清的内容	容易漏掉的边界
核心结论	任务失败重试要区分临时故障和确定性错误，设置次数、间隔、退避、告警和人工补偿	不要停在名词解释
流程机制	任务执行失败 -> 分类错误类型 -> 按策略延迟重试 -> 超过次数告警 -> 进入失败队列 -> 人工或补偿处理	要说清触发点、状态变化、确认点和失败兜底
工程取舍	调用下游超时可重试 3 次并指数退避，参数格式错误重试 100 次也不会成功	任务调度提升自动化和吞吐，但必须处理重复执行、漏执行、积压、超时和故障恢复

任务失败重试 面试拆解：
1. 任务执行失败
2. 分类错误类型
3. 按策略延迟重试
4. 超过次数告警
5. 进入失败队列
6. 人工或补偿处理

记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「任务失败重试」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。

• 误区：失败任务无限重试最可靠。 确定性错误无限重试只会浪费资源并阻塞后续任务。
• 误区：所有异常都用同一种重试策略。 网络超时、限流、参数错误和业务冲突应区别处理。
• 误区：重试成功就不用记录。 重试次数、耗时和原因是稳定性分析的重要证据。
• 追问：重试间隔怎么设？ 常用指数退避加随机抖动，避免集中打爆下游。
• 追问：失败超过上限怎么办？ 告警、进入失败表或死信队列，人工修复后补偿。
• 追问：如何避免重复副作用？ 所有可重试任务必须先做幂等设计。

七、加强记忆

重试的正确姿势是“先分类，再限次，再退避，最后兜底”。能重试的是临时故障，不能重试的是业务错误；所有重试都要建立在幂等之上，并且失败到底后必须可告警、可追踪、可人工处理。