RPC 核心概念 05：超时、重试、熔断与限流
RPC 核心概念 05：超时、重试、熔断与限流
如果说服务发现是 RPC 的"基础设施"，那么超时、重试、熔断、限流就是 RPC 的安全气囊——决定了系统在故障来临时还能否站立。本篇讲清楚这四件套的边界、配合与陷阱。
一、为什么需要这些？
分布式调用链中，任何一环都可能：
- 突然变慢；
- 偶发抖动；
- 整体不可用；
- 流量洪峰冲击。
如果不加防护：
- 慢调用会耗尽线程/goroutine；
- 偶发错误会蔓延至上游；
- 故障会雪崩式放大。
所以每一次跨网络调用都必须有超时、重试、熔断、限流策略，这是工业 RPC 的铁律。
二、超时（Timeout）
2.1 为什么超时是第一道防线？
“网络请求没有超时 = 自杀。”
没有超时 = 调用方线程/goroutine 永远悬挂 = 资源耗尽 = 整体宕机。
2.2 超时层级
[用户请求] │ 整体超时 5s ▼ [网关] │ 调下游 A 超时 3s ▼ [服务A] │ 调下游 B 超时 1s ▼ [服务B]经验法则：
- 上游超时 ≥ 下游所有调用之和；
- 同一接口对不同调用方可有不同超时；
- 写操作超时要慎重，重试可能造成幂等问题。
2.3 上下文传递（context.Context）
Go 的context是天然的超时载体：
ctx,cancel:=context.WithTimeout(ctx,1*time.Second)defercancel()resp,err:=client.Call(ctx,req)关键设计：所有 RPC 框架都会把ctx透传给下游，使整条调用链共享 deadline。tRPC、gRPC 都遵循这一规则。
2.4 超时常见错误
| 错误 | 后果 |
|---|---|
| 整体业务超时大于 SDK 超时 | 实际超时由 SDK 决定 |
| 不带 cancel | 资源泄漏 |
| 超时太长 | 流量打爆下游 |
| 超时太短 | 误判正常请求 |
三、重试（Retry）
3.1 重试的基本原则
✅ 应该重试：
- 网络超时；
- 503 / 5xx；
- 连接失败。
❌ 不应该重试：
- 业务错误（参数错、权限错）；
- 4xx；
- 已扣款的支付。
3.2 幂等性
重试的前提是接口幂等——同样的请求重复调用，结果一致。
幂等性实现：
- 天然幂等：GET、删除、ID 唯一约束；
- 请求 ID 去重：每次请求带
request_id，服务端缓存已处理； - 乐观锁：
UPDATE ... WHERE version = X。
3.3 退避策略
不能立即重试，否则会"暴击"故障下游：
固定退避
500ms → 500ms → 500ms指数退避
100ms → 200ms → 400ms → 800ms指数退避 + 抖动（推荐）
delay = min(cap, base * 2^n) ± random抖动能避免大量调用方"同步暴击"。AWS 推荐做法：
sleep:=rand.Float64()*math.Min(cap,base*math.Pow(2,n))3.4 重试预算（Retry Budget）
无脑重试会放大下游压力。Google 提出"重试预算"：
重试比例 ≤ 10% 总流量超过则禁用重试一段时间，保护下游。
3.5 tRPC 配置示例
client:service:-name:trpc.app.usertimeout:1000# msretry:2四、熔断（Circuit Breaker）
4.1 熔断的本质
下游已经挂了/极慢，继续打无意义且伤害自己。熔断器在错误率达到阈值时主动拒绝请求，给下游恢复时间。
4.2 三态状态机
┌────────────┐ │ Closed │ ← 正常，全量放行 └─────┬──────┘ │ 错误率 > 阈值 ▼ ┌────────────┐ │ Open │ → 快速失败，全部拒绝 └─────┬──────┘ │ 冷却时间到 ▼ ┌────────────┐ │ Half-Open │ → 放少量探测请求 └─────┬──────┘ 成功 │ 失败 ↓ ↓ Closed Open4.3 关键参数
- 错误率阈值：通常 50%；
- 统计窗口：滚动窗口（如最近 10s）；
- 最小调用数：避免低流量误判；
- 冷却时间：通常 5~30s；
- 探测请求数：half-open 状态放行的请求数。
4.4 算法
Sliding Window
[ 1s | 1s | 1s | ... | 1s ] ← 10 个桶 合计错误率 → 决策Google SRE《SRE 工作手册》算法
拒绝概率 = max(0, (requests - K * accepts) / (requests + 1))K 通常取 2，自适应、无明显状态切换、被广泛采用（如 Kratos）。
4.5 与限流的边界
| 维度 | 熔断 | 限流 |
|---|---|---|
| 触发原因 | 错误率高 | 流量太大 |
| 保护对象 | 自己（避免被慢调用拖垮） | 下游（避免被打爆）/ 自己 |
五、限流（Rate Limiting）
5.1 为什么需要限流？
- 保护下游不被打爆；
- 防御异常流量（爬虫、攻击）；
- 公平分配资源给多租户。
5.2 限流维度
全局 → 接口 → 调用方 → 用户 → IP通常组合使用，比如"每个 IP 每秒最多 10 次 + 整体 QPS 不超过 1 万"。
5.3 主流算法
计数器
最简单：每秒 N 次。
缺点：边界突刺（59.999s 来 N 次 + 60.001s 又来 N 次 = 1 秒内 2N 次）。
滑动窗口
把 1 秒分成多个小桶，更精细。
漏桶（Leaky Bucket）
[流量] → ████ → [桶] → 匀速流出 → [服务]平滑流量，但不能应对短时突发。
令牌桶（Token Bucket）
[匀速生成 token] → [桶] ← [请求需要拿到 token]允许突发（桶里攒了 N 个 token 可一次消费完），是最常用算法。
Go 标准库golang.org/x/time/rate就是令牌桶实现：
limiter:=rate.NewLimiter(100,200)// 100 QPS，桶容量 200if!limiter.Allow(){returnerrors.New("rate limited")}5.4 分布式限流
单机限流在多实例场景失效。常见方案：
- Redis + Lua：分布式计数；
- Sentinel / Polaris：内置分布式限流；
- 网关层限流：在入口统一控流。
六、降级（Fallback）
当下游不可用，返回兜底数据：
- 推荐服务挂了 → 返回热门兜底；
- 个性化页面挂了 → 返回静态页；
- 关键服务挂了 → 直接报错（不能瞎降级）。
resp,err:=client.Recommend(ctx,req)iferr!=nil{returndefaultHotItems,nil// 降级}returnresp,nil七、四件套协同
[客户端] │ ▼ [限流]：流量太大直接拒绝 │ ▼ [熔断]：下游挂了直接拒绝 │ ▼ [超时]：调用必须有 deadline │ ▼ [重试]：偶发错误幂等重试 │ ▼ [降级]：兜底数据八、tRPC-Go 配置实战
client:service:-name:trpc.app.usertarget:polaris://trpc.app.usertimeout:500# msretry:2plugins:circuitbreaker:polaris:{}# 走 Polaris 熔断ratelimiter:polaris:{}# 走 Polaris 限流代码层显式控制：
ctx,cancel:=context.WithTimeout(ctx,500*time.Millisecond)defercancel()resp,err:=client.GetUser(ctx,req,client.WithTimeout(500*time.Millisecond),)九、可观测性配套
四件套必须配备指标：
- 超时率
- 重试次数 / 重试成功率
- 熔断次数 / 熔断恢复时间
- 限流拒绝数
通过 Prometheus + Grafana 大盘可视化，结合告警闭环：
错误率突增 → 告警 → 自动扩容 / 切流十、踩坑清单
- ❌ 重试非幂等接口 → 资金事故；
- ❌ 上游超时 < 下游超时之和 → 重试无用功；
- ❌ 不带退避的重试 → 故障放大；
- ❌ 关键服务无脑降级 → 数据错误流到用户；
- ❌ 单机限流认为是全局 → 限流策略失效；
- ❌ 熔断阈值过严 → 抖动即误熔；
- ❌ 网关侧已限流但内部不再限流 → 内部某节点被打爆。
十一、小结
- 超时：Deadline 必须随调用链层层下传；
- 重试：幂等 + 退避 + 预算；
- 熔断：三态机+错误率阈值，保护自己；
- 限流：令牌桶最常用，分布式靠 Redis/Sentinel；
- 降级：兜底数据，不能盲目用。
至此，RPC 核心概念 5 篇完结。下一阶段我们正式进入tRPC-Go 框架的世界，看它如何把这些理念落地为开箱即用的工程能力。