压力测试基础理论
做交易网关这么多年，我见过太多系统在上线前没做压力测试，结果一上线就崩。说实话，那场面挺尴尬的。今天咱们就来聊聊压力测试的那些基础理论。
压力测试的目的
压力测试到底为了啥？说白了就三个字：找极限。
我习惯把压力测试比作给系统做「体能测试」。你不能等到马拉松比赛那天，才发现选手跑不了全程。同样，你也不该等到行情爆发时，才发现网关扛不住。
具体来说，压力测试要回答这几个问题：
- 系统到底能承受多大的流量？
- 在极限压力下，系统会怎么死？
- 系统恢复需要多久？
- 哪些环节是瓶颈？
我在项目中遇到过一件事：有个交易网关，平时跑得好好的，一到每月交割日就卡死。后来一压测才发现，是某个日志模块在数据量大的时候会锁死。嗯，这种问题不上压力测试根本发现不了。
压力测试的类型
压力测试不是只有一种玩法。根据目的不同，我一般把它分成三类。
负载测试
负载测试是最常见的。它的目标是：验证系统在预期流量下能否正常工作。
比如你的网关设计目标是每秒处理 5000 笔订单。那你就压到 5000 TPS，看看各项指标是否达标。我建议你从 1000 开始，慢慢往上加，直到 5000。这样能观察到系统在不同负载下的表现曲线。
我的习惯：负载测试至少跑 15 分钟。太短了看不出问题，太长了浪费时间。15 分钟是个不错的平衡点。
稳定性测试
稳定性测试，也叫长时间测试。它的目标是：验证系统在持续压力下会不会出问题。
你想想看，很多系统刚启动时一切正常，跑着跑着就开始出幺蛾子。内存泄漏、连接池耗尽、磁盘写满……这些问题只有长时间运行才能暴露。
我曾经有个项目，网关在 70% 负载下跑了 6 个小时，第 5 个小时的时候，响应时间突然从 5ms 飙到了 500ms。查了半天，是某个缓存组件没有设置过期策略，导致内存持续增长，最终触发了 GC 风暴。
注意：稳定性测试的负载不要太高，60%-80% 的额定容量就够了。目的是模拟真实运行环境，不是把系统压垮。
尖峰测试
尖峰测试，也叫突发测试。它的目标是：验证系统能否应对流量突增。
交易系统最怕什么？行情异动。平时 1000 TPS 的流量，突然飙到 10000 TPS。系统能不能扛住？扛不住的话，是优雅降级还是直接崩溃？
我习惯的做法是：先让系统在 30% 负载下稳定运行，然后突然把压力提升到 150% 甚至 200%，持续 30 秒到 1 分钟，再降回正常水平。观察系统的反应和恢复速度。
关键点：尖峰测试不仅要看系统能不能扛住，还要看系统能不能恢复。有些系统被冲垮后，需要人工重启才能恢复，这在交易场景下是不可接受的。
关键术语
聊压力测试，有几个术语你必须搞清楚。我见过不少人在这些概念上栽跟头。
TPS（每秒事务数）
TPS 是衡量系统处理能力的核心指标。它表示系统每秒能处理多少个完整的事务。
在交易网关里，一个「事务」通常指一笔订单从接收到确认的完整过程。注意，不是网络包，不是消息，是完整的业务事务。
举个例子：
假设你的网关 1 秒内收到了 10000 笔订单
其中 9500 笔在 1 秒内完成了处理
那么 TPS 就是 9500我建议你关注两个 TPS 值：
- 峰值 TPS：系统能承受的最大瞬时 TPS
- 持续 TPS：系统能稳定运行的 TPS
这两个值往往不一样。峰值可能很高，但持续不了太久。
响应时间
响应时间，就是用户发请求到收到响应的时间差。在交易网关里，通常指订单从提交到确认的时间。
响应时间不是单一数值，而是一个分布。我习惯看这几个分位值：
| 分位值 | 含义 | 典型目标 |
|---|---|---|
| P50 | 50% 的请求在这个时间内完成 | < 10ms |
| P90 | 90% 的请求在这个时间内完成 | < 20ms |
| P99 | 99% 的请求在这个时间内完成 | < 50ms |
| P999 | 99.9% 的请求在这个时间内完成 | < 100ms |
为什么看分位值而不是平均值？因为平均值会骗人。100 个请求里，99 个是 1ms，1 个是 10 秒，平均值才 100ms 左右。但那个 10 秒的请求，可能已经让客户崩溃了。
我的经验：交易网关的响应时间，重点关注 P99 和 P999。P50 再好看，P999 如果飙高，说明系统存在严重的抖动问题。
并发数
并发数，就是系统同时处理的请求数量。注意，并发数和 TPS 不是一回事。
举个简单的例子：
一个餐厅有 10 张桌子（并发数 = 10）
每张桌子吃饭需要 30 分钟（响应时间 = 1800 秒）
那么餐厅的 TPS = 10 / 1800 ≈ 0.0056
如果每张桌子吃饭只需要 5 分钟（响应时间 = 300 秒）
那么 TPS = 10 / 300 ≈ 0.033看到了吗？同样的并发数，响应时间不同，TPS 完全不同。
它们的关系可以用这个公式表示：
TPS = 并发数 / 平均响应时间（秒）反过来：
并发数 = TPS × 平均响应时间（秒）这个公式很重要。你想想看，如果你的目标 TPS 是 10000，平均响应时间是 10ms，那么需要的并发数就是：
并发数 = 10000 × 0.01 = 100也就是说，你只需要 100 个并发连接就能达到 10000 TPS。但如果响应时间变成 100ms，就需要 1000 个并发连接。
避坑指南：我曾经见过一个团队，他们压测时只关注 TPS，完全不看并发数和响应时间。结果 TPS 上去了，但响应时间从 5ms 变成了 500ms。这种「虚假的 TPS」没有任何意义。记住，三个指标要一起看。
知识体系总览
下面这张图，是我对压力测试基础理论的总结。你可以把它当作本章的思维导图。
这张图把压力测试的核心要素串起来了。目的、类型、术语，三者缺一不可。你搞清楚了这些，后面的实战内容才能听得明白。
好了，这一章就到这里。记住一句话：压力测试不是为了证明系统没问题，而是为了找到问题。带着这个心态去做压测，你会少踩很多坑。
公众号:蓝海资料掘金营，微信deep3321