吞吐压测概述：到底什么是吞吐压测？
吞吐压测，说白了就是给系统“称体重”。
你想想看，一个系统上线前，总得知道它能扛多少流量吧？我刚开始做运维那会儿，就吃过这个亏。有一次新系统上线，没做压测就直接上了生产，结果用户一多，服务器直接挂了。嗯，从那以后，我再也不敢跳过吞吐压测了。
吞吐压测的核心目的，就是摸清系统的处理能力上限。它不像压力测试那样非要搞崩溃系统，而是更关注“系统在正常负载下能处理多少请求”。
为什么需要吞吐压测？
我个人习惯把吞吐压测比作“体检”。你总得知道自己的心脏能跳多快、肺活量有多大，才能去跑马拉松吧？系统也一样。
- 容量规划：知道系统能扛多少并发，才好决定买几台服务器。我在项目中遇到过，客户拍脑袋买了10台机器，结果压测发现2台就够了，白白浪费钱。
- 性能基线：每次代码上线前跑一遍压测，对比数据。如果吞吐量下降了，说明新代码有问题。这个习惯帮我抓过不少bug。
- 瓶颈定位：吞吐量上不去，到底是数据库慢？还是网络带宽不够？压测数据会告诉你答案。
- SLA保障：合同里写了“支持1000 QPS”，你总得证明给客户看吧？吞吐压测就是最好的证据。
核心观点：吞吐压测不是“要不要做”的问题，而是“什么时候做”的问题。越早做，成本越低。
吞吐压测的核心指标
做吞吐压测，你得盯住四个关键指标。我管它们叫“四大金刚”。
1. QPS（每秒查询数）
QPS全称是Queries Per Second，指系统每秒能处理的查询请求数量。说白了，就是“一秒钟能回答多少个问题”。
举个例子：你打开一个网页，浏览器会发出很多请求——加载HTML、CSS、图片、接口数据。每个请求都算一次QPS。
我曾经帮一个电商平台做压测，发现他们的QPS峰值只有200。但大促期间预估流量是2000 QPS。嗯，这差距，不压测根本发现不了。
2. TPS（每秒事务数）
TPS全称是Transactions Per Second，指系统每秒能完成的事务数量。一个事务可能包含多个请求。
比如你在电商网站下单：先查询商品信息（QPS），然后提交订单（QPS），最后支付（QPS）。这三个请求合起来，才算一个完整的事务（TPS）。
| 指标 | 含义 | 典型场景 |
|---|---|---|
| QPS | 每秒查询数 | 搜索、列表页、详情页 |
| TPS | 每秒事务数 | 下单、支付、注册 |
小技巧：我个人习惯先看TPS，再看QPS。因为TPS更能反映业务处理能力。QPS高不一定代表系统好，可能只是缓存命中率高而已。
3. 并发数
并发数，就是系统同时能处理多少个请求。注意，是“同时处理”，不是“同时到达”。
你想想看，一个餐厅有10张桌子，同时来了20桌客人。那10桌在吃，另外10桌在排队。并发数就是“正在吃饭的桌子数”，不是“排队的桌子数”。
我在项目中遇到过，有人把并发数设得特别高，结果系统直接OOM了。为什么？因为并发数太高，内存不够用了。所以并发数不是越大越好，得结合系统资源来看。
4. 响应时间
响应时间，就是用户发一个请求，到收到回复需要多久。通常看三个值：
- 平均响应时间：所有请求的平均值。容易被极端值拉偏。
- P95响应时间：95%的请求都在这个时间内完成。我比较看重这个。
- P99响应时间：99%的请求都在这个时间内完成。对性能要求高的系统必须看。
举个例子：一个接口平均响应时间是100ms，但P99是2秒。说明有1%的用户体验很差。嗯，这就是优化的方向。
注意：这四个指标是联动的。并发数高了，响应时间会变长，QPS/TPS可能先升后降。我见过太多人只看一个指标，结果被坑了。
知识体系结构图
下面这张图，帮你理清吞吐压测的核心逻辑：
这张图很直观：吞吐压测围绕四个核心指标展开，每个指标都有它的侧重点。而做压测的目的，就是为了容量规划、性能基线、瓶颈定位和SLA保障。
一句话总结：吞吐压测就是给系统做体检，QPS/TPS/并发数/响应时间是体检报告上的四个关键数据。看不懂这些数据，就别谈性能优化。
好了，这一章就到这里。记住这四个指标，后面我们会一个一个拆开来讲。嗯，到时候我会分享更多实战中的坑和技巧。