什么是重试风暴，为什么它比故障本身更可怕

做后端的人大概都遇到过这种场景：某个服务响应变慢，客户端等不到结果就开始重试；重试的请求又加重了服务负担，让它变得更慢；于是更多客户端加入重试队列——雪崩就这样发生了。

Uber 在官方博客里把这个现象称为「重试风暴」（Retry Storms）。它的可怕之处在于：故障的起因可能只是一个小抖动，但重试行为会把它放大成一场全局性的服务瘫痪。对任何依赖大量微服务、跨区域调用的系统来说，这都是必须提前设计防御的场景。

Uber 的核心思路：别让客户端「想重试就重试」

Uber 的做法不是简单粗暴地禁止重试，而是把重试变成一种「被管理的资源」。几个关键点值得记下来：

第一，设置重试预算。 系统会为每类请求设定一个可接受的重试总量上限，一旦超过这个预算，新的重试请求就会被直接拒绝。这相当于给重试行为装了一个总闸，避免它无限膨胀。

第二，引入退避与抖动。 如果所有客户端在同一时刻重试，冲击会集中爆发。Uber 采用指数退避加上随机抖动，让重试请求在时间轴上被打散，削平瞬时峰值。

第三，区分错误类型。 不是所有失败都值得重试。网络超时、连接被拒可以重试，但业务逻辑错误、参数错误重试多少次都没用。把可重试和不可重试的错误分开处理，能省下大量无效流量。