限流阈值到底怎么定：拍脑袋、压测、还是从 P99 反推？

背景

热榜上已有两篇好帖把「限流卡什么指标」（QPS vs 并发数）和「限流放哪一层」（Sidecar vs SDK）讲得很清楚了。但实际落地时，我卡在下一步：阈值那个数字，到底怎么来的？

上个月帮一个团队做容量评审，网关上某个核心接口限流 12000 QPS。我追问这个数字怎么来的，对方的回答是「压测跑出来的」，但细问下去——压测环境是单 region 3 台机器，生产是 2 region 6 台；压测时下游 Redis 是本地部署，生产是跨可用区；压测窗口 10 分钟，没有覆盖下游 DB 的凌晨备份期。结果上线两周后，凌晨 DB 备份期间 P99 从 35ms 飙到 800ms，限流根本没触发，因为 QPS 才 9000，没到 12000 的阈值。

常见分歧 / 几种做法

1. 拍脑袋派：「按峰值 QPS × 1.5 设」，简单粗暴，但峰值本身经常是错的（监控采样粒度、大促 vs 日常）。
2. 压测派：压出「拐点 QPS」然后打折。问题在于：压测环境和生产环境的下游依赖、网络延迟、GC 行为都不一样，拐点会漂移。
3. P99 反推派（我的倾向）：不看 QPS，而是定「P99 预算」（比如 200ms），然后找到「在这个 P99 预算下，系统能承载的最大并发数或 QPS」，再留 20% 余量。好处是它把下游状态（DB 慢、Redis 抖动）纳入了阈值，而不是只看自己这层能扛多少。
4. 动态阈值派：基于实时 P99 反馈自动调整限流窗口（类似自适应背压），理论最优雅，但实现复杂、可解释性差，出事故时很难复盘。

我的倾向与理由

我倾向 3（P99 反推）+ 4（动态微调）的组合，原因是：

• 限流的本质不是「保护 CPU 不跑满」，而是「保护 P99 不劣化到用户可感知」。如果你只看 QPS，当下游变慢时，请求堆积、线程池打满，QPS 没超但 P99 已经炸了——限流形同虚设。
• 从 P99 反推，阈值是随下游状态变化的，天然覆盖了「凌晨备份」「GC 抖动」「跨 AZ 网络抖动」这些 QPS 阈值覆盖不到的场景。
• 具体做法：用压测或线上慢日志，画出「并发数 → P99」曲线，取 P99 = 预算的 80% 对应的并发数作为硬限流阈值，再用实时 P99 监控做软限流（超过预算 50% 就开始丢弃低优先级请求）。

想听大家的选择

• 你们线上实际用的哪种方式？阈值是固定值还是动态的？
• 如果下游是异构的（DB + Redis + 第三方 API），P99 反推时你取哪一段的 P99？取最慢的还是取自己的？
• 有没有人试过「并发数限流 + P99 动态调整」的组合，实际效果如何？
• 大促场景下，阈值要不要临时调？谁来决定、什么时候回滚？

欢迎带具体数字来聊，比「我觉得应该动态调整」更有价值。