大促 10 倍流量峰值，你们是靠压测、影子流量还是容量建模撑住的？聊聊取舍

背景

社区里高并发方向的内容已经很密：连接池调参、超时重试、慢查询治理、热 key 治理，这些是「单点性能」层面的事，写得都很扎实。但最近我反复碰到的另一个问题，是容量规划：业务侧拍板「明年大促要撑 10 倍流量」，研发侧怎么给出一个可信的「能扛 / 不能扛」的结论？这件事我观察到团队里分歧非常大，而且经常吵到跨组。

常见做法，至少四种

1. 全链路压测：在预发或生产开影子库，按峰值 1.5x / 3x / 5x 逐级加压，看 P99、错误率、依赖水位。优点是「最接近真实」，缺点是成本高——影子数据构造、影子库同步、下游 mock，光工程化就够一个季度。
2. 影子流量（录制回放）：把生产流量录下来、脱敏、回放到预发集群。优点是不用「造」流量，缺点是相关性问题——回放时刻的流量形态未必等于峰值形态（比如秒杀场景的 key 分布和日常完全不同），而且很多团队其实没做全链路。
3. 离线容量建模：用 Little's Law、Amdahl 之类的模型 + 单点 benchmark，反推需要多少实例、多少连接、多少 buffer。优点是便宜、可重复，缺点是对依赖链路的耦合建模很脆——一个 GC 抖动、一次慢查询、一次网络分区，模型都算不出来。
4. 直接堆资源：把实例数翻倍、把连接池调大、把超时放宽，靠「余量」换确定性。优点是简单，缺点是成本线性涨、且可能把抖动放大（社区那篇连接池的文章讲得很透：池子调大往往不是变快，而是把抖动放大）。

我的倾向与理由

我 8 年下来基本是「3 → 1 → 2」的组合拳：先用建模把「理论上限」和「瓶颈在哪一层」算出来（CPU？IO？锁？下游 RT？），再针对模型里识别出的瓶颈层做定向压测验证（而不是全链路压一遍），最后用影子流量做一次「真实流量形态」的兜底验证。理由有三：

• 全链路压测贵，而且每次大促都得重跑一次，长期看 ROI 不高；
• 影子流量相关性是隐性的坑，峰值流量形态和日常往往差一个量级，容易给你「误信心」；
• 建模最大的价值不是「算出数字」，而是逼你把假设列出来——哪些环节是线性、哪些是超线性、哪些是硬上限，这些假设列清楚之后，压测才知道该测什么。

但我也承认这个组合拳对团队的建模能力要求很高，小团队往往做不动，最后只能退回「堆资源 + 全链路压测」，这个我理解，不丢人。

想听大家聊的

• 你们的峰值流量是可预测（大促、抢购）还是不可预测（突发热点、舆情）？这两种场景的容量策略其实完全不同，我猜很多团队混着做。
• 你们压测的置信度怎么定的？「P99 < 200ms 算过」这种硬阈值，和「比基线劣化 15% 以内算过」这种相对阈值，你们用哪个？为什么？
• 有没有人做过「只压瓶颈层、不压全链路」的实践？效果如何，踩过什么坑？
• 反过来问一句：有没有人反对我这个组合拳的？觉得我漏了什么？尤其是依赖链路建模那部分，我自己也心虚。

期待具体案例，最好带数字（QPS、P99、实例数、成本），空谈方法论的咱们可以单独聊。