随机退避：让重试更聪明

一、问题的起点

在分布式系统中，网络抖动、服务限流、数据库超时无处不在。面对失败，最直觉的做法是：立刻重试。但这恰恰是最危险的做法。

设想一台后端服务因为短暂过载而返回503，此时同时连接它的 1000 个客户端立刻全部重试——这一波整齐划一的"报复性请求"会再次压垮服务，周而复始，形成重试风暴（Retry Storm），让本可自愈的系统永远无法恢复。

随机退避（Random Backoff）正是解决这一问题的标准武器。

二、核心思路

2.1 固定等待：治标不治本

importtime,requestsdefretry_fixed(url,retries=5,wait=2.0):forattemptinrange(retries):try:resp=requests.get(url,timeout=5)resp.raise_for_status()returnrespexceptExceptionase:print(f"第{attempt+1}次失败：{e}")ifattempt<retries-1:time.sleep(wait)# 所有客户端同步等待 2 秒，再同步冲击raiseRuntimeError("超过最大重试次数")

固定等待解决了"立即重试"的问题，但每个客户端等待时长完全相同，重试依然是同步的——洪峰被推迟了，但并没有打散。

2.2 指数退避：让等待时间增长

defretry_exponential(url,retries=6,base=0.5,cap=30.0):forattemptinrange(retries):try:resp=requests.get(url,timeout=5)resp.raise_for_status()returnrespexceptExceptionase:wait=min(cap,base*(2**attempt))print(f"第{attempt+1}次失败，等待{wait:.2f}s")ifattempt<retries-1:time.sleep(wait)raiseRuntimeError("超过最大重试次数")

等待时间：0.5 → 1 → 2 → 4 → 8 → 16秒，指数递增，给下游更多喘息时间。但问题仍在：所有客户端的等待序列完全一样，重试依然扎堆。

2.3 随机抖动（Jitter）：打散洪峰

最重要的一步，在等待时间中引入随机性：

importrandomdefretry_with_jitter(url,retries=6,base=0.5,cap=30.0,jitter=1.0):""" 指数退避 + 全随机抖动（Full Jitter） wait = random(0, min(cap, base * 2^attempt)) """forattemptinrange(retries):try:resp=requests.get(url,timeout=5)resp.raise_for_status()returnrespexceptExceptionase:ceiling=min(cap,base*(2**attempt))# Full Jitter：等待时间在 [0, ceiling] 内均匀随机wait=random.uniform(0,ceiling)print(f"第{attempt+1}次失败，等待{wait:.2f}s（上限{ceiling:.1f}s）")ifattempt<retries-1:time.sleep(wait)raiseRuntimeError("超过最大重试次数")

1000 个客户端同时失败后，每个人的等待时间各不相同，重试请求被均匀散布在整个时间窗口内，后端看到的是平稳的流量，而非脉冲。

三、四种 Jitter 策略对比

AWS 在 2015 年发表了一篇经典博文，系统比较了四种策略，这里用 Python 还原它们：

importrandom,mathdefbackoff_naive(attempt,base=0.5,cap=30.0):"""无抖动，纯指数"""returnmin(cap,base*(2**attempt))defbackoff_full_jitter(attempt,base=0.5,cap=30.0):"""全随机：wait ∈ [0, min(cap, base·2ⁿ)]"""returnrandom.uniform(0,min(cap,base*(2**attempt)))defbackoff_equal_jitter(attempt,base=0.5,cap=30.0):"""等量抖动：保留一半，随机一半"""v=min(cap,base*(2**attempt))/2returnv+random.uniform(0,v)defbackoff_decorrelated(prev_wait,base=0.5,cap=30.0):"""去相关：等待时间由上一次决定，彻底打破相关性"""returnmin(cap,random.uniform(base,prev_wait*3))# 演示prev=0.5foriinrange(6):fj=backoff_full_jitter(i)ej=backoff_equal_jitter(i)dc=backoff_decorrelated(prev)prev=dcprint(f"第{i+1}次 | Full={fj:.2f}s | Equal={ej:.2f}s | Decorelated={dc:.2f}s")

