一、压力测试基础

什么是压力测试

压力测试，说白了就是「故意找茬」。

你搭建好一套交易系统，平时跑得挺欢。但你想过没有——如果突然涌进来10倍、100倍的订单，系统会怎样？

我刚开始做交易系统那会儿，就吃过这个亏。上线前觉得「差不多了」，结果双十一流量一上来，数据库连接池直接打满，订单全部超时。嗯，那晚我睡在机房，盯着监控屏幕发呆。

压力测试就是模拟这种极端场景。它不关心你的业务逻辑对不对，只关心一件事：系统到底能扛多少。

为什么需要压力测试

你可能觉得：「我的系统平时负载不高，有必要吗？」

我跟你讲个真实案例。有个做期货交易的朋友，系统平时每秒处理200笔订单，他觉得绰绰有余。结果某天突发行情，瞬间涌入5000笔订单——系统直接挂了，恢复用了40分钟。那40分钟里，每秒钟都在亏钱。

压力测试的价值，体现在三个层面：

• 发现瓶颈——数据库、缓存、网络、CPU，哪个先扛不住？
• 验证容量——系统到底能支撑多少用户、多少交易量？
• 保障稳定性——高负载下会不会崩溃？崩溃后能不能快速恢复？

压力测试的核心指标

聊指标之前，先看一张图。这张图是我自己画的，帮你理解这几个指标之间的关系。

好，我们一个一个说。

1. TPS（每秒事务数）

TPS 全称是 Transactions Per Second。它衡量的是系统每秒能完成多少个完整的事务。

什么叫「完整的事务」？在交易系统里，一个事务可能包含：下单→扣库存→更新账户余额→生成订单。这一整套流程走完，才算一个事务。

我个人习惯把 TPS 当作「系统吞吐量的黄金指标」。为什么？因为它反映的是业务层面的处理能力，不是单纯的技术指标。

2. QPS（每秒查询数）

QPS 是 Queries Per Second。它衡量的是系统每秒能处理多少个请求。

注意，QPS 和 TPS 的区别：一个请求可能只是查询一下行情，不涉及写操作。而一个事务通常包含多个请求。

我在项目中遇到过一种情况：QPS 很高，但 TPS 很低。一查，原来是大量重复的行情查询请求占满了服务器资源，真正的交易反而被挤到后面去了。这就是典型的「查询拖垮交易」。

指标	含义	典型场景
TPS	每秒完成的事务数	下单、支付、转账
QPS	每秒处理的请求数	行情查询、订单查询

3. RT（响应时间）

RT 就是 Response Time，从发出请求到收到响应的时间差。单位通常是毫秒。

你想想看，用户点击「下单」按钮，等了 3 秒才看到结果——这体验能好吗？

RT 有两个关键分位数：

• P99——99% 的请求都在这个时间内完成。比如 P99 = 200ms，说明只有 1% 的请求超过 200ms。
• P999——99.9% 的请求都在这个时间内完成。更严格，通常用来衡量极端情况。

4. 错误率

错误率就是失败请求占总请求的比例。通常用百分比表示。

压力测试中，错误率是一个「一票否决」的指标。哪怕 TPS 再高、RT 再低，只要错误率超过阈值，系统就是不稳定的。

我给自己定的标准是：

• 正常负载下：错误率 < 0.01%
• 压力测试下：错误率 < 1%
• 超过 5%：立即停止压测，排查问题

四个指标的关系

这四个指标不是孤立的。它们之间有一条「跷跷板」规律：

随着压力增大，TPS 和 QPS 先上升，然后达到瓶颈，开始下降。与此同时，RT 和错误率开始飙升。

为什么会这样？

因为系统资源是有限的。当请求量超过处理能力，请求开始排队。排队时间越长，RT 就越高。队列满了，新请求直接被拒绝，错误率就上来了。

我习惯用一句话总结：TPS 是上限，RT 是体验，错误率是底线。

嗯，这一章的内容就到这里。记住这四个指标，它们是后续所有压测工作的基础。下一章我们会聊怎么搭建压测环境、选什么工具——到时候我会分享一些踩过的坑，保证有用。