第一章：压力测试基础
各位同学好，我是老张。在交易系统这个行当摸爬滚打了十几年，今天咱们来聊聊压力测试。
说实话，我刚入行那会儿，对压力测试的理解特别肤浅。觉得不就是多开几个线程发请求嘛，能有多难？直到有一次线上事故，让我彻底改变了看法。嗯，那件事我后面会讲到。
什么是压力测试
压力测试，说白了就是模拟真实用户场景，给系统施加超出预期的负载，看看它到底能扛多久、什么时候会崩。
我个人的理解是：压力测试不是要证明系统有多强，而是要找到它的极限在哪里。
举个例子。你开发了一个交易网关，平时每秒处理1000笔订单。压力测试就是要看看：
- 当流量涨到2000 TPS时，系统还稳不稳？
- 涨到5000 TPS时，会不会开始丢单？
- 涨到10000 TPS时，是不是直接挂了？
你想想看，如果这些问题的答案你都不知道，你敢把这个系统上线吗？反正我是不敢。
为什么需要压力测试
这个问题我问过很多刚入行的同事。最常见的回答是：「为了通过验收」或者「领导要求的」。其实远不止这些。
核心原因有三个：
- 发现性能瓶颈 —— 我在项目中遇到过，一个看起来很简单的数据库查询，在低并发下毫秒级返回，到了高并发场景直接变成秒级。压力测试能帮你把这些隐藏的坑挖出来。
- 验证系统稳定性 —— 系统能跑起来和能稳定跑，完全是两码事。我记得有一次压测，系统前10分钟表现完美，第11分钟突然内存溢出。这种问题，不上压力测试根本发现不了。
- 评估容量规划 —— 你的系统到底需要多少台机器？每台机器能扛多少流量？这些数据不是拍脑袋拍出来的，是压出来的。
压力测试的核心指标
聊完了概念，咱们来看看具体怎么衡量。压力测试有四个核心指标，我习惯叫它们「四大金刚」。
1. TPS（每秒事务数）
TPS 全称是 Transactions Per Second。在交易系统里，一个事务通常包含：接收请求、业务处理、返回结果这三个步骤。
举个例子：
用户下单 -> 系统扣库存 -> 生成订单 -> 返回成功
↑ 这就是一个完整的事务 ↓TPS 衡量的是系统处理完整业务的能力。我个人习惯用 TPS 作为交易系统的核心指标，因为它最能反映真实业务场景。
2. QPS（每秒查询数）
QPS 是 Queries Per Second。它和 TPS 的区别在于：QPS 只关注查询操作，不关注事务完整性。
比如：
- 查询行情数据 -> 这是 QPS
- 提交一笔订单 -> 这是 TPS
在实际项目中，我一般这样区分：如果系统主要是读操作，看 QPS；如果主要是写操作，看 TPS。
3. 响应时间
响应时间就是用户发出请求到收到响应的时间差。这个指标特别有意思，因为它不是单一数值，而是一个分布。
我常用的几个分位值：
| 指标 | 含义 | 交易系统建议值 |
|---|---|---|
| 平均响应时间 | 所有请求的平均耗时 | < 100ms |
| P99 响应时间 | 99%的请求都在这个时间内完成 | < 500ms |
| P999 响应时间 | 99.9%的请求都在这个时间内完成 | < 1000ms |
为什么要关注 P99 而不是平均值？我举个例子你就明白了。假设有100个请求，99个都是1ms，但有1个是1000ms。平均值是10.99ms，看起来还不错。但那个等了1秒的用户，可能已经骂娘了。
4. 错误率
错误率就是失败请求占总请求的比例。这个指标看似简单，但坑特别多。
常见的错误类型：
- 超时错误 —— 请求发出去，但没在规定时间内收到响应
- 业务错误 —— 比如订单重复、库存不足
- 系统错误 —— 比如 500、503 等 HTTP 错误码
我个人的标准是：交易系统的错误率必须为 0%。为什么这么严格？因为交易系统涉及真金白银，一个错误可能就意味着一次交易失败，用户可能因此损失几万甚至几十万。
知识体系总览
说了这么多，咱们用一张图来总结一下压力测试的核心知识体系：
这张图把压力测试的核心知识串起来了。从定义到原因，再到具体指标，每一步都环环相扣。你想想看，如果这四个指标你都能掌控好，系统的稳定性基本就有保障了。
好了，第一章的内容就到这里。压力测试的基础概念咱们聊完了，后面几章会深入讲解具体的压测工具、场景设计、结果分析等内容。记住我今天说的：压力测试不是走过场，是真刀真枪的实战。