一、压测基础认知：吞吐量、QPS/TPS 与核心目标
各位好，我是老赵。做压测这行十几年了，今天咱们聊聊最基础、也最容易被误解的几个概念。
很多人一上来就问：“我这个系统能抗多少 QPS？” 但真让他解释什么是 QPS，什么是吞吐量，往往说不清楚。我见过不少团队，压测报告写得花里胡哨，结果上线第一天就挂了——因为连压测的目标都没搞明白。
这一章，咱们就把地基打牢。
1.1 什么是吞吐量？
吞吐量，说白了就是系统在单位时间内能处理多少活儿。
举个例子：你家小区门口只有一个快递驿站。一天 24 小时，最多能收 1000 件快递。那这个驿站的“吞吐量”就是 1000 件/天。
放到服务器上，吞吐量通常用两个指标衡量：
- 请求数/秒（比如 QPS、TPS）
- 数据量/秒（比如 MB/s、GB/s）
我个人习惯把吞吐量看作一个容量上限。它告诉你：系统最多能扛多少，超过这个数，要么排队，要么崩溃。
1.2 QPS 与 TPS：别再傻傻分不清
这两个词，面试常考，实战也常用。但很多人混着用，其实它们有区别。
| 指标 | 全称 | 含义 | 典型场景 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数 | 读多写少的系统（如搜索引擎、商品详情页） |
| TPS | Transactions Per Second | 每秒事务数 | 写操作多的系统（如支付、下单、转账） |
你想想看：一个查询接口，只查数据库，返回结果——这叫 QPS。一个下单接口，要扣库存、生成订单、调用支付——这叫 TPS，因为它是一个完整的事务。
我曾经在一个电商项目中踩过坑。团队把下单接口的压测结果写成“QPS 5000”，结果上线后数据库连接池被打满。为什么？因为下单接口内部调了 3 个服务、写了 4 张表，一个“请求”背后是多个“事务”。用 QPS 来衡量，完全失真。
1.3 压测的核心目标与价值
很多人觉得压测就是“测一下系统能扛多少并发”。嗯，这只是最表层的目的。
我个人把压测的核心目标总结为三点：
- 找上限：系统在什么条件下会崩溃？瓶颈在哪？
- 验稳定性：长时间高负载下，会不会内存泄漏、连接池耗尽？
- 做规划：根据压测结果，决定要不要扩容、要不要加缓存、要不要改架构。
说白了，压测的价值就一句话：用最小的成本，提前暴露问题。
我记得有一次帮一家金融公司做压测。他们的系统平时只有 200 QPS，但搞活动时预计会到 2000 QPS。团队觉得“加两台机器就行了”。结果一压，发现数据库的连接数配置只有 100，2000 QPS 一上来，连接池直接爆了。如果没做压测，活动当天就是事故。
1.4 知识体系总览
下面这张图，把本章的核心知识点串起来了。你可以把它当作压测认知的“地图”。
1.5 本章小结
这一章，咱们把压测最基础的概念捋了一遍：
- 吞吐量是系统的容量上限，单位时间内能处理多少请求或数据。
- QPS 适合读场景，TPS 适合写场景，别混用。
- 压测的核心目标是找上限、验稳定性、做规划，而不是刷一个好看的数字。