限流，本来是为了保护系统。
但在这次事故中，限流器本身成了第一个被拖垮的组件。
更糟的是：
- 后端服务没来得及崩
- 网关先失去了响应能力
- 所有请求卡在入口
这是一次非常典型的“限流设计正确，但位置和实现错误”的事故。
一、事故背景
系统架构简化如下：
textClient ↓ Spring Cloud Gateway（统一入口） ↓ 下游微服务
事故发生前做了这些“看起来很正确”的事情：
- 在 Gateway 层做统一限流
- 使用 Redis 作为分布式限流存储
- 限流算法：令牌桶 / 滑动窗口
- 限流粒度：按接口 + IP
目标很明确：
入口挡流量，保护下游
二、事故现象
突发流量高峰后，系统表现为：
- Gateway RT 飙升（几十 ms → 几秒）
- 大量请求超时
- 下游服务 CPU、线程池仍然正常
- Redis QPS 急剧上升
- Gateway 实例频繁 Full GC
最终结果：
限流没挡住流量，反而把网关拖死了
三、第一反应：限流规则是不是失效了？
第一时间检查限流规则：
- 阈值配置正确
- Redis key 在增长
- 限流命中率正常
结论很反直觉：
限流规则是生效的，但系统还是扛不住
问题不在“限没限住”，而在“限流是怎么做的”。
四、核心问题一：限流器成了“同步阻塞点”
Gateway 中的限流逻辑：
请求进入 ↓ 执行限流判断（Redis） ↓ 通过 → 转发 拒绝 → 返回 429
在高并发下，每一个请求都会：
- 同步访问 Redis
- 等待 Redis 返回结果
- 才能决定是否放行
📌限流判断本身就是一次远程调用
当 QPS 上来时：
- Redis RTT × 请求数
- 网关线程被大量阻塞
- Reactor 线程开始堆积
五、核心问题二：Redis 成了“全局热点”
限流 key 设计如下（示例）：
javascriptgateway:rate_limit:/order/create
问题在于：
- 热接口 → 热 key
- 所有 Gateway 实例
- 所有请求
- 都在竞争同一个 Redis key
结果：
- Redis 单点瓶颈
- 网络 IO 放大
- Gateway 等 Redis，Redis 又被 Gateway 打爆
👉形成“限流互相伤害”
六、核心问题三：限流位置选错了
这次事故最大的设计问题是：
把“高成本限流”放在了最外层入口
Gateway 层的特点：
- 请求量最大
- 并发最高
- 对 RT 最敏感
但限流实现却是：
- 分布式
- 强一致
- 同步远程依赖
📌入口层，最怕“慢”
七、为什么下游没挂，Gateway 先挂？
因为：
- 下游有线程池、熔断、限流
- Gateway 是“放大器”
- Gateway 一旦慢，所有请求都慢
一句话总结：
网关是系统的喉咙，不是缓冲区
八、正确的限流设计思路
1️⃣ Gateway 层只做“轻量限流”
适合 Gateway 的限流：
- 本地限流（Guava / Resilience4j）
- 基于内存
- 不依赖外部组件
- 宁可不准，也要快
📌 原则：
入口限流要“快失败”
2️⃣ 分布式限流下沉到服务内部
真正需要精确控制的地方：
- 核心接口
- 资源敏感操作
- 下游依赖重的逻辑
这些限流应该：
- 放在服务内
- 靠近资源
- 粒度更细
3️⃣ 限流本身也要被限流
这是很多系统忽略的一点：
- Redis 限流 → Redis 也要保护
- Gateway → 也需要自我保护策略
例如：
- Redis 超时直接放行 / 拒绝
- 限流服务降级为本地策略
九、事故总结
这次事故并不是“限流没用”，而是：
- 限流实现成本过高
- 限流位置选择错误
- 忽略了入口层的吞吐特性
最终导致：
系统没被流量打垮，却被“保护机制”先拖垮
十、写在最后
限流不是越统一越好，
入口不是越重越安全。
在分布式系统中：
任何保护机制，如果本身不可控，都会成为新的风险点。