四、生产级封装

实际项目中，推荐将重试逻辑抽象为装饰器，与业务代码解耦：

importtime,random,functoolsfromtypingimportTuple,Typedefwith_backoff(retries:int=5,base:float=0.5,cap:float=30.0,exceptions:Tuple[Type[Exception],...]=(Exception,),):""" 指数退避 + Full Jitter 重试装饰器 用法： @with_backoff(retries=4, base=1.0, exceptions=(IOError, TimeoutError)) def call_api(): ... """defdecorator(func):@functools.wraps(func)defwrapper(*args,**kwargs):last_exc=Noneforattemptinrange(retries):try:returnfunc(*args,**kwargs)exceptexceptionsasexc:last_exc=excifattempt==retries-1:breakceiling=min(cap,base*(2**attempt))wait=random.uniform(0,ceiling)print(f"[Retry{attempt+1}/{retries}]{type(exc).__name__}:{exc}"f"→ 等待{wait:.2f}s")time.sleep(wait)raiselast_excreturnwrapperreturndecorator# 使用示例importrequests@with_backoff(retries=5,base=0.5,cap=20.0,exceptions=(requests.RequestException,))deffetch_data(url:str)->dict:resp=requests.get(url,timeout=5)resp.raise_for_status()returnresp.json()# 直接调用，重试由装饰器透明处理data=fetch_data("https://api.example.com/data")

五、使用tenacity库：开箱即用

手写重试逻辑适合理解原理，生产中更推荐使用经过充分测试的库tenacity：

fromtenacityimport(retry,stop_after_attempt,wait_exponential_jitter,retry_if_exception_type,before_sleep_log,)importlogging,requests logger=logging.getLogger(__name__)@retry(stop=stop_after_attempt(5),wait=wait_exponential_jitter(initial=0.5,max=30,jitter=1),retry=retry_if_exception_type(requests.RequestException),before_sleep=before_sleep_log(logger,logging.WARNING),reraise=True,)deffetch_with_tenacity(url:str)->dict:resp=requests.get(url,timeout=5)resp.raise_for_status()returnresp.json()

wait_exponential_jitter内部实现正是min(max, initial × 2ⁿ) + random(0, jitter)，与我们手写的逻辑完全一致，同时还提供了日志钩子、事件回调、上下文感知等企业级特性。

六、工程细节：避免常见陷阱

1. 必须设置重试上限（cap）

不设上限时，第 10 次重试的等待时间可能长达0.5 × 2¹⁰ = 512 秒，完全不可接受。cap=30是常见的合理值。

2. 区分"可重试"与"不可重试"的错误

# HTTP 429 Too Many Requests、503 才应重试# HTTP 400 Bad Request、401 Unauthorized 永远不要重试——参数错了重试多少次都没用RETRYABLE_STATUS={429,500,502,503,504}defshould_retry(exc:requests.HTTPError)->bool:returnexc.response.status_codeinRETRYABLE_STATUS

3. 在协程（asyncio）中使用

importasyncio,randomimportaiohttpasyncdeffetch_async(session,url,retries=5,base=0.5,cap=20.0):forattemptinrange(retries):try:asyncwithsession.get(url,timeout=aiohttp.ClientTimeout(total=5))asresp:resp.raise_for_status()returnawaitresp.json()exceptaiohttp.ClientErrorase:ifattempt==retries-1:raisewait=random.uniform(0,min(cap,base*(2**attempt)))awaitasyncio.sleep(wait)# 非阻塞等待，不会卡死事件循环

4. 结合断路器（Circuit Breaker）

退避解决"偶发失败"，断路器解决"持续失败"。两者配合使用：当连续失败次数超过阈值时，断路器"断开"，后续请求直接失败（fast-fail），不再等待重试，保护调用方资源。

七、小结

随机退避看似是一个简单的"加个random"，背后却体现了分布式系统中一个深刻的原则：客户端之间的协调，往往不需要显式通信，只需要引入随机性。一点点随机，就能让整个系统从同步振荡走向平稳自愈。