备案站点的全链路压测与影子环境实践

测试环境压出来的数字，上线那天不作数

「我们压过了，单机能扛三千」——然后大促当晚一千就崩了。原因不在压测工具，而在压测环境：数据量差几个数量级、下游全是挡板、机器规格和网络拓扑不同、缓存还是热的。这些差异叠加起来，测出来的数字与生产没有可比性。

所以成熟团队最终都会走到同一条路上：在生产环境压测。而生产压测真正的难点从来不是「怎么发压力」，而是「怎么不污染真实数据、不误伤真实用户」。

关键要点

• 生产压测的第一要件是压测流量可标识，且标识能贯穿全链路——同步调用、消息、定时任务、缓存键，断掉任何一段都会把压测数据写进真实表。
• 数据隔离靠影子表或影子库，缓存与消息主题也要同步隔离。
• 计费和外发类的第三方依赖必须挡板化，绝不能真发短信、真扣款。
• 必须有一键停止开关与自动熔断：真实用户的错误率一旦上涨就立刻停。

测试环境压不出真问题的四个原因

差异	导致的失真
数据量小几个量级	执行计划不同，慢查询根本压不出来，见 慢查询定位与索引优化
下游全是挡板	掩盖真实依赖的瓶颈与超时，见 第三方服务依赖治理
规格与拓扑不同	连接数上限、网络路径、缓存层级都不一致
缓存已被预热	命中率虚高，数据库承受的压力被严重低估

压测标识的贯穿：最容易出事的一环

入口给压测请求打标，然后这个标识必须一路传下去：同步调用放在请求头里、消息放在消息属性里、异步任务放进任务上下文、存储层据此路由到影子表、日志和指标带上它以便区分统计。

断点几乎总是出现在这几处：异步任务与消息消费（上下文没传下去）、定时补偿任务（根本不知道有压测这回事）、缓存键（没加前缀，压测数据把真实热点挤掉）、第三方回调（回调回来时标识丢了）。

省事的做法是复用链路追踪的上下文透传机制，它已经解决了同一个问题，见 可观测性建设；日志侧要能按标识过滤，见 日志规范与集中检索。

三种数据隔离方案

方案	做法	取舍
影子表	同实例、同结构、表名加前缀	能压出真实的 IO 与锁竞争，最接近真实，推荐
影子库	独立数据库实例	隔离彻底，但压不出资源竞争，结论偏乐观
标记列	同表加一列标记压测数据	最省事也最危险，报表、对账、风控都可能误读

影子表必须与真实表结构和索引完全一致，否则压出来的执行计划没有参考价值。除了数据库，缓存要用独立前缀或独立实例、消息要用独立主题、上传文件要用独立路径，见 对象存储与静态资源托管。

压力从哪里来

• 录制回放：把真实流量脱敏后回放，参数分布和热点集中度最接近真实，效果最好。
• 构造流量：成本低，但要刻意还原热点分布——均匀随机的请求会让缓存命中率虚高，严重低估真实压力。
• 渐进放大：按 1 倍、1.5 倍、2 倍逐档加，每档稳定观察一段时间，而不是一步顶到目标值。

比 QPS 数字更重要的是三件事：读写比例、参数分布、热点集中度。这三项不对，压测就是在测另一个系统。

挡板与风险控制

• 短信、支付、推送等外部依赖一律走挡板，并模拟合理的延迟与错误率——挡板永远不失败，是另一种失真。
• 告警与风控要能识别压测标识：目标是把压测流量单独归类，而不是整体屏蔽告警，否则压测期间的真实故障会被一起吞掉。
• 准备一键停止开关，并设置自动熔断条件（真实用户错误率或延迟超阈值就自动终止）。
• 压测窗口选低峰期，提前通知值班与客服，避免一次压测触发一次真实的应急响应，流程见 故障响应、复盘与 SLO 实践。

要盯的指标与结论怎么用

压测的产出不是「扛住了多少 QPS」，而是这四样：

• 性能拐点：吞吐不再上升而延迟开始陡增的那个点，它才是真实容量上限，换算方法见 容量规划与弹性伸缩。
• 瓶颈定位：CPU、连接池等待、队列积压、磁盘 IO 分别在哪一档先到顶，连接侧见 数据库连接池与连接数治理。
• 保护机制是否生效：限流有没有按预期触发、熔断有没有打开、降级页面对不对，见 限流、熔断与服务降级。
• 改进项清单：带责任人和期限，并约定复测时间。

收尾：最容易被忘记的一步

压测结束后要做三件事：清理影子数据（或给影子表配自动过期策略，见 数据生命周期与归档清理）、把挡板与开关恢复原状、把这次的容量基线写进台账。基线只有和上一次对比才有意义——同样的配置，这季度比上季度掉了三成，这种信息比单次数字有价值得多。

常见坑

• 标识在异步链路上断掉：压测数据混进真实表，事后极难清理。
• 只压读不压写：写路径的锁竞争与主从延迟完全没被验证。
• 只看平均值：平均值好看，P99 早已劣化，用户感知的是 P99。
• 压测把缓存冲垮：真实热点被淘汰，压测结束后一段时间内线上反而变慢。
• 发现的问题不闭环：下次压测出现同样的瓶颈。

常见问题

一定要在生产环境压测吗？

不是所有站点都需要。流量平稳、规模不大的站点，在结构一致的预发环境按比例压测已经够用。但只要有大促、投放、活动这类尖峰场景，生产压测的价值就无可替代——差异恰恰出现在测试环境无法复现的那部分。

影子表和影子库该怎么选？

要验证真实资源竞争（IO、锁、连接）就用影子表；只想验证业务逻辑吞吐、且对污染风险极度敏感时用影子库。多数团队从影子库起步，成熟后转向影子表。

压测流量会不会污染业务指标和报表？

会，除非指标和日志都按压测标识做了区分。上线压测能力时，指标体系和报表口径要同步改造，这部分工作量常被低估。

多久压一次合适？

大促前必压；架构或核心链路有较大变更后补压；日常按季度做一次基线复测即可。关键是形成可对比的基线序列，而不是每次都从零开始。

资料来源

主流压测工具与全链路压测的公开实践资料，以及链路追踪上下文透传相关的公开文档。本文为通用运维说明，仅供参考，具体方案请结合自身架构与风险承受度设计。