Shell脚本重试策略：指数退避与固定间隔到底怎么选

在写批量任务脚本的时候，重试间隔到底该怎么定，是很多人都会纠结的问题。固定间隔省心，指数退避聪明，但到底哪种更适合你的场景？今天把两种策略掰开了说，结合实际脚本例子，让你看完就能选对、用对。

固定间隔重试：简单可靠的稳妥之选

固定间隔重试的逻辑很简单：每次失败之后，等同样的时间再试。比如间隔5秒，最多重试3次，那顺序就是：0s失败 → 等5秒 → 重试 → 失败 → 等5秒 → 重试 → 失败 → 等5秒 → 重试 → 最终放弃。

这种策略最大的优点是行为可预测。不管是调试还是写文档，跟别人解释起来都很容易。实现代码也很简洁，不需要算什么指数，直接一个 sleep 加循环就够了：

固定间隔适合什么场景？当故障原因是可预期、可控的时候。比如数据库维护窗口、网络切换这类有固定恢复时间的场景，重试间隔和故障恢复时间匹配，成功率就很高。但如果系统压力本身就大，固定间隔反而会让多个客户端同时重试，形成「重试风暴」，把本来快恢复的系统又压垮。

指数退避重试：智能等待的流量保护

指数退避的核心思路是：失败次数越多，等待时间越长。间隔按指数增长，比如初始1秒，乘以2倍，顺序就是：1s → 2s → 4s → 8s。这么设计的目的很明确——给故障服务喘息的空间，避免被大量重试请求淹没。

但光有指数增长还不够，实战中有个关键技巧叫抖动（jitter）。纯指数退避有个隐患：多个客户端同时失败后，会在同一时刻一起重试，这就是「惊群效应」。加上随机抖动后，每次等待时间在固定值上下浮动，客户端的请求就自然错开了。

抖动有两种常见写法。上面用的是完全随机抖动（full jitter），等待时间在 0 到当前间隔之间随机选。另外还有均匀抖动（equal jitter），在间隔的 50%~100% 之间取值，波动更小。完全随机抖动对分散并发请求效果最好，均匀抖动则更平稳，具体选哪个看你的业务场景。

两种策略横向对比

下面从几个关键维度把两种策略放在一起看：

• 实现复杂度：固定间隔几行代码搞定，指数退避要多写几行计算逻辑和随机数。
• 资源友好度：固定间隔在高并发场景容易引发重试风暴，指数退避+抖动能有效缓解这个问题。
• 响应速度：固定间隔在故障快速恢复时更快（不用等越来越长的间隔），指数退避首次重试也快，但后续会越来越慢。
• 适用场景：固定间隔适合故障恢复时间可预期的场景；指数退避适合调用外部 API、数据库连接等不稳定服务的场景。

实战建议：不要非此即彼

选策略不是选边站，很多成熟的做法是把两者结合起来。最常见的模式是：设置一个较小的初始间隔（比如1秒），用指数退避增长，但同时设置最大间隔上限（比如30秒），避免等太久。抖动一定要加，幅度根据并发客户端数量调整——客户端越多，抖动范围越大效果越好。

另外还有两个实战细节值得注意。一是最大重试次数和总超时时间要同时限制，防止指数退避把整个重试过程拖得太长。二是根据退出码判断是否值得重试，有些错误（比如权限不足、参数错误）是重试也没用的，这类情况直接失败比傻等更合理。

如果你用的是 timeout 命令配合重试，可以参考这篇《Shell脚本指数退避重试策略完整配置》里的实操配置，模板直接改改参数就能用。

两种策略没有绝对优劣，关键是搞清楚故障的特性和你的目标。追求响应快、故障可预期 → 固定间隔；追求系统稳定、防止雪崩 → 指数退避。搞懂了原理，选起来就不难了。

相关文章：
Shell脚本指数退避重试策略完整配置
bash timeout自动重试循环脚本
xargs并行处理任务失败自动重试配置