1. 吞吐压测概述
大家好，我是你们的老朋友。今天咱们开始聊吞吐压测。
说实话，做了这么多年性能调优，我见过太多团队一上来就猛怼并发数，结果系统崩了还不知道问题出在哪。其实，压测的核心就三个字——吞吐量。你想想看，一个系统再花哨，如果每秒只能处理几个请求，那跟单机跑个脚本有啥区别？
什么是吞吐量？
吞吐量，说白了就是系统在单位时间内能处理多少活儿。我习惯把它理解成「系统的消化能力」。就像一个人吃饭，你给他端十碗面，他能不能在十分钟内吃完？能吃完几碗？这就是吞吐量。
在技术层面，吞吐量通常用两个指标来衡量：
- TPS（Transactions Per Second）：每秒完成的事务数。一个事务可能包含多个操作，比如下单、支付、扣库存。
- QPS（Queries Per Second）：每秒查询数。通常用于读多写少的场景，比如搜索引擎、商品列表页。
嗯，这里要注意：很多人把 TPS 和 QPS 混着用，其实不太严谨。我在项目中遇到过好几次，开发说 QPS 能到 5000，结果一压测，TPS 只有 800。为什么？因为一个事务里可能包含了 6 个查询。你想想看，如果只看 QPS，很容易被表象迷惑。
核心公式：
吞吐量 = 并发数 × 单请求响应时间
但注意，这个公式是理想状态。实际中，并发数一上去，响应时间就会变长，吞吐量会先升后降。
TPS 和 QPS 到底怎么选？
我个人习惯这样区分：
| 场景 | 推荐指标 | 原因 |
|---|---|---|
| 电商下单、支付 | TPS | 一个事务包含多个步骤，TPS 更能反映真实处理能力 |
| 新闻列表、搜索 | QPS | 主要是查询，事务边界不明显 |
| 混合场景（读写都有） | 两者都看 | 我曾经踩过坑，只看 QPS 导致写链路被打爆 |
举个例子。我之前帮一家金融公司做压测，他们的核心业务是「用户开户」。这个操作涉及：身份校验、征信查询、账户创建、短信通知。如果只看 QPS，征信查询接口的 QPS 很高，但整个开户流程的 TPS 却很低。为什么？因为征信查询是异步的，真正的瓶颈在账户创建的数据库写入上。
我的建议：压测时优先关注 TPS，尤其是涉及写操作的场景。QPS 可以作为辅助指标，但别拿它当唯一标准。
压测的核心目标是什么？
很多人以为压测就是为了测出系统能扛多少并发。其实不对。压测的核心目标有三个：
- 找到瓶颈：系统到底卡在哪？是 CPU 满了？数据库连接池不够？还是网络带宽打满了？
- 验证容量：系统在目标吞吐量下，能不能稳定运行？响应时间是否在可接受范围内？
- 指导调优：压测结果告诉你该优化哪里。是加机器？还是改代码？还是调参数？
我记得有一次，一个团队说他们的系统能扛 10000 QPS。我一压，发现 2000 QPS 时响应时间就飙到了 5 秒。他们很惊讶，说「我们代码没问题啊」。结果一查，是数据库连接池配了 10 个。你想想看，10 个连接怎么扛 10000 QPS？这就是典型的「没压测就上线」的后果。
压测的价值到底在哪？
说白了，压测的价值就一句话：让你在线上出问题之前，先知道问题在哪。
我见过太多线上事故了：
- 双十一零点，系统直接挂了，因为没压过峰值流量
- 上线一个新功能，结果把老接口拖慢了，因为没做隔离压测
- 数据库连接池爆了，因为没压过极限并发
这些事故，其实都可以通过压测提前发现。压测不是「测一下能不能跑」，而是「测一下能跑多快、能扛多狠、瓶颈在哪」。
避坑指南：我曾经犯过一个错误——压测时只测了正常场景，没测异常场景。结果线上一个慢查询把整个数据库拖死了。从那以后，我压测一定会加「异常注入」，比如模拟网络延迟、数据库超时、第三方服务挂掉。你想想看，如果压测时没测过这些，线上出了事你连锅都甩不出去。
本章知识体系
下面这张图，是我自己总结的吞吐压测知识框架。你可以把它当成一张地图，后面每章都会围绕这些点展开。
这张图把吞吐压测拆成了三个维度：概念、目标、价值。后面每一章，我都会围绕这些点深入展开。比如下一章咱们会聊「压测工具怎么选」，再后面会讲「参数怎么调」。但不管讲什么，核心都是这张图里的东西。
好了，第一章就到这里。记住一句话：吞吐量是系统的命，压测是保命的工具。后面咱们慢慢聊。