压测入门：不压测，一切架构都是猜
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 1 · 接入层扩展 · 第 8/49 篇 · 🚧 占位待学
上一篇：《线程模型：从 BIO 到 NIO，百万连接的地基》
下一篇：《数据库为什么先死：读懂 MySQL 的极限》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 1 · 单元 1.5
一、本文要解决的问题
「这个优化有效吗」「单机能扛多少」——所有这类问题只有一个答案来源：压测。但压测也最容易自欺：压到了缓存、压满了客户端本机、连接没复用……得出虚高或虚低的结论比不压更危险。
二、知识点清单
- 压测四类型：基准压测（单个接口上限）/ 负载压测（日常水位）/ 压力压测（找极限）/ 稳定性压测（浸泡）
- wrk 核心：连接数 / 线程数 / 时长的关系，Lua 脚本定制请求
- JMeter 的适用场景（复杂场景编排、GUI 陷阱）与 wrk 的分工
- 压测指标解读：QPS、RT 分位、错误率，以及「饱和点」的判定（QPS 不再涨 + RT 陡升）
- 压测五大陷阱：客户端瓶颈、缓存全命中、连接不复用、数据集太小、本机压本机
- 压测报告模板：环境、模型、数据、结论、瓶颈初判
三、动手实验（学习时必须真跑）
- 对带 MySQL 查询的接口做阶梯加压（并发 10 → 400 递增），每档记录 QPS / RT / 错误率
- 画出「QPS-并发数」与「RT-并发数」双曲线，标出饱和点
- 故意制造一个陷阱对照：先压只查同一条数据的接口（缓存全命中），再压随机 id 接口，对比虚高幅度
四、验收标准（全部通过才进入下一篇）
五、阶段验收（本篇是阶段 1收尾篇）
六、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。