限流与熔断方案设计

核心命题：流量洪峰下如何保护系统不崩溃——从单机限流到分布式全链路熔断降级。

---

01. 案例引入

一个真实事故：秒杀流量打崩支付服务 → 连锁雪崩拖垮整个集群 → 30分钟全站不可用。

---

02. 问题拆解

• 限流：控制请求量（拒绝多余，保证核心可用）
• 熔断：快速失败（下游挂了别等了，直接返回兜底）
• 降级：有损服务（关非核心功能，保核心链路）
• 隔离：线程池隔离 vs 信号量隔离

---

03. 业界方案

方案	代表	优点	缺点
令牌桶	Guava RateLimiter	允许突发、平滑	单机
漏桶	Nginx limit_req	强制匀速	不允许突发
滑动窗口	Redis + Lua	精确、分布式	Redis依赖
熔断器	Hystrix/Resilience4j	自动恢复	已停止维护(Hystrix)
全链路	Sentinel	限流+熔断+降级一体	阿里系依赖
网关层	Kong/APISIX	零代码入侵	粒度粗

---

04. 设计原则

1. 限流在入口（网关层），熔断在调用点（RPC/HTTP Client层）
2. 快速失败 > 等待超时
3. 降级要有损但可控（明确知道关了哪些功能）
4. 熔断恢复用半开状态（试探性放行）

---

05. 方案落地

• 单机限流：Guava RateLimiter + 令牌桶
• 分布式限流：Redis Lua脚本滑动窗口
• 熔断器状态机：CLOSED → OPEN → HALF_OPEN
• Sentinel 全链路流控规则配置

---

06. 踩坑反例

• 限流阈值拍脑袋 → 阈值太低误杀正常流量
• 只限不限排队 → 大量等待耗尽线程池
• 熔断后不半开 → 服务恢复了但永远熔断
• 降级不区分核心/非核心 → 用户体验灾难

---

07. 演进路线

• V1: Guava 单机限流 → V2: Redis 分布式 + Sentinel 熔断 → V3: 自适应限流（BBR/拥塞控制）

---

下一篇：20. 终端设备鉴权设计