3. 吞吐量(Throughput)概念：QPS/TPS定义、吞吐量与延迟的关系、Little定律
吞吐量这个词，做性能测试的人天天挂在嘴边。但说实话，我见过不少团队把QPS和TPS搞混，甚至直接用并发数来评估系统能力。这其实挺危险的。
今天咱们就把吞吐量这个概念彻底掰扯清楚。我会结合自己踩过的坑，帮你建立一套扎实的理解。
3.1 QPS与TPS：别再傻傻分不清
QPS（Queries Per Second），每秒查询数。它通常用来衡量读接口的吞吐能力。比如你搜索商品、查看订单详情，这些都属于查询操作。
TPS（Transactions Per Second），每秒事务数。它更强调一个完整的事务链路。比如下单操作，可能包含扣库存、生成订单、支付等多个步骤，这算一个完整事务。
我个人的习惯是：
- 纯查询接口，用QPS衡量
- 写操作或复杂业务链路，用TPS衡量
举个例子你就明白了。一个电商系统的首页推荐接口，每秒能处理5000次请求，这就是5000 QPS。而一个下单接口，每秒能完成200笔完整交易，这就是200 TPS。
核心区别：QPS关注单次请求，TPS关注完整事务。一个TPS可能包含多个QPS。
我在项目中遇到过这样的情况：某团队宣称系统TPS能达到10000，结果一压测发现，他们统计的是接口调用次数，而不是完整事务数。说白了，就是把QPS当TPS报了。这会导致容量评估严重失真。
3.2 吞吐量与延迟：一对欢喜冤家
吞吐量和延迟的关系，就像跷跷板的两头。你压得越狠，延迟往往就越高。
为什么会这样？
系统资源是有限的。当请求量增加，CPU、内存、IO等资源开始争抢。每个请求等待的时间变长，延迟自然就上去了。
我画了一张图，帮你直观理解这个关系：
你看这张图，左边有一段平缓的区域，叫线性区。在这个区域里，吞吐量增加，延迟基本不变。这是系统最理想的工作状态。
但到了某个点——我习惯叫它拐点——情况就变了。再增加一点请求，延迟就会急剧上升。这就是系统进入饱和区的标志。
我的经验：做性能测试时，一定要找到这个拐点。它告诉你系统真正的极限在哪里。我曾经帮一个客户优化数据库，他们一直以为系统能扛5000 QPS，结果拐点在3200就出现了。超过这个值，延迟从50ms直接飙到800ms。
3.3 Little定律：吞吐量、并发数、延迟的数学关系
Little定律是排队论里的一个经典结论。它很简单，但非常实用：
并发数 = 吞吐量 × 平均延迟
用公式表示就是：N = X × R
其中：
- N：系统中平均的并发请求数
- X：吞吐量（每秒完成的请求数）
- R：平均响应时间（延迟）
你想想看，这个公式意味着什么？
只要知道任意两个指标，就能算出第三个。这在性能测试中太有用了。
举个例子：
假设你的系统平均延迟是100ms（0.1秒），你希望吞吐量达到1000 QPS。那么系统需要支撑的并发数是多少？
N = 1000 × 0.1 = 100
也就是说，你需要同时维持100个并发请求在系统中处理。
实战应用：我经常用Little定律来做容量规划。比如客户说「我们预计峰值并发用户是5000」，那我就会问「你期望的响应时间是多少？」。如果他说「2秒以内」，那就能算出目标吞吐量：X = 5000 / 2 = 2500 QPS。这样目标就清晰了。
3.4 避坑指南：吞吐量测试的常见误区
做吞吐量测试时，有几个坑我踩过，也看别人踩过。今天一并告诉你：
- 混淆QPS和TPS：前面说过了，这是最常见的错误。一定要根据业务场景选择合适的指标。
- 忽略思考时间：有些测试工具默认不模拟用户思考时间，导致压测结果虚高。我建议加上合理的思考时间，更贴近真实场景。
- 只看平均延迟：平均延迟会掩盖长尾问题。我习惯同时关注P99、P999延迟。曾经有个系统平均延迟50ms，但P999延迟高达5秒，用户体验极差。
- 在非稳定状态下测吞吐量：系统刚启动时，缓存是空的，这时候测出来的吞吐量偏低。我一般会让系统预热5-10分钟再开始记录数据。
特别注意：Little定律成立的前提是系统处于稳定状态。如果系统正在抖动（比如频繁GC、网络波动），公式就不准了。所以测试前一定要确认系统状态稳定。
3.5 一张图总结本章核心
我把吞吐量的核心概念整理成了一张知识结构图，方便你回顾：
嗯，吞吐量这部分内容就这些了。记住，理解概念只是第一步，真正有价值的是你在实际项目中怎么用这些知识去发现问题、解决问题。
想要更多资料，联系可可