吞吐压测概述：从定义到落地
大家好，我是这次课程的主讲。做性能压测这么多年，我见过太多团队把吞吐量挂在嘴边，但真要问起来——「吞吐量到底怎么定义？TPS和QPS是不是一回事？」——能说清楚的人真不多。
这一章，咱们就把这些基础概念掰开揉碎了讲。别小看这些定义，我踩过的坑，十有八九都是基础不牢导致的。
吞吐量定义：系统「搬砖」的能力
吞吐量，说白了就是系统在单位时间内能处理多少请求。你可以把它想象成一个快递分拣中心——每小时能分拣多少包裹，就是吞吐量。
在计算机世界里，吞吐量通常用两个指标来衡量：
- 请求数/秒：比如每秒处理1000个HTTP请求
- 数据量/秒：比如每秒传输50MB数据
我个人习惯把吞吐量看作系统的「体力活」能力。你想想看，一个系统如果吞吐量上不去，响应时间再短也没用——就像一辆跑车，速度再快，一次只能拉一个人，那也成不了物流巨头。
核心公式：吞吐量 = 完成请求数 / 耗时
注意，这里的「完成请求」必须是成功处理的，重试、超时的都不算。
TPS与QPS区别：别再傻傻分不清
这是面试高频题，也是实际工作中最容易混淆的概念。我直接说结论：
| 指标 | 全称 | 含义 | 典型场景 |
|---|---|---|---|
| TPS | Transactions Per Second | 每秒完成的事务数 | 数据库事务、下单流程 |
| QPS | Queries Per Second | 每秒完成的查询数 | 读接口、搜索请求 |
嗯，这里要注意：一个事务可能包含多个查询。比如你在电商平台下单，这个「下单」是一个事务，但它背后可能涉及：查询库存、扣减库存、生成订单、更新用户积分……这些每一步都是一个查询。
所以，TPS 和 QPS 的关系是：
- 如果系统只有查询操作（比如搜索引擎），TPS ≈ QPS
- 如果系统有复杂事务（比如支付系统），TPS 通常远小于 QPS
我的经验：在压测报告中，我习惯同时给出 TPS 和 QPS。如果只给一个，别人会追问「你测的是事务还是查询？」——别给自己找麻烦。
压测核心指标：不止是吞吐量
吞吐量很重要，但它不是全部。我见过有人只盯着 TPS，结果系统吞吐量上去了，用户却骂声一片——为什么？因为响应时间爆炸了。
做压测，你必须同时关注这「三驾马车」：
- 吞吐量（TPS/QPS）：系统能扛多少
- 响应时间（RT）：用户等多久
- 错误率：系统稳不稳
这三者互相制约。你想想看：
- 吞吐量上去了，响应时间通常会变长
- 响应时间变长，用户容易超时重试，错误率就上来了
- 错误率高了，系统实际完成的请求反而少了
避坑指南：我曾经接手过一个项目，压测报告显示 TPS 高达 5000，但响应时间 P99 是 8 秒。这数据看着漂亮，实际上线后用户全跑了。记住：没有响应时间约束的吞吐量，都是耍流氓。
除了这三驾马车，还有几个指标也值得关注：
- 并发数：系统同时处理的连接数
- CPU/内存使用率：资源消耗情况
- P99/P95 响应时间：长尾延迟，比平均响应时间更有参考价值
压测在研发流程中的位置
很多团队把压测放在上线前最后一刻，这是大忌。我见过最惨的一次：上线前压测发现系统扛不住，但代码已经合并，回滚成本巨大，最后只能硬着头皮上线——结果可想而知。
压测应该贯穿整个研发流程：
| 阶段 | 压测目的 | 我的建议 |
|---|---|---|
| 需求阶段 | 确定性能目标（目标TPS、RT） | 和产品、业务一起定，别自己拍脑袋 |
| 开发阶段 | 单接口压测，发现代码级瓶颈 | 每个接口提测前，开发自己跑一遍 |
| 集成阶段 | 全链路压测，模拟真实场景 | 这是最关键的，别跳过 |
| 预发阶段 | 容量评估，确定集群规模 | 根据压测结果决定要不要加机器 |
| 上线后 | 持续监控，对比压测数据 | 线上数据才是最终检验标准 |
我个人习惯在「集成阶段」做一次完整的全链路压测。为什么？因为单接口压测没问题，不代表组合起来没问题。数据库连接池、线程池、缓存……这些资源在真实场景下会互相争抢，只有全链路压测才能暴露这些问题。
一句话总结：压测不是上线前的「体检」，而是研发流程中的「日常锻炼」。平时不锻炼，比赛时肯定掉链子。
本章知识体系
下面这张图，是我梳理的本章核心逻辑。你可以把它当作一个思维导图来理解：
这张图把本章的四个核心知识点串起来了。你从上往下看：先搞清楚吞吐量是什么，再区分 TPS 和 QPS，然后掌握核心指标，最后知道压测该在什么时候做。每一步都是下一步的基础。
我的建议：把这四个知识点记在脑子里，以后做压测方案时，按这个框架去思考，基本不会漏掉关键点。
好了，这一章就到这里。下一章我们会深入讲压测场景的设计方法——怎么设计场景才能真实反映线上情况？到时候我会分享几个我踩过的坑，保证让你少走弯路。