北京
下游数据库或微服务出现一次短暂的延迟尖峰，应用里的重试逻辑本该把这次抖动盖过去。但在大多数生产架构里，重试恰恰是把5秒的小故障拖成45分钟级联故障的那个机制。
亚马逊 Builders' Library 的记录指出，重试本质上是自私的：客户端重试一次失败调用，等于宣称自己的请求足够重要，可以从一个已经在挣扎求生的依赖身上索取更多资源。
如果你的 HTTP 客户端用的是固定延迟、没有抖动（jitter）的标准指数退避，或者在技术栈的多层都开了重试，那你建起来的不是韧性，而是一台同步负载放大器。
同步羊群与分层放大
多数工程师知道立即重试（延迟为0）很危险，于是配置标准指数退避：等1秒，再等2秒，再等4秒。但 Marc Brooker 在 AWS 架构博客关于指数退避与抖动的研究中证明，标准指数退避只降低了单个客户端的重试频率，并没有打破客户端之间的同步。
当下游服务卡住500毫秒，1000个并发请求会在同一毫秒一起失败：
- 1000个客户端全部睡1000毫秒（2^0 × 1000）。
- 整整一秒后，1000个客户端齐步醒来，连同正常流入的流量一起猛砸正在恢复的服务器。
- 服务器再次崩溃，同步波在2000毫秒4000毫秒处重复。
常见错误：无抖动退避与盲目重试
一个典型的 HTTP 或 RPC 调用封装，往往能顺利通过大多数代码评审：最大重试3次，基础延迟1000毫秒，循环里按尝试次数算出延迟再睡过去。看起来很有韧性，但在高负载下正是同步重试风暴的源头。
生产中的后果很直接。当一次发布或数据库锁让延迟越过2000毫秒的超时阈值，调用方实例会保持 socket 打开等待，然后在+1秒、+2秒、+4秒处打出同步重试波。即便你重启了过载的下游 pod，在途重试的积压也会在新实例缓存预热完成前把它们压垮——谷歌 SRE 手册在讨论级联故障时描述过这种经典的正反馈循环。
改进方案：全抖动加预算
要让重试在生产中变得安全，需要三个控制手段协同工作：
- 全抖动：把延迟随机化到0和指数上限之间（sleep = random(0, min(cap, base × 2^attempt))），把同步尖峰摊平成平滑、恒定的到达速率。
- 严格的可重试过滤：只重试瞬时传输错误或明确的429503状态码，存在 Retry-After 头时予以遵守。
- 本地重试预算（令牌桶）：把重试限制在总出站流量的某个百分比（例如10%）。依赖彻底挂掉时，预算耗尽，客户端快速失败，而不是放大故障。
在 AWS 对100个竞争客户端的模拟中，全抖动相比标准指数退避把服务器总调用量削减了50%以上，同时完成得更快。三种变体的取舍：
- 全抖动 random(0, min(cap, base × 2^attempt))：最佳默认选择，高竞争下服务器总工作量最低、完成最快。
- 等量抖动 temp/2 + random(0, temp/2)：保证最小睡眠窗口，客户端不会在0毫秒重试，同时打散羊群。
- 去相关抖动 min(cap, random(base, prevSleep × 3))：无状态替代方案，按上一次随机等待时间缩放，而非严格的2的幂。
上线前的五条检查
在发布任何客户端 SDK、队列消费者或 API 网关规则之前，用这五条核对重试策略：
- 只在技术栈的单一层重试：网关或顶层调用方已经重试时，关掉内层微服务跳转和 ORM 驱动的自动重试，让下层快速失败。
- 始终应用全抖动：并发调用方多于一个的系统里，绝不部署固定间隔或纯2^n退避。
- 执行10%重试预算：用令牌桶，失败请求超过10%时客户端停止重试、立即卸载。
- 变更操作要求幂等键：除非传入幂等键并在存储层原子化执行，否则不要对 POST 或 PATCH 端点开启自动重试。
- 跨跳传播截止时间：进来的请求超时是2000毫秒、已在上游处理花掉1800毫秒，就别再发一次还要1500毫秒的重试——用户早就断开了。
重试只有在失败是瞬时的、孤立的、罕见的时候才有效。一旦失败变成系统性——连接池饱和、数据库副本降级——朴素的重试就把你自己的微服务变成了一支内部僵尸网络。用全抖动替换确定性退避，把重试限制在单一架构层，并执行重试预算，让系统知道什么时候该停止往下挖。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
