一、吞吐压测概述：什么是吞吐压测、吞吐量核心指标（QPS/TPS）、压测的价值与误区
1.1 吞吐压测到底在测什么？
吞吐压测，说白了就是看系统「扛不扛得住」。
我经常跟团队里的小伙伴说：别把压测想得太玄乎。它本质上就是模拟一堆用户同时访问你的系统，看看系统会不会崩，响应会不会慢。
举个例子。你开了一家奶茶店。平时一个顾客来点单，你3分钟做好一杯。突然来了100个人排队，你还能3分钟出一杯吗？不能。那10分钟出一杯呢？可能也不行。到底能扛多少人？这就是吞吐压测要回答的问题。
我个人习惯把吞吐压测分成两类：
- 容量测试：系统最多能处理多少请求？
- 压力测试：系统在极限负载下表现如何？会不会挂？
嗯，这里要注意：吞吐压测不是功能测试。功能测试关心「对不对」，吞吐压测关心「快不快、稳不稳」。
1.2 核心指标：QPS 和 TPS
聊吞吐，绕不开两个词：QPS 和 TPS。
很多新手搞混这两个概念。我刚开始做压测时也犯过这个错——把 QPS 当 TPS 报给老板，结果线上出了大问题。
QPS（Queries Per Second）
每秒查询数。说白了就是系统每秒能处理多少个请求。
比如你的首页接口，每秒能响应 1000 次请求，那 QPS 就是 1000。
TPS（Transactions Per Second）
每秒事务数。一个事务可能包含多个请求。
举个例子：用户下单。这个「下单」动作，可能包含：查询商品 → 创建订单 → 扣减库存 → 支付。这一整套才算一个事务。
什么时候用 QPS？什么时候用 TPS？
我个人习惯这样区分：
- 纯查询接口（比如搜索、列表页）→ 用 QPS
- 涉及写操作、多步骤的业务（比如下单、转账）→ 用 TPS
重要提醒： 别只看一个指标。QPS 高不代表系统好。我见过一个系统 QPS 冲到 5000，但事务成功率只有 60%。这种压测结果，说白了就是自欺欺人。
1.3 其他关键指标
除了 QPS/TPS，还有几个指标必须关注：
| 指标 | 说明 | 我的经验值 |
|---|---|---|
| 响应时间（RT） | 从发请求到收到响应的时间 | 一般要求 P99 < 200ms |
| 并发数 | 同一时刻有多少请求在处理 | 不是越大越好，要看系统设计 |
| 错误率 | 请求失败的百分比 | 超过 1% 就要报警 |
| 资源利用率 | CPU、内存、IO 的使用情况 | CPU 建议 70% 以下，别跑满 |
你想想看，如果响应时间从 50ms 飙到 5s，QPS 再高有什么用？用户早跑了。
1.4 压测的价值：为什么必须做？
我遇到过不少团队，上线前不做压测，结果线上出事故。说白了，压测的价值就三点：
- 提前发现瓶颈：数据库扛不住？代码有死锁？压测一跑，问题全现形。
- 验证容量规划：服务器要配多少台？带宽够不够？压测数据告诉你答案。
- 保障用户体验：双十一、秒杀活动，系统能不能扛住？压测过了才敢上线。
我的小技巧： 压测最好在开发阶段就做，别等到上线前一周。我曾经在一个项目里，上线前三天才做压测，结果发现数据库连接池配小了，改完代码重新部署，差点没赶上发布时间。
1.5 常见误区：这些坑我踩过
做吞吐压测这么多年，我见过太多误区。挑几个典型的说说：
误区一：压测环境跟生产环境不一样
「我在 4 核 8G 的机器上压测，QPS 有 2000，上线肯定没问题。」—— 这话我听过无数次。结果呢？生产环境是 16 核 64G，但网络带宽、磁盘 IO、数据库连接数都不一样，压测结果根本不准。
误区二：只压一个接口
很多团队只压登录接口，觉得登录过了就万事大吉。但真实场景是：用户登录后还要查数据、下单、支付。只压一个接口，说白了就是掩耳盗铃。
误区三：压到系统崩溃才算完
我曾经见过一个测试，把系统压到 CPU 100%、内存爆满、服务宕机，然后报告说「系统扛不住」。嗯，这确实测出了极限，但实际业务中谁会这么用？压测的目的是找到安全水位，不是找死亡线。
避坑指南： 我曾经犯过一个低级错误——压测时忘了关日志。结果压了 10 分钟，磁盘写满了，系统直接挂了。后来我养成了习惯：压测前先检查日志级别、磁盘空间、监控告警是否开启。
1.6 本章知识体系
下面这张图，是我自己总结的吞吐压测知识框架。你一看就明白：
1.7 小结
吞吐压测不是花架子，它是保障系统稳定性的最后一道防线。
记住三点：
- 指标要全面：别只看 QPS，响应时间、错误率、资源利用率都得看
- 环境要真实：压测环境越接近生产，结果越可信
- 误区要避开：别自欺欺人，压测是为了发现问题，不是为了交差
嗯，这一章就聊到这儿。下一章我们开始动手，讲怎么搭建压测环境、选工具。到时候我会分享一些我常用的脚本模板，你直接拿来就能用。