全链路压测与容量规划

单接口压八万，全链路压八百

压测报告里最经典的自欺：Redis 预扣单接口压出八万 QPS、网关限流压出五万、数据库写入压出两千——单看每层都漂亮。全链路一起压：八百。原因很简单：每个组件都要为同一次请求付出资源，连接池互相挤占、CPU 互相争抢、下游互为瓶颈——容量不是组件容量的最小值，是它们纠缠之后的结果。全链路压测的价值就在于暴露纠缠——全链路压测的总体方法论之前已经系统讲过，这一篇聚焦秒杀场景的落地细节。

影子隔离：压测数据不能污染生产

秒杀压测必须在生产环境做——测试环境的连接数、数据量、缓存命中率都与生产失真。生产压测的前提是影子隔离：压测流量带标记，数据写影子表（影子库或影子前缀），缓存走影子 key，MQ 走影子队列——链路全程可追踪、可丢弃、可清理。隔离不彻底的压测等于在生产里做事故：真实库存被扣减、真实用户收到假通知，都是真实发生过的案例。

// 压测标记沿链路透传
X-Load-Test: true                      // 入口标记
// 数据层路由：标记流量写影子表
if (isLoadTest) target = "shadow_seckill_order";  else target = "seckill_order";
// Redis：影子 key 带前缀与短 TTL
key = isLoadTest ? "shadow:stock:sku:1001" : "stock:sku:1001";
// MQ：影子队列独立消费，活动后整体清理

容量公式与短板定理

容量规划从峰值推算开始：预估峰值 QPS = 预计参与人数 ÷ 开抢高峰秒数（经验上 30%～50% 的请求挤在头三秒），再乘冗余系数 1.5～2——容量要按压测实测值的 60%～70% 规划，给噪音、抖动和未知留位置。然后把峰值分配到每一层核对：CDN 带宽、网关连接、Redis 分桶吞吐、MQ 消化速率、数据库写入——任何一层的短板决定全链路上限，压测报告要给每层一个明确结论：够、紧、不够。

压测场景不止一条

除了正常抢购主场景，四个异常场景同样要压：热点加剧——单个 SKU 流量翻倍验证分桶与打散；售罄洪峰——库存归零后的纯失败流量验证快速失败；回补洪峰——大量关单同时回补验证幂等与 Redis 写压力；降级切换——压测中注入故障验证预案生效。主场景证明"能扛"，异常场景证明"坏了也知道怎么坏"。

常态化

压测不是大促前的一次性运动：架构变更后回归压测——分桶参数改了、限流阈值调了，容量结论全部作废重来；每场大促前例行压测——数据量涨了、代码演进了一年，去年的报告不能护今年的航。压测报告归档对比，容量退化趋势比单次结果更有价值。下一篇收官：回到崩掉的那一晚，把整条漏斗重新走一遍。