任务自动重试机制如何实现，哪些情况会触发？

核心回答

自动重试是把可恢复的失败重新调度执行，同时约束重复执行和额外负载。常见触发包括网络抖动、临时超时、下游短暂不可用，以及执行实例宕机后任务租约到期；参数错误、权限拒绝、业务条件不满足通常直接失败。

实现上先持久化任务状态、尝试次数和下次执行时间，再由工作线程领取任务。失败后按错误类型决定重试或终止，重试采用带上限的指数退避和随机抖动；超过次数或总时间预算则进入失败队列或补偿流程。整个过程通过任务 ID、业务唯一键和状态条件更新保证幂等，不能把“多执行一次”当成“多产生一次业务效果”。

从任务状态看实现

任务可经历“待执行、执行中、等待重试、成功、最终失败”。领取任务时用条件更新或锁，写入本次执行的 owner、attempt 和租约；只有领取成功者执行。失败调度与状态变更也要有可靠衔接，例如事务发件箱配合扫描补发，避免数据库已标记等待重试却没有重新入队。

队列可以只携带任务 ID，具体输入和进度放在数据库。重投消息到达时重新读取状态：已成功的任务返回已有结果；仍可执行的任务才尝试领取。Kafka 的消费位点与业务数据库不天然处于一个事务，先落业务结果再确认消息可能产生重复，因此还需要业务幂等。

实例突然宕机时，不能依靠它自己捕获异常。恢复扫描器发现执行中任务的租约过期，确认可以接管后重新调度。旧实例可能只是暂停而非死亡，恢复后仍会写结果，所以结果提交还应校验本次 owner 或递增执行代次，重要外部写入可结合接收端校验的 fencing token。

重试策略与追问

• 调用超时为什么不能直接再扣款？ 原调用可能已完成，只是响应丢失。重试沿用同一业务幂等号，并先查询最终状态；幂等记录与业务写入尽量在同一事务提交。
• 退避是否越长越好？ 太短会放大故障，太长会错过任务时效。限制单次等待、最多尝试次数和整个任务 deadline；收到明确的限流等待信息时按协议处理。
• 工作流节点与队列任务有何区别？ 节点级重试负责当前节点的短暂失败；持久化检查点负责流程恢复。恢复执行可能重跑带副作用的节点，仍需相同的幂等边界。
• 如何验证策略？ 注入连接重置、超时、提交成功但响应丢失、实例退出等故障，核对最终业务效果、重试次数、租约接管和失败告警，不能只看最终返回成功。

对应教程

参考资料