一篇读懂全链路压测：影子库、流量标记与容量规划

「大促前系统能不能扛住」不能靠猜——每一次大促（双 11、618）都是对系统容量的一次终极考验。单接口压测（用 JMeter 或 wrk 压某个接口）只能测出单点的极限，无法发现服务间调用链上的瓶颈——全链路压测（End-to-End Load Testing）用真实的流量模型、在预发或生产环境、做完整的端到端测试。本篇讲清全链路压测的完整方案。

全链路压测 vs 单接口压测

单接口压测的局限：只测单个接口的性能（如某个查询接口的 QPS 上限），无法覆盖「一次用户操作触发的多服务调用链」——用户的下单操作触发「订单服务 → 库存服务 → 支付服务 → 通知服务」的完整调用链，链路上任何一个服务的瓶颈都会限制整条链的吞吐——单接口压测无法发现这种「链路级瓶颈」。全链路压测的思路：模拟真实的用户行为（下单、支付、浏览），在完整的服务链路上施压——测试的不是「单点的极限」，是「全链路的极限」。全链路压测的核心挑战：如何在生产环境中压测而不污染真实数据。

影子库：压测数据的隔离方案

影子库（Shadow Database）的思路：为压测流量创建「影子」的数据存储——压测产生的数据（订单、支付、用户）写入影子表（如 shadow_order）而非真实表（order），Redis 写入影子 key（前缀标记），消息队列发送到影子 topic。实现的方式有三种：方式一：影子表——数据库中创建与真实表结构一致的影子表（shadow_ 前缀），压测流量通过数据源路由写入影子表（应用层根据流量标记切换数据源）；方式二：独立影子库——创建一个独立的影子数据库实例，压测流量全部路由到影子库（隔离更彻底，但成本高——需要维护两套数据库）；方式三：影子 topic——消息队列中创建影子 topic（shadow_order_created），压测消息发送到影子 topic——下游消费者订阅影子 topic 处理压测消息。

影子库的关键前提是「流量标记」：每个压测请求携带一个标记（如 HTTP Header X-Load-Test: true），标记沿着调用链传播（HTTP 头透传、消息体携带、RPC Context 传递），每个服务检测到标记后切换数据源到影子库——标记的透传需要所有服务配合改造（RPC 框架、消息队列、线程池的上下文传递都需要支持标记透传）——全链路压测的工程改造量主要集中在「标记透传」上。

容量规划：从压测结果到扩容决策

压测的目的不是「跑一遍」而是「指导扩容」。压测结果的分析：找出瓶颈点（哪个服务的 CPU/内存/连接池先到达极限——本库《操作系统内功 · 性能观测》的方法论）、绘制容量曲线（随流量增加，各服务的资源消耗曲线——找到「拐点」，即吞吐量不再增长的流量阈值）。扩容决策：根据预期流量与压测结果计算「需要多少实例、多少数据库连接、多少缓存容量」——例如压测发现「1000 QPS 时数据库连接池耗尽」，预期大促流量 5000 QPS，则需要扩容 5 倍的数据库连接容量（或引入缓存减少数据库访问）。容量规划不是一次性的——每次大功能上线、每次流量增长后都需要重新压测与规划——容量规划是一个持续的过程，不是一次性的任务。

全链路压测的「标记透传」：RPC 框架与消息队列的改造

全链路压测的核心前提是「流量标记的全链路透传」——标记从入口一直传递到最后的数据库写入。RPC 框架的透传：Dubbo 的 RpcContext attachment、gRPC 的 metadata、Spring Cloud 的 HTTP Header——每个 RPC 框架都有自己的上下文传递机制，标记的透传需要在每种框架中实现拦截器。消息队列的透传：Kafka 的消息 Header、RocketMQ 的消息属性——消息的属性可以携带标记，消费者从消息属性中提取标记并继续透传。线程池的透传：异步处理时线程切换会导致 ThreadLocal 丢失——需要使用 TransmittableThreadLocal（阿里开源的 TTL 库——在提交任务时捕获上下文、在执行任务时恢复上下文）。标记透传的改造量是全链路压测最大的成本项——每个 RPC 框架、消息队列、线程池都需要改造——这也是为什么很多团队选择在「流量入口层」统一标记（网关添加标记 + 全链路的 AOP 拦截器自动透传）而不是逐个改造。

全链路压测的「影子Redis」：缓存层的隔离

