全链路压测：洪水来之前先演一遍

单机压测的谎言

只压单个接口、单个服务的压测，给出的数字是谎言：单服务压出 5000 QPS，全链路一压只剩 800——缓存命中率变了、连接池竞争变了、下游依赖也来分时间。容量必须全链路测：请求从网关进来，穿过所有服务、所有中间件，带着真实的依赖关系被打满，测出来的数字才是真的。

影子流量：压测的核心难题

直接拿生产真实流量压？写操作会把用户数据改乱。压测的核心难题：流量要真实，数据要隔离。三个配套缺一不可：流量标记——压测请求打上标记，一路透传，全链路的限流、路由、存储都知道「这是演习」；影子表——写操作落到同实例的影子表（shadow_ 前缀）或独立影子库，结构与真实表一致，数据可随时清空；中间件隔离——MQ 发影子 topic、Redis 写影子 key 前缀，谁都不污染。

// 入口识别压测流量，全链路透传
if ("1".equals(request.getHeader("X-Stress-Test"))) {
    StressContext.mark();   // 标记进 ThreadLocal，RPC/HTTP 头继续透传
}
// 下游写操作按标记路由
if (StressContext.isStress()) {
    tableRouter.routeTo("shadow_order");         // 写影子表
    mqTemplate.send("shadow_order_topic", msg);  // 发影子 topic
}

压测看什么

压测不是把数字打上去看系统喘不喘气，要带走四样东西：容量水位——每层的最大吞吐与拐点（QPS 曲线由涨转平、RT 由平转升的那一点）；最先垮的层——瓶颈排序，压完就知道该扩哪里；预案有效性——压测中手动触发限流、降级，验证真的生效且动作符合预期；恢复速度——洪峰退去后系统多久回到基线，有没有积压、有没有死连接。

安全红线

全链路压测是「在生产环境放火」，红线四条：低峰进行——避开业务高峰；全局开关——压测流量可一键熔断，演习自身出问题要能立刻停；数据可清理——影子数据带标记，压完即清；监控分流——压测流量单独打标上报，不污染真实监控基线，不然告警刷屏、容量基线全错。

机制、参数、演练都齐了——最后用真实事故来检验这套体系。下篇事故集锦：十个真实故障，对应本系列攒下的十件武器。