重试的数学基础：指数退避、抖动与超时设置
说实话，很多人刚开始做重试策略时，都觉得「失败了就再试一次呗，有啥好算的？」。我当年也这么想。直到有一次线上事故——下游服务短暂抖动，我们的重试像潮水一样涌回去，直接把人家打挂了。那次复盘让我明白：没有数学支撑的重试，就是一场灾难。
这一章，我们来聊聊重试背后的三个核心数学概念：指数退避、抖动、以及最大重试次数与超时的设置。搞懂了这些，你的流水线才算真正有了「抗揍」的能力。
指数退避算法详解
先问一个问题：如果第一次请求失败了，你隔多久重试？
直觉告诉我们，不能立刻重试。因为失败的原因可能是服务正忙，你马上再打过去，大概率还是失败。那等多久？1秒？2秒？还是5秒？
指数退避的思路很简单：每次重试的等待时间，按指数增长。
公式长这样：
wait_time = base_delay × (2 ^ attempt_number) + random_jitter其中：
- base_delay：基础等待时间，比如100ms
- attempt_number：当前是第几次重试（从0开始）
- random_jitter：随机抖动（后面细说）
举个例子，base_delay = 100ms：
| 重试次数 | 计算过程 | 等待时间（无抖动） |
|---|---|---|
| 0（首次） | 100 × 2^0 | 100ms |
| 1 | 100 × 2^1 | 200ms |
| 2 | 100 × 2^2 | 400ms |
| 3 | 100 × 2^3 | 800ms |
| 4 | 100 × 2^4 | 1.6s |
| 5 | 100 × 2^5 | 3.2s |
你看，前几次间隔很短，给系统快速恢复的机会；后面间隔越来越长，避免持续施压。这背后的逻辑是：如果一个小问题，几秒内没恢复，那大概率需要更长时间。
核心要点：指数退避的本质，是用「越来越长的等待」换取「系统恢复的时间窗口」。它不是惩罚，而是保护。
我在项目中见过有人把 base_delay 设成 1ms，结果前几次重试几乎瞬间发出，跟没有退避一样。我个人习惯，base_delay 至少设 50ms，生产环境常用 100ms~500ms。
抖动（Jitter）的原理与必要性
好，指数退避看起来不错。但有个坑——惊群效应。
想象一下：你有100个客户端同时调用一个服务。服务挂了，所有客户端都开始按指数退避重试。因为算法一样，base_delay 一样，它们会在完全相同的时刻发起重试。100个请求同时砸过来……服务刚缓过来，又被拍下去了。
这就是没有抖动的后果。
抖动的原理很简单：在计算出的等待时间上，加上一个随机值，让每个客户端的重试时间点错开。
常见的抖动策略有三种：
| 策略 | 公式 | 特点 |
|---|---|---|
| 全抖动 | random(0, base × 2^n) | 等待时间完全随机，范围大，分散效果好 |
| 等比例抖动 | base × 2^n + random(0, base × 2^(n-1)) | 保留指数增长趋势，加少量随机 |
| 固定抖动 | base × 2^n + random(-jitter_range, jitter_range) | 在指数结果附近波动，可控性高 |
我个人最常用的是全抖动。为什么？因为它简单粗暴，效果最好。你想想看，当系统真的出问题时，我们需要的是让所有客户端尽快错开，而不是保留什么「优雅的指数曲线」。全抖动虽然让单次等待时间不可预测，但从整体看，它最大程度避免了请求的同步峰值。
实战建议：如果使用全抖动，建议设置一个最大上限（max_delay），防止随机值过大导致用户等待太久。比如 base=100ms，max_delay=10s。
我曾经遇到过一个案例：某团队用了指数退避但没加抖动，每次服务重启后，所有客户端都在同一秒重试，导致服务反复崩溃。加了全抖动后，问题立刻消失。嗯，有时候解决问题就这么简单。
最大重试次数与超时设置
有了退避和抖动，是不是就可以无限重试了？当然不是。
你想想看，如果下游服务真的挂了，你重试100次也没用。不仅浪费资源，还会让调用方（比如用户）等到天荒地老。所以，必须设置上限。
两个关键参数：
- 最大重试次数（max_retries）：最多重试几次
- 总超时时间（total_timeout）：从第一次请求到最终放弃，最多等多久
这两个参数怎么设？我一般遵循三个原则：
- 重试次数不超过3~5次。超过5次，成功率提升微乎其微，反而增加系统负担。
- 总超时时间不超过用户可接受等待时间的1/3。比如用户能等3秒，你的重试总时间就别超过1秒。
- 重试次数 × 单次超时 ≤ 总超时。这个不等式必须成立，否则会出现「总超时还没到，重试次数已经用完」的尴尬情况。
举个例子：
base_delay = 200ms
max_retries = 4
total_timeout = 5s
# 计算最坏情况下的总耗时（无抖动）
总耗时 = 200ms + 400ms + 800ms + 1.6s + 3.2s = 6.2s
# 6.2s > 5s，超了！
# 需要调整：要么减少重试次数，要么缩短 base_delay注意：加了抖动后，实际等待时间可能更长。所以计算总超时时，建议按「最大可能等待时间」来算，留出余量。
我习惯用一个简单的表格来快速决策：
| 场景 | base_delay | max_retries | total_timeout |
|---|---|---|---|
| 内部服务调用（低延迟） | 50ms | 3 | 2s |
| 外部API调用（中等延迟） | 200ms | 4 | 10s |
| 文件上传/下载（高延迟） | 1s | 3 | 30s |
当然，这只是起点。实际生产环境，你需要根据监控数据不断调整。我记得有一次，我们把某个接口的 max_retries 从3改成2，成功率反而上升了——因为减少了无效重试，下游压力小了，正常请求反而更快了。
知识体系总览
下面这张图，把这一章的核心逻辑串起来了：
说白了，指数退避、抖动、上限控制，这三者是一个整体。指数退避决定「等多久」，抖动解决「大家一起等」的问题，上限控制告诉你「等到啥时候是个头」。缺一个，你的重试策略就是定时炸弹。
好了，这一章的内容就到这里。记住：重试不是简单的「失败了再来一次」，而是一门关于等待的数学。搞懂了这些，你的流水线才算真正有了「抗揍」的能力。