性能指标：QPS、TPS、响应时间、吞吐量
聊到高并发，大家第一反应就是「扛得住」。但怎么量化？
很多人喜欢说「我接口单机扛了 5 万」，结果一细问，响应时间 3 秒，这 5 万有什么意义？
所以我习惯先统一度量衡。下面这四个指标，基本覆盖了所有性能场景。
QPS 与 TPS：一个容易混淆，一个经常被误解
QPS (Queries Per Second)，每秒查询数。
TPS (Transactions Per Second)，每秒事务数。
区别在哪？
说白了——QPS 只管一次请求，TPS 管一次完整的业务操作。比如支付，用户点支付按钮，前端调一次下单接口，后台可能要查余额、写订单、扣库存、记流水。这一趟完整操作，就是 1 个 TPS，内部可能包含 4-5 次 QPS。
我的一点经验
我个人习惯，谈缓存、CDN 这类查询场景时用 QPS；谈交易、下单、转账这种有状态变更的场景时，一定要盯着 TPS。
| 指标 | 定义 | 典型场景 | 优化目标 |
|---|---|---|---|
| QPS | 每秒查询次数 | 商品列表、用户信息 | 提升缓存命中、减少 DB 查询 |
| TPS | 每秒事务数 | 下单、支付、转账 | 缩短事务耗时、降低锁冲突 |
踩过的坑
我曾经以为 TPS 和 QPS 拉平就行。结果线上支付接口 QPS 到了 8000，TPS 才 1500 —— 因为每个下单事务要查询 5-6 次。压测只看 QPS 的优化，用户端反而更慢了。
响应时间：不只是平均数
响应时间 RT（Response Time），从发出请求到完整收到响应的时间。
很多同学喜欢报平均 RT。但你想想看，1000 个请求，999 个 10ms 搞定，1 个卡了 9 秒，平均 RT 也才 19ms，看着还不错吧？
实际上，那 1 个用户已经炸了。
所以我更关注下面这两个值：
- TP99：99% 的请求都在这个时间以内完成。代表绝大部分用户的体验。
- TP999：99.9% 的请求时间。高并发下，千分之一的慢请求也可能拖垮连接池。
实战经验
我在一次活动大促中遇到过，某个核心接口的平均 RT 只有 30ms，但 TP99 居然到了 1.2 秒。查下去才发现，是某个数据库连接池偶发性的 full GC 导致的。平均 RT 完全看不出来。
响应时间和 QPS 有什么关系？
一个简单的公式：单线程 QPS ≈ 1000 / RT (ms)。RT 每增加 10ms，单机瓶颈就下降一截。所以优化 RT，就是直接提升 QPS 天花板。
吞吐量：真实能处理的量
吞吐量也叫 Throughput，单位时间内系统能处理的总请求量。
很多人把 QPS 和吞吐量混淆。其实吞吐量更像是一个系统的总产出能力，它 = 并发数 × 单请求处理能力。
我举个例子：
- 系统 A：并发 100，QPS 500
- 系统 B：并发 20，QPS 500
两者 QPS 一样，但系统 B 的吞吐量上限不高——一旦并发超过 20，QPS 就开始掉。系统 A 还能扛一扛。
优化思路
提升吞吐量，不只是堆机器。要优化线程模型、减少锁竞争、合理设置 IO 超时。我曾经接手过一个接口，RT 一直在 800ms 左右飘忽，吞吐量上不去。查了半天，是 HTTP 客户端连接超时设置得太长，导致线程池被慢请求占满了。
四者关系图解
这四个指标其实互为约束。我画了一张关系图，方便大家理解：
你看，QPS 和 TPS 是「瞬时速率」，响应时间是「单个请求体验」，吞吐量是「整体能力」。优化的时候，不要只看一个值。
一个避坑清单
- 不要只看平均值。 平均 RT 漂亮不顶用，TP99 才是真实用户体验。
- 不要只看 QPS。 当 TPS 和 QPS 差距太大时，说明每次请求背后逻辑太重，该考虑异步或拆分。
- 不要忽略吞吐量上限。 有时候 QPS 很高，但一加压力就崩，就是因为吞吐量天花板太低。
记住一句话
一个接口的高并发能力 = QPS × 稳定性（低 TP999） × 资源利用率。
这三个缺一不可。拿不到这三项指标的压测，只能叫「跑分」，不能叫「上线保障」。
这四个指标，说得直白点，就是你系统性能的「体检报告」。每次压测，先让人把 QPS、TPS、平均 RT、TP99、吞吐量打出来。数据不对，后面所有优化都是盲人摸象。