限流，本来是为了保护系统。
但在这次事故中，限流器本身成了第一个被拖垮的组件。

更糟的是：

• 后端服务没来得及崩
• 网关先失去了响应能力
• 所有请求卡在入口

这是一次非常典型的“限流设计正确，但位置和实现错误”的事故。

一、事故背景

系统架构简化如下：

text

Client ↓ 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 设计如下（示例）：

javascript

gateway: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 超时直接放行 / 拒绝
• 限流服务降级为本地策略

九、事故总结

这次事故并不是“限流没用”，而是：

• 限流实现成本过高
• 限流位置选择错误
• 忽略了入口层的吞吐特性

最终导致：

系统没被流量打垮，却被“保护机制”先拖垮

十、写在最后

限流不是越统一越好，
入口不是越重越安全。

在分布式系统中：

任何保护机制，如果本身不可控，都会成为新的风险点。