全链路压测：为什么单机压测会骗人
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 8 · 压测与容量 · 第 43/49 篇 · 🚧 占位待学
上一篇：《场景解剖四：秒杀系统（全链路总复习）》
下一篇：《影子体系：在生产环境安全地压测》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 8 · 单元 8.1
一、本文要解决的问题
每个服务单独压测都过万，拼起来 3000 就挂了——因为单机压测把依赖打了桩、把缓存喂热了、把连接池独占了，全是理想条件。全链路压测在真实拓扑、真实数据分布下找整条链路的短板，这是「设计扛 10 万」变成「实测扛 10 万」的唯一路径。
二、知识点清单
- 单机压测的四大盲区：依赖打桩失真、缓存全命中、共享资源（连接池 / 带宽）未竞争、数据分布理想化
- 全链路压测的定义：真实链路拓扑 + 真实流量模型（接口配比）+ 真实数据量，从入口统一施压
- 流量模型构建：按线上访问日志统计接口配比（如 70% 查询 / 20% 写入 / 10% 混合），回放 or 构造
- 施压端容量：施压机自身不能先成为瓶颈（分布式施压）
- 瓶颈定位方法论：自上而下逐层看水位（入口 → 应用 → 缓存 → DB），每层的「满了」长什么样
三、动手实验（学习时必须真跑）
- 对示例系统「网关 → 服务 → Redis → MySQL」做全链路阶梯压测（按接口配比 7:2:1）
- 每档记录各层水位：网关 QPS、应用线程池、Redis ops / CPU、MySQL 连接 / IO——找到第一个饱和的组件
- 优化该瓶颈（如加缓存 / 调连接池）后复测，记录容量提升；输出完整压测报告
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。