从 3 次雪崩到 0：RPC 超时预算与重试风暴避坑实录

问题背景：一次下单接口的 3 次雪崩

某电商大促期间，订单服务调用库存服务偶发超时。排查发现链路上每个服务都独立配置了 1s 超时和 3 次重试：网关重试 3 次、订单服务重试 3 次、库存服务内部调用 Redis 又重试 3 次。当下游轻微抖动时，入口 1 个请求最坏会放大成 27 次子调用，连接池被迅速打满，最终从局部超时演变为全链路雪崩。这就是典型的重试风暴：重试本为容错，却在调用链中被指数级放大。

根因有两个：一是缺少统一的超时预算，各层超时简单相加而非共享；二是重试决策彼此独立，没有感知剩余时间与下游负载。

方案对比：固定超时 vs 超时预算

维度	各层独立超时	全局超时预算
总耗时	各层超时相加，不可控	入口截止时间统一约束
重试放大	层层相乘，易风暴	预算不足直接 fail-fast
级联取消	上游超时后下游仍在跑	context 取消立即传播
实现成本	低	中，需透传 deadline

超时预算的核心思想：入口为整条链路分配一个总预算（如 800ms），每经过一跳从剩余预算中扣除已耗时间，并为网络与排队预留缓冲；任何重试都必须先检查剩余预算是否足够覆盖一次完整调用。

实操步骤：Go 实现超时预算与安全重试

下面以 Go 为例，实现一个带预算感知的 RPC 客户端。关键在于：用 context.WithTimeout 承载截止时间，重试前校验剩余预算，并配合指数退避与抖动（jitter）避免同步重试。

第一步：透传并计算剩余预算

package main

import (
	"context"
	"fmt"
	"math/rand"
	"time"
)

// CallOptions 描述一次下游调用的预算策略
type CallOptions struct {
	MaxRetry   int           // 最大重试次数（不含首次）
	BaseDelay  time.Duration // 退避基数
	Reserve    time.Duration // 为网络/排队预留的缓冲
}

// childTimeout 根据父级剩余预算计算本次调用的超时
// 原则：本次超时 = 剩余预算 - 预留缓冲，且必须为正
func childTimeout(parent context.Context, reserve time.Duration) (time.Duration, bool) {
	deadline, ok := parent.Deadline()
	if !ok {
		// 上游没有截止时间时，给一个保守默认值，避免无限等待
		return 500*time.Millisecond - reserve, true
	}
	left := time.Until(deadline) - reserve
	return left, left > 0
}

第二步：预算感知的退避重试

// CallWithBudget 在共享超时预算内执行带退避的调用
func CallWithBudget(ctx context.Context, opt CallOptions, do func(context.Context) error) error {
	var lastErr error
	for attempt := 0; attempt <= opt.MaxRetry; attempt++ {
		// 重试前先检查预算：不够一次完整调用就立即放弃
		timeout, ok := childTimeout(ctx, opt.Reserve)
		if !ok || timeout <= 0 {
			return fmt.Errorf("预算耗尽，fail-fast: %w", lastErr)
		}

		callCtx, cancel := context.WithTimeout(ctx, timeout)
		err := do(callCtx)
		cancel()

		if err == nil {
			return nil
		}
		lastErr = err

		// 上游已取消（如用户断开、网关超时），不再重试
		if ctx.Err() != nil {
			return ctx.Err()
		}
		if attempt == opt.MaxRetry {
			break
		}

		// 指数退避 + 随机抖动，避免大量客户端同时重试
		backoff := opt.BaseDelay << attempt
		sleep := time.Duration(float64(backoff) * (0.5 + rand.Float64()))
		timer := time.NewTimer(sleep)
		select {
		case <-ctx.Done():
			timer.Stop()
			return ctx.Err()
		case <-timer.C:
		}
	}
	return lastErr
}

第三步：入口分配总预算并串联调用链

func main() {
	// 入口为整条链路分配 800ms 总预算
	rootCtx, cancel := context.WithTimeout(context.Background(), 800*time.Millisecond)
	defer cancel()

	opt := CallOptions{MaxRetry: 2, BaseDelay: 20 * time.Millisecond, Reserve: 30 * time.Millisecond}

	err := CallWithBudget(rootCtx, opt, func(ctx context.Context) error {
		// 模拟订单 -> 库存的嵌套调用，子调用复用同一 ctx
		return CallWithBudget(ctx, CallOptions{MaxRetry: 1, BaseDelay: 10 * time.Millisecond, Reserve: 20 * time.Millisecond},
			func(ctx context.Context) error {
				// 真实场景这里发起 gRPC 请求，deadline 会随 metadata 透传
				return fmt.Errorf("模拟下游超时")
			})
	})
	fmt.Println("最终结果:", err)
}

在 gRPC 中，客户端只需 grpc.WithUnaryInterceptor 注入上述逻辑，并通过 metadata 传递 grpc-timeout；服务端用 grpc.FromContext 取出的 ctx 天然携带截止时间，无需自行解析请求头。

防重试风暴的三道闸门

仅有预算仍不够，生产环境还需叠加防护：

1. 重试预算（Retry Budget）：限制客户端重试请求占正常请求的比例（如 10%~20%），超过阈值直接放弃重试。相比固定次数，它能在下游高负载时自适应收敛。
2. 熔断与限流：下游错误率超阈值时熔断器打开，快速失败；服务端配合令牌桶限流，保护核心线程池与连接池。
3. 只重试幂等操作：非幂等写接口必须带幂等键（如订单号），否则超时后重试可能造成重复扣款。

避坑总结：来自线上的 4 条具体教训

坑 1：各层超时简单相加，入口预算形同虚设。 现象是网关设 1s、下游各设 1s，实际请求 2s 才超时返回。修正方法是全链路共享同一 deadline，每跳用 context 剩余时间减去预留缓冲作为本次超时，而不是重新 setTimeout(1s)。

坑 2：重试只看错误次数，不看剩余时间。 现象是日志显示请求已超时返回，但下游仍在收到重试并继续打满连接。修正方法是每次重试前检查 ctx.Err() 与剩余预算，预算不足立即 fail-fast，并让退避 select 监听 ctx.Done()，避免无谓 sleep。

坑 3：退避不加抖动，故障整点复发。 现象是大量客户端使用固定 100ms 退避，每隔 100ms 出现一波整齐的重试流量尖峰。修正方法是指数退避乘以 0.5~1.5 的随机抖动因子，打散重试时刻；跨语言实现可用全抖动（full jitter）算法。

坑 4：对非幂等写接口盲目重试。 现象是库存扣减超时后重试，导致一单扣两次库存。修正方法是写请求必须携带业务幂等键，服务端用唯一索引去重；无法保证幂等的接口只做快速失败，把补偿交给对账或消息队列。

建议结合混沌工程常态化演练：主动注入下游延迟与错误，验证 deadline 是否正确传播、重试放大倍数是否受控、熔断器是否按预期打开。把超时与重试当作一套共享预算系统来设计，而不是每个服务各自为政，才能让 RPC 调用链在抖动下保持韧性。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。