全链路压测的影子库方案需要覆盖 Redis 缓存层——压测的数据不能写入真实的 Redis 缓存。影子 Redis 的方案：为压测流量分配独立的 Redis 前缀（如 shadow: 前缀）或独立的 Redis 实例——压测流量通过流量标记（本库《标记透传》的机制）识别后自动切换到影子 Redis。应用层的改造：Redis 的 key 生成函数检查流量标记——有标记则在 key 前加 shadow: 前缀——Redis 操作（GET/SET/DEL）自动路由到影子 key。影子 Redis 的清理：压测结束后批量清理影子 key（SCAN 命令遍历并删除 shadow: 前缀的 key——避免残留数据影响真实的缓存命中率）。影子 Redis 的意义：压测的缓存读写不会影响真实的缓存命中率与数据正确性——压测与真实流量的隔离做到了缓存层。

全链路压测的影子 Redis

全链路压测的影子库方案需要覆盖 Redis 缓存层。影子 Redis 的方案为压测流量分配独立的 Redis 前缀或独立的 Redis 实例。应用层的改造 Redis 的 key 生成函数检查流量标记有标记则在 key 前加 shadow 前缀。影子 Redis 的清理压测结束后批量清理影子 key 避免残留数据影响真实的缓存命中率。影子 Redis 的意义压测的缓存读写不会影响真实的缓存命中率与数据正确性。

全链路压测的影子 Redis 与容量规划

全链路压测的影子库方案需要覆盖 Redis 缓存层。影子 Redis 的方案为压测流量分配独立的 Redis 前缀或独立的 Redis 实例。容量规划从压测结果到扩容决策——找瓶颈点绘容量曲线按预期流量计算扩容方案。容量规划不是一次性的——每次大功能上线每次流量增长后都需要重新压测与规划——容量规划是一个持续的过程不是一次性的任务。

全链路压测的「数据构造」：模拟真实流量分布

全链路压测的效果取决于「压测数据的真实度」——如果压测数据的分布与真实流量差异大，压测结果的可信度就打折。真实流量分布的特征：请求的路径分布（哪些接口是热点——遵循帕累托法则，20% 的接口承载 80% 的流量）、请求的参数分布（参数值的分布不是均匀的——热门商品 ID 被频繁查询）、请求的时间分布（高峰与低谷的流量差异可能是 10 倍以上）。数据构造的方法：从生产日志中采样（记录真实请求的分布——用生产日志回放比手工构造更真实）；按生产日志的分布生成压测数据（热门商品 ID 的查询频率与生产一致）。数据构造的纪律：压测数据的分布必须尽可能接近真实流量——否则压测通过不代表大促能扛住。

全链路压测的「压测报告」：从数据到决策

全链路压测的价值在于压测报告——将数据转化为可执行的决策。压测报告的核心内容：容量结论（系统能承受的最大 QPS）、瓶颈清单（哪些服务或组件是瓶颈——CPU/内存/连接池/下游依赖的瓶颈分析）、扩容建议（需要增加多少实例/连接/缓存才能支撑目标流量）、风险清单（哪些风险没有被发现——未压测的链路、未模拟的故障场景）。压测报告的格式：不需要正式文档——一个仪表盘（Grafana 的压测面板）加一个会议（压测结果的评审会）就够了——关键是让决策者看到数据而不是看 PPT。压测报告的终极目标：让「大促前系统能不能扛住」从「猜」变成「有数据支撑的判断」。

全链路压测的「压测报告」模板与决策矩阵

全链路压测的报告需要包含四个部分。第一部分：压测环境描述——部署拓扑、数据量、压测时长、压测工具（让人知道测试的条件）。第二部分：性能指标汇总——最大 QPS、P50/P99 延迟、错误率、各服务的资源消耗（CPU 内存 连接池）——表格形式一目了然。第三部分：瓶颈分析——找到的瓶颈点（哪个服务的哪个资源先到达极限）与瓶颈的原因分析（连接池太小？缓存命中率低？下游依赖慢？）。第四部分：扩容建议——需要增加多少实例/连接/缓存才能支撑目标流量，每项扩容的成本估算。压测报告的终极目标：让「大促前系统能不能扛住」从猜变成有数据支撑的判断——这个判断直接影响扩容的预算与上线的时间表。

小结

全链路压测收成四条：全链路压测 vs 单接口压测——单接口只能测单点极限，无法发现链路级瓶颈；影子库隔离压测数据——影子表 + 独立影子库 + 影子 topic，核心前提是「流量标记」的全链路透传；容量规划从压测结果到扩容决策——找瓶颈点、绘容量曲线、按预期流量计算扩容方案；容量规划是持续过程不是一次性任务。全链路压测的投入很大（改造标记透传、搭建影子库、编写压测脚本），但它买的是「大促当晚不炸」的信心——这份信心，是任何监控告警都替代不了的。

参考资料

• 本库前篇：《一篇读懂限流器》《操作系统内功 · 第 10 篇｜性能观测方法论》《LLM 应用的可观测性》
• 全链路压测的行业实践（阿里双 11 全链路压测的公开技术分享）
• JMeter / wrk / Gatling —— 压测工具的选型参考