重试机制选择指南

调用一个外部服务失败了第一反应是再试一次。这个直觉没错但「再试一次」从一句代码到生产可用的重试策略中间隔着好几层坑——每一层都是被上一层的代价逼出来的。起点固定次数重试最直觉的做法失败就重试重试 N 次还不行就放弃。foriinrange(3):try:returncall_api()except:continueraise够简单逻辑清晰。调用偶发失败的场景下完全够用。但它有两个问题。第一重试间隔是零。上一秒刚失败下一秒立刻重试被调方还没缓过来你又打过去了。如果被调方是因为过载才失败的零间隔重试等于火上浇油。第二重试会把延迟放大。一次调用 100ms重试 3 次最坏 400ms。调用方多等一会儿没关系但如果你在请求链路里这个延迟会传到用户那一端。指数退避别打太勤零间隔重试会加剧拥塞于是想到每次失败后等久一点再试。指数退避就是干这个的第一次等 1 秒第二次等 2 秒第三次等 4 秒——间隔指数增长。被调方如果是因为过载失败的给它喘息的时间别一上来就连着打。但这引入了新问题如果你有 10 个客户端同时调用同一个服务服务挂了10 个客户端都在等指数退避。第一次都在第 1 秒重试第二次都在第 3 秒重试——大家步调一致重试全挤在一起。服务刚缓过来一点一波重试又打过去又被压垮。这叫惊群效应。指数退避解决了「重试太频繁」但制造了「重试太整齐」。加抖动打散整齐的重试解决惊群的方法是给退避加随机性——抖动。本来第 2 秒重试加个随机偏移变成 1.7 秒或 2.3 秒。10 个客户端不再同时重试而是分散在一个时间窗口里。被调方收到的重试从「一波打过来」变成「陆续打过来」。抖动这步不起眼但关键。不加抖动指数退避只是把问题从「太频繁」推迟到「太整齐」加了抖动重试才真正分散开。代价是延迟变得不可预测。同一个请求你可能 2 秒重试成功也可能 5 秒才重试。对于需要确定性延迟的场景这个不可预测是新的麻烦。重试加超时一直不返回怎么办到目前为止重试策略解决的是「失败后怎么办」。但还有一个没解决「一直不返回怎么办」。被调方不一定每次都干脆地返回失败。更常见的情况是它卡住了——请求发出去不返回成功也不返回失败就这么挂着。你的重试逻辑根本触发不了因为还没收到失败信号。所以重试必须配合超时。单次调用设个超时超时了就算失败触发重试。否则一个卡住的请求能占满你的连接池后面的请求全排队。但超时设多少是个难题。设短了正常慢请求被误杀设长了故障时干等。而且超时和重试次数会叠加单次超时 3 秒重试 3 次最坏 9 秒。调用方愿意等这么久吗重试加熔断别把故障放大重试的本质是假设「失败是暂时的再试一次可能成功」。但如果被调方是真的挂了不是暂时抖动你的每一次重试都是在给一个已经死掉的服务发请求。更糟的是你的重试会放大故障。正常情况下一个请求打一次现在打三次。被调方本来就在勉强支撑重试让它雪上加霜。如果被调方还有下游重试的请求会一层层传下去把一个局部故障放大成全局雪崩。熔断就是干这个的连续失败到一定次数直接停止重试也不再发新请求快速失败。给被调方喘息的时间也保护自己不被拖死。熔断不是重试的替代是重试的刹车。没有熔断的重试是「无脑试到死」加了熔断的重试是「试几次不行就算了」。怎么选重试策略的演进是被代价一层层逼出来的固定重试太频繁 → 指数退避 → 退避太整齐 → 加抖动 → 还得防卡住 → 加超时 → 还得防放大故障 → 加熔断。但实际工程中你不需要每次都从零搭。大多数场景的答案是指数退避 抖动 超时 熔断用现成的库。Java 的 Resilience4j、Go 的 go-resilience、Python 的 tenacity都内置了这套组合。真正需要你自己想清楚的是这几个参数重试几次3 次是个常见值多了放大故障少了不够兜底。退避多久起步看被调方的恢复速度。秒级服务从 1 秒起步分钟级任务从 30 秒起步。超时设多长看调用方能接受的最长等待。链路越长单次超时要越紧给重试留余量。什么情况不重试不是所有失败都该重试。参数校验失败、权限不足重试一百次结果一样。只有「可能恢复的临时故障」才值得重试——超时、限流、网络抖动。非幂等的写操作更要慎重重试可能导致重复写入。最后一条最容易被忽略重试的前提是幂等。如果被调方不保证幂等重试可能把一次扣款变成两次。在重试之前先确认你的操作能不能安全地重复执行。