吞吐压测概述：从指标到本质
吞吐压测，说白了就是给系统灌流量，看它能扛多少。我入行那会儿，有个前辈跟我说过一句话，我一直记着——「压测不是为了让系统挂，而是为了知道它什么时候会挂。」这句话，到今天依然适用。
你想想看，一个线上服务，平时跑得好好的，突然流量翻了三倍，结果会怎样？是丝滑扩容，还是直接雪崩？吞吐压测，就是提前回答这个问题。
什么是吞吐压测
吞吐压测，全称是「吞吐量压力测试」。它跟并发压测不一样。并发压测关心的是「同时有多少人在用」，吞吐压测关心的是「单位时间内能处理多少请求」。
举个例子：
一个外卖平台的订单接口，并发压测看的是「同时有 1000 个人下单，系统会不会报错」。
吞吐压测看的是「1 秒钟内，这个接口能成功处理多少笔订单」。
这两个维度，一个看空间，一个看时间。我个人的习惯是：先跑吞吐压测，摸清系统的天花板，再去做并发压测，找具体的瓶颈点。
为什么需要吞吐压测
很多团队觉得压测可有可无，上线前跑一跑就行。但我在项目中遇到过不止一次，线上出问题，回看压测报告，发现吞吐量指标早就预警了，只是没人看。
吞吐压测的价值，我总结为三点：
- 容量规划 —— 知道系统能扛多少，才能决定要部署多少台机器。我见过一个团队，双十一前凭感觉加机器，结果加多了浪费，加少了扛不住。后来老老实实做吞吐压测，每台机器的 QPS 上限摸得清清楚楚，扩容方案一次过。
- 性能基线 —— 每次代码上线，吞吐量是涨了还是跌了？没有基线数据，你根本不知道这次重构是优化还是劣化。我曾经接手过一个老项目，压测后发现吞吐量只有文档标注的 30%，查了三天，发现是连接池配置被误改了。
- 瓶颈定位 —— 吞吐量上不去，到底是 CPU 满了、内存不够、IO 瓶颈，还是数据库扛不住了？压测报告会告诉你答案。
吞吐量核心指标解析
聊吞吐压测，绕不开三个字母：QPS、TPS、RPS。很多人混着用，其实它们有区别。我刚开始也搞混过，直到有一次在压测报告里写错了指标，被架构师当场指出来……嗯，从那以后我再也没弄错过。
| 指标 | 全称 | 含义 | 典型场景 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数 | 读多写少的系统，如搜索引擎、内容列表 |
| TPS | Transactions Per Second | 每秒事务数 | 金融交易、订单系统，一个事务包含多个步骤 |
| RPS | Requests Per Second | 每秒请求数 | 通用指标，HTTP 接口、API 网关 |
这里有个容易踩的坑：QPS 和 RPS 在大部分场景下可以互换，但 TPS 不行。
为什么？因为一个事务（Transaction）可能包含多个请求（Request）。比如你在电商平台下单，前端会先后调用「创建订单」「扣减库存」「生成支付链接」三个接口。对后端来说，这是三个请求，但业务上只算一个事务。
指标之间的关系
这三个指标不是孤立的。我习惯用一个公式来理解它们的关系：
吞吐量 = 并发数 × 单请求耗时举个例子：
假设一个接口平均响应时间是 50ms，那么单线程每秒能处理 20 个请求（1000ms / 50ms）。
如果并发数是 100，理论吞吐量就是 20 × 100 = 2000 QPS。
但现实往往比理论残酷。随着并发数增加，响应时间会变长，吞吐量不会线性增长。我见过一个系统，并发从 100 升到 200，吞吐量只涨了 30%，因为 CPU 已经打满了。
本章知识体系
下面这张图，是我自己梳理的吞吐压测知识框架。你可以把它当作本章的思维导图：
小结
吞吐压测不是玄学，它是一套可量化的方法论。你只需要记住三件事：
- 吞吐压测测的是「单位时间处理能力」，不是「同时在线人数」。
- QPS、TPS、RPS 各有适用场景，选错了指标，压测结果就是废的。
- 吞吐量存在上限，找到这个上限，就是压测的核心目标。