这是一个非常典型的“伪安全”场景。很多开发者认为只要限制了入口 QPS，系统就是安全的，却忽视了Little's Law（利特尔定律）中“响应时间”对并发资源的致命影响。
当数据库变慢时，限流器依然按照 500 QPS 放行，但应用服务器的线程池（通常只有几百）瞬间被耗尽，导致系统雪崩。限流器此时就像一个在那儿数人头、却看不见屋里已经着火的保安。
错误示范：基于 QPS 限流导致的系统雪崩
图解核心逻辑分析
1. 限流器的盲区：
● 限流器只看速率（Rate），即“每秒进来了多少人”。
● 它不看并发（Concurrency），即“现在屋子里挤了多少人”。
● 在这个例子中，每秒放 500 个请求进去是符合规则的，但因为它不知道这些请求进去后要花 5 秒才能出来。
2. 资源耗尽过程：
● 应用服务器线程池最大只有 200。
● 如果数据库耗时变成 5 秒。
● 仅需 0.4秒 ()，所有 200 个线程就被全部占满去等待数据库了。
● 之后的 4.6 秒内，虽然限流器还在放人进来（因为它觉得每秒 500 没问题），但应用服务器已经没有任何线程来接待了。
正确的应用场景
场景 1：多级租户 API 限流 (SaaS 配额管理)
这个场景展示了网关如何识别用户身份（API Key），并根据不同的配置策略（免费 vs 专业）来决定是放行还是拒绝（429）。
场景 2：保护下游服务的限流 (削峰/整形)
这个场景展示了系统内部的主动限流。即使上游业务（如营销活动）产生了 2000 TPS 的请求，限流器也会像漏斗一样，强制将其“整形”为 1000 TPS 发送给短信网关，防止下游崩溃或触发供应商的封禁。
关键区别总结
● 场景 1 (API 配额) 关注的是 Identify（身份）。核心在于“识别你是谁，你配多少资源”。这是为了公平性。
● 场景 2 (下游保护) 关注的是 Capacity（容量）。核心在于“不管请求是谁发的，只要总量超过阈值就卡住”。这是为了稳定性。
评论区