吞吐压测概述
吞吐压测，说白了就是看看你的系统到底能扛多少活。
我刚开始做性能优化那会儿，总觉得这玩意儿离我很远。直到有一次线上服务在双十一凌晨直接被打挂，老板站在我身后盯着屏幕，那眼神我这辈子都忘不了。嗯，从那以后，吞吐压测就成了我每个项目上线前的必修课。
什么是吞吐压测
吞吐压测，全称是吞吐量压力测试。它模拟大量用户同时访问你的系统，看看系统在极限状态下表现如何。
你可以把它想象成一座桥。平时走几个人没问题，但早晚高峰能扛住吗？能扛住多少人同时走？会不会塌？吞吐压测就是帮你找到这个答案的。
我个人习惯把吞吐压测分成两类：
- 基准压测：在理想环境下，测出系统的理论最大值
- 极限压测：在真实环境下，逐步加压直到系统崩溃
两者缺一不可。基准压测告诉你「最好能到多少」，极限压测告诉你「实际能到多少」。
为什么需要吞吐压测
这个问题我问过不少刚入行的朋友。他们的回答大多是「为了上线不出问题」。对，但不全对。
我在项目中遇到过这样一个案例：一个推荐系统，单机压测QPS能到5000，看起来很美。结果上线后，实际流量只有2000 QPS的时候，服务就开始频繁超时。为什么？因为压测时只测了接口本身，没考虑下游依赖的连锁反应。
吞吐压测的真正价值，我总结为三点：
- 发现瓶颈：CPU、内存、IO、网络，到底哪个先扛不住
- 验证容量：你的机器够不够，要不要扩容
- 评估稳定性：高负载下会不会抖动，会不会雪崩
核心观点：吞吐压测不是一次性的活动，而是持续的过程。每次代码变更、架构调整、硬件升级，都应该重新跑一遍。
吞吐压测的核心指标
聊指标之前，我想先问一个问题：你判断系统「快不快」的标准是什么？
很多人第一反应是「响应时间」。但响应时间快，不代表系统能处理很多请求。反过来，系统处理了很多请求，也不代表每个请求都很快。所以我们需要三个指标一起来看。
| 指标 | 全称 | 含义 | 我的经验值 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数 | 读场景的核心指标 |
| TPS | Transactions Per Second | 每秒事务数 | 写场景的核心指标 |
| RT | Response Time | 响应时间 | 用户体验的直接体现 |
QPS —— 每秒查询数
QPS 衡量的是系统每秒能处理多少个请求。它最常用于读多写少的场景，比如搜索引擎、内容推荐。
举个例子：你的首页接口 QPS 是 1000，意味着每秒有 1000 个用户同时请求首页数据。
我曾经优化过一个搜索服务，QPS 从 2000 提升到 8000。你以为我做了什么高大上的事情？其实只是把缓存策略从 LRU 换成了 LFU。有时候，瓶颈就在你想不到的地方。
TPS —— 每秒事务数
TPS 和 QPS 很像，但更强调「事务」的概念。一个事务可能包含多个操作，比如下单 = 扣库存 + 生成订单 + 扣款。
你想想看，如果一个接口内部调用了 3 次数据库，那它的 TPS 可能只有 QPS 的三分之一。这就是为什么压测时不能只看 QPS，还要看 TPS。
小技巧：我习惯在压测脚本里埋点，统计每个事务内部的子操作耗时。这样一旦 TPS 下降，能快速定位是哪个环节出了问题。
RT —— 响应时间
RT 就是用户从发出请求到收到响应的时间。它通常用百分位来衡量：
- P50：一半的请求在这个时间内完成
- P95：95% 的请求在这个时间内完成
- P99：99% 的请求在这个时间内完成
我一般重点关注 P99。为什么？因为 P50 好看不代表系统稳定，但 P99 如果飙升，说明有少数请求被严重阻塞了。这些「慢请求」往往是系统崩溃的前兆。
避坑指南：我曾经犯过一个错误——只看平均 RT。平均 RT 200ms，看起来很漂亮对吧？结果 P99 是 5 秒。也就是说，每 100 个用户里就有 1 个要等 5 秒才能看到页面。这种体验，用户不骂你才怪。
三个指标的关系
QPS、TPS、RT 不是孤立的。它们之间有一个经典的公式：
QPS = 并发数 / RT这个公式告诉我们：
- 并发数固定时，RT 越低，QPS 越高
- RT 固定时，并发数越高，QPS 越高
- 但并发数不是无限增加的，超过某个阈值，RT 会急剧上升
这就是所谓的「拐点」。找到这个拐点，是吞吐压测的核心目标之一。
知识体系总览
下面这张图，是我自己梳理的吞吐压测知识体系。你可以把它当作本章的思维导图：
这张图把本章的知识点串起来了。你顺着箭头看，就能理解吞吐压测的全貌。
好了，第一章就到这里。记住这三个指标，它们是后续所有优化的基础。下一章我们会聊压测工具的选择，到时候我会分享一些踩坑经验。
一句话总结：吞吐压测不是炫技，是保命。QPS、TPS、RT 三个指标，缺一不可。
想要更多资料，联系可可