技术 · 开发实战
接口超时之后:重试策略怎么写才不添乱
超时就重试,看似稳妥,实则可能把故障放大。重试的次数、间隔与条件,都需要设计。
先区分失败类型
网络超时、连接被拒、服务返回错误码,性质不同。对不可恢复的错误重试没有意义,只会浪费资源。
只对幂等操作重试是基本前提。非幂等请求重放,可能造成重复扣款或重复下单。
间隔怎么定
固定间隔的重试会让所有客户端同时涌向服务,形成新的压力峰值。指数退避加随机抖动,能分散请求。抖动的作用是避免同步,让重试在时间上错开。
次数的上限
重试次数应有明确上限,并在链路各层统一,避免每层都重试导致放大。上游已重试过的请求,下游不宜再叠加。
熔断与降级
当失败率超过阈值时,应先停止重试并快速失败,给后端恢复的时间。降级方案要提前准备好,比如返回缓存数据或简化响应。
可观测性
记录重试次数与最终结果,才能在故障复盘时看清放大倍数。没有观测的重试,等于把风险藏起来。
读者留言
共 4 条 · 精选展示非幂等重放的风险,这条最要紧。
指数退避加抖动,终于知道为什么要抖。
每层都重试会放大,踩过坑。
没有观测的重试等于藏风险,说得好。