吞吐量基础概念

大家好，我是你们的老朋友。今天咱们聊聊吞吐量——这个听起来简单，但实际坑特别多的概念。

我记得刚入行那会儿，老板问我：“系统吞吐量多少？”我张口就来：“每秒能处理1000个请求。”结果上线第一天，实际只有200。嗯，这就是典型的“理论值”和“实际值”的差距。今天我就把这块掰开揉碎了讲清楚。

什么是吞吐量？

吞吐量，说白了就是系统在单位时间内能处理多少活儿。

你想想看，一个收费站，一分钟能过多少辆车？那就是它的吞吐量。系统也一样——一分钟能处理多少个请求、多少笔交易、多少条数据。

我习惯把吞吐量分成两类：

• 理论吞吐量：硬件和软件架构理论上能达到的上限。比如CPU主频、网络带宽、磁盘IOPS这些硬指标。
• 实际吞吐量：在真实业务场景下，系统稳定运行时的处理能力。这个才是我们真正关心的。

QPS/TPS 定义

这两个词，面试必问，工作中也天天打交道。

指标	全称	含义	典型场景
QPS	Queries Per Second	每秒查询数	搜索引擎、API接口、读多写少的系统
TPS	Transactions Per Second	每秒事务数	支付系统、订单系统、写多读少的系统

这里有个容易混淆的点：QPS 和 TPS 到底啥区别？

我个人的理解是这样的：

• QPS 更偏向“查询”类操作。比如你刷抖音，每刷一次就是一次查询。它通常不涉及数据修改。
• TPS 更偏向“事务”类操作。比如你下单、支付、退款，这些操作会改变数据状态。一个事务可能包含多个查询和写入。

举个例子：你在淘宝买东西。

• 浏览商品详情页 → 这是 QPS（查询）
• 点击“立即购买”并完成支付 → 这是 TPS（事务）

一个 TPS 可能包含 5-10 个 QPS。所以别把这两个指标混为一谈。

吞吐量与延迟的关系

这是性能优化里最经典的一对“冤家”。

你想想看，一条高速公路，车流量越大，每辆车通过的时间是不是就越长？这就是吞吐量和延迟的关系。

我画了一张图，帮你理解这个关系：

从这张图你能看到三个关键区域：

• 线性区：系统很轻松，吞吐量增加，延迟几乎不变。这是最理想的状态。
• 拐点：系统开始吃力了。再增加一点请求，延迟就开始明显上升。这个点就是系统的“最佳工作点”。
• 饱和区：系统已经超负荷。吞吐量稍微增加，延迟就急剧飙升。这时候系统随时可能崩溃。

我个人的经验是：永远不要让系统运行在拐点之后。你想想看，一旦进入饱和区，延迟从 10ms 变成 1000ms，用户体验直接崩盘。

性能指标矩阵

光看吞吐量和延迟还不够。我习惯用一个矩阵来全面评估系统性能：

指标	定义	关注点	典型阈值
吞吐量	单位时间处理请求数	系统容量	根据业务定
平均延迟	所有请求的平均耗时	整体性能	< 200ms
P99 延迟	99% 的请求都在这个延迟内完成	长尾请求	< 500ms
错误率	失败请求占总请求的比例	系统稳定性	< 0.1%
资源利用率	CPU、内存、IO 的使用率	资源瓶颈	CPU < 80%

这里我想特别强调一下 P99 延迟。为什么？

平均延迟会骗人。举个例子：

• 100 个请求，99 个耗时 10ms，1 个耗时 1000ms
• 平均延迟 = (99×10 + 1000) / 100 = 19.9ms
• 看起来不错对吧？但 P99 延迟是 1000ms！

也就是说，有 1% 的用户体验极差。在电商大促、直播秒杀这类场景下，这 1% 的用户可能就是你的核心用户。

最后，送你一个性能指标矩阵的思维框架：

你想想看，你的系统现在在哪个象限？

大多数系统一开始都在“低吞吐 + 低延迟”象限。随着优化，会进入“高吞吐 + 低延迟”的理想区。但如果优化方向错了，就可能掉进“高吞吐 + 高延迟”的陷阱。

好了，这一章的内容就到这里。吞吐量这个概念虽然基础，但它是整个性能优化的基石。下一章我们会深入聊怎么测量和监控这些指标。