限流到底该卡 QPS 还是卡并发数？聊聊我踩过的一个坑

背景

上个月帮一个团队做容量评审，他们网关层给一个订单查询接口配了 QPS 限流 5000，压测跑下来 QPS 4800、P99 稳定 45ms，一切"正常"。结果上线第三天，下游 MySQL 主从切换，P99 飙到 2.3s，QPS 只跌到 3000——没触发限流，但连接池（max=50）全打满，线程全阻塞，整个服务雪崩。

事后复盘才意识到：QPS 5000 在 P99=45ms 时对应的并发数才约 225，远没打满 50 的连接池；但 P99 一飙到 2s，同样的 3000 QPS 对应的 in-flight 请求就接近 6000，连接池根本兜不住。QPS 没超限 ≠ 资源没耗尽，这就是坑。

社区里常见的几种做法

• 流派 A：网关统一卡 QPS（令牌桶 / 漏桶）。优点：简单、可预测、运维面板一个数字就够；缺点：对"长接口"极不友好——一个 200ms 的接口和一个 5ms 的接口，同样的 QPS 配额，资源消耗差 40 倍。
• 流派 B：应用层卡并发数（in-flight / 信号量）。优点：直接对齐"同时有多少请求在吃资源"，对长接口天然公平；缺点：实现分散、每个服务自己管，且"并发数上限"设多少本身又是一个玄学。
• 流派 C：混合——网关 QPS 兜底 + 应用层并发数精细控制。我目前最认同这个，但落地时"两层限流的指标怎么对齐、告警怎么归因"是个工程细节坑。
• 流派 D：不显式限流，直接靠资源上限天然限流（连接池 max=50 就是并发上限 50，线程池 core=200 就是并发上限 200）。最"诚实"，但故障时表现为"排队 → 超时"，不如显式限流"快速失败"来得干净。

我的倾向

一句话：限流指标要和真实瓶颈资源对齐。

• 瓶颈是 CPU / 带宽（短接口、无外部 IO）→ QPS 够用；
• 瓶颈是连接池 / 线程池 / 下游并发额度（长接口、有 DB / RPC）→ 必须卡并发数；
• 网关层做 QPS 兜底（防突发流量打爆），应用层做并发数精细控制（对齐资源），两层都要有，但告警归因要分清是哪一层先触发的。

想听大家聊的

1. 你们团队限流到底卡的是什么？纯 QPS、纯并发、还是混合？
2. 有没有遇到过"QPS 没超限但服务挂了"或者"并发限了但吞吐量反而更低"的情况？怎么排查的？
3. 对于"一个接口里既有 5ms 的缓存命中路径、又有 200ms 的 DB 回源路径"这种混合延迟接口，你们限流怎么配？是按最坏路径卡还是按 P50 卡？

欢迎带具体场景和数字来聊，纯理论可以，但带上压测数据更有价值。