一句话定义：重试风暴（Retry Storm）指的是——系统已经出现故障或过载时，大量客户端同时对失败的请求发起重试，让请求量在短时间内成倍放大，把本来只是“吃力”的服务彻底压垮。它最讽刺的地方在于：重试本是提高成功率的手段，最后却成了加速死亡的那一脚。
原理：一次“催菜”如何变成灾难
打个餐馆的比方。后厨出餐慢了，一桌客人开始催，服务员放下手里的活儿跑去后厨问一句“好了没”；隔壁桌看到有人催，也跟着催。很快十个服务员挤在厨房门口问同一句话，厨师手上的活儿反而停了。客人越等越急、催得越勤，出餐越慢。重试风暴就是这个场面：单看每一次“催”都合理，合起来就是灾难。
放大效应首先是个数学问题。假设每个请求失败后自动重试 3 次，一个失败请求就变成 4 次调用；而当服务端已经因为过载开始超时（Timeout），这些请求正卡在它最脆弱的时刻，新一波流量又压上来。更麻烦的是“同步”：如果所有客户端都用固定间隔重试（比如统一等 1 秒），它们会整齐地在同一毫秒一起动手，形成周期性尖峰。服务刚喘上一口气，又被踩一脚，恢复时间被大幅拉长。失败导致重试、重试加剧失败，这是个典型正反馈回路。
工程上的解法，基本是给这个回路装刹车：指数退避（Exponential Backoff） 让每次重试的等待时间逐次拉长；抖动（Jitter） 在等待里掺入随机量，打散同步脉冲；重试预算（Retry Budget） 限制重试流量在总流量中的占比；熔断（Circuit Breaker） 在失败率过高时直接停止调用、给下游喘息；同时只对幂等（AI 词典：Idempotency">Idempotency） 的请求重试，并把重试层数收敛到调用链的最外层——每一层都重试，放大倍数是相乘的。
和相邻概念的区别
| 概念 | 触发源 | 核心机制 | 典型后果 |
|---|---|---|---|
| 重试风暴 Retry Storm | 请求失败、超时 | 失败驱动的重试把流量成倍放大 | 过载加剧，恢复时间拉长 |
| 惊群 Thundering Herd | 资源同时可用、缓存集中过期 | 大量请求同时争抢同一资源 | 瞬时尖峰 |
| 雪崩 Cascading Failure | 单点故障 | 故障沿依赖链逐级传导 | 整条链路不可用 |
三者常被混着说：重试风暴往往是雪崩的触发器或加速器，而惊群描述的是“同时醒来”的形态，重试风暴描述的是“越失败越猛”的放大。
对从业者和普通人的意义
对做系统的人：重试策略不是“加上就完事”的保险丝，它本身是一份流量承诺。上线前请想清楚——重试几次、间隔多长、有没有抖动、谁负责熔断、下游扛不扛得住最坏情况的放大倍数。重试逻辑写错，等于给故障装了个涡轮。
对普通职场人：抢票页面转圈时狂点“刷新”、提交订单没反应就连按五次，其实就是微缩版的重试风暴，只会让本就拥挤的系统更慢。正确做法是等几秒、按页面提示重试，或者干脆走开一会儿。对调用大模型 API、跑批量推理任务的 AI 从业者同理：限速与重试要配套设计，别让自动重试把配额和下游服务一起打穿。