QPS 和 TPS 吞吐量指标解读

什么是吞吐量 —— 初识 QPS 与 TPS

吞吐量是衡量系统处理能力的关键指标，它直接反映了系统在单位时间内能够“处理多少事”。在性能测试、系统监控和容量规划中，你总会看到两个高频缩写：QPS 和 TPS。它们虽然都代表“每秒处理的数量”，但衡量粒度完全不同。理解它们的区别、计算方式及实际意义，是入门性能工程的必修课。

QPS：每秒查询数

QPS (Queries Per Second) 指一台服务器或系统在一秒内能够响应的查询请求数量。这里的“查询”通常对应一次客户端到服务端的完整请求-响应过程，常见于 Web 服务、数据库和搜索引擎场景。

• 典型应用场景：HTTP 接口调用（比如用户刷新页面、点击搜索）、数据库 SQL 查询（SELECT）、Redis 缓存查询。

• 简单计算公式：

  QPS = 总请求数 / 统计时间窗口（秒）
  

  例如，在 10 秒内处理了 2300 次查询，则 QPS = 230。更常见的说法是“该接口每秒可以扛住 230 个查询”。

• 注意：一次查询（Query）只对应一次请求，不关心该请求内部是否操作了多条数据或触发了复杂业务逻辑。它看重的是请求的频次。

TPS：每秒事务数

TPS (Transactions Per Second) 指系统在一秒内能够处理的事务数量。事务是一组逻辑上不可分割的操作，通常包含多个步骤，且往往涉及数据状态的改变。

• 典型应用场景：银行转账（扣款+入账）、电商下单（扣库存+生成订单+记录流水）、支付回调处理。
• 一个事务的界定：一系列操作要么全部成功，要么全部失败回滚。一次事务可以包含多次数据查询和多次数据变更。
• 计算公式：

  TPS = 成功完成的事务数 / 统计时间窗口（秒）
  

  例如，每秒成功完成了 50 笔用户下单操作（每笔下单元包含校验库存、创建订单、扣减库存三个子步骤），此时 TPS 即为 50。

QPS 与 TPS 的核心区别

很多初学者容易混淆二者，因为它们都在说“每秒多少”。关键在于关注的是“动作的粒度”。

启发式理解：如果你只做页面浏览，关心的是服务器每秒能吐出多少个页面，这是 QPS；如果你要做用户注册，关心的是每秒能成功注册多少个用户（包含信息校验、写入数据库、发送通知等），这便是 TPS。

如何计算与解读吞吐量指标

从日志或监控中获取原始数据

实际工程中，吞吐量往往通过埋点或日志聚合得到。你需要收集以下两类数据：

1. 请求/事务总数：在某一时间段内完成的总次数。
2. 错误/失败数：通常 TPS 只统计成功耗时的事务，失败的、超时的应当排除或在计算可用性时单独考量。
3. 时间段：收集间隔越短，实时性越强（如 1s 粒度），但毛刺可能明显；适当放宽到 1 分钟平均值能平滑噪声。

QPS 的实际计算方法

假设你有一段 Nginx 访问日志，记录了近 5 分钟的请求。你可以用命令统计：

cat access.log | wc -l

若总行数为 150000，则平均 QPS = 150000 / (5 * 60) = 500。但这只是平均值，真实场景中需要关注峰值 QPS。

峰值 QPS 往往通过时间序列分片计算，比如按秒统计，取最高值。很多监控工具（如 Prometheus、Grafana）会直接输出 rate(request_count[1m])，即过去 1 分钟内每秒请求速率。

TPS 的实际计算方法

TPS 通常和业务逻辑绑定，很难仅靠网络日志推导。你需要从应用层的数据源入手：

• 在代码中对事务成功节点计数，比如下单成功时调 metrics.counter.increment("order.success")。
• 使用数据库事务日志：MySQL 的 Com_commit 计数器每秒增量近似表示提交的事务数，但需注意这包含了数据库自身内部事务。
• 压力测试工具（如 JMeter、wrk）中的 TPS 统计：JMeter 中的“事务控制器”会把一组采样器归拢为一个事务，最终报告会给出 TPS。

计算公式依旧简单：

TPS = 事务成功总数 / 持续时间（秒）

例如压测 5 分钟，共成功下单 12000 次，则 TPS ≈ 12000 / 300 = 40。

从吞吐量看系统瓶颈

吞吐量与并发用户数、响应时间的关系

这三个指标经常被放在一起讨论，它们遵循著名的利特尔法则 (Little’s Law)：

并发数 (N) = 吞吐量 (X) × 平均响应时间 (R)

• 吞吐量 X：即 QPS 或 TPS，代表系统每秒处理完成的请求/事务数。
• 平均响应时间 R：每个请求从事发到完成的时间，单位秒。
• 并发数 N：系统中同时存在的请求/事务数量（处于“处理中”状态）。

这个公式的本质含义是：在稳定状态下，系统中的排队 + 处理中的请求数量，等于它们完成速率和平均逗留时间的乘积。

应用示例： 如果你的支付接口平均响应时间是 200ms（0.2s），TPS 为 100，则系统处理支付事务的平均并发数 = 100 × 0.2 = 20。这意味着同一时刻大约有 20 笔支付在并行处理。

为什么吞吐量提升会遇到天花板

随着压力增大，QPS/TPS 通常不会线性增长，而会表现出阶段式特征：

1. 线性增长区：资源充足，吞吐量与并发用户数近似正比。
2. 增长放缓区：资源出现争用（CPU、锁、连接池），响应时间开始明显上升，吞吐量增速变缓。
3. 饱和/下降区：系统过载，大量请求堆积超时，吞吐量不仅不增，反而可能下降（如上下文切换风暴、死锁、连接池耗尽）。

核心瓶颈通常在于：

• 数据库：连接数限制、锁竞争、磁盘 I/O。
• 线程模型：同步阻塞 vs 异步非阻塞，线程池大小配置。
• 网络带宽：大包传输达到带宽上限。
• 下游依赖：调用第三方的 QPS 限制。

如何提升系统吞吐量

无论 QPS 还是 TPS，以下优化手段具有普适性。

读密集型场景（提升 QPS）

1. 增加缓存：将热点数据放入 Redis 或本地缓存，减少数据库查询。
2. 读写分离：数据库主从架构，读流量分散到多个从库。
3. CDN 与静态化：对于不常变动的 Web 内容，前置到 CDN 边缘节点。
4. 提升并发效率：使用异步非阻塞框架（如 Nginx、Netty、Node.js）处理大量连接。
5. 索引优化：确保慢查询都能被覆盖索引或快速索引查找。

写密集型场景（提升 TPS）

1. 批量写入：积攒一批数据一次性提交，降低事务开销和磁盘 I/O 次数。
2. 异步化：非核心实时操作（如发放积分、发通知）异步处理，缩短主事务路径。
3. 分库分表：将写入压力分散到多个数据库实例，突破单库的 TPS 限制。
4. 减少锁范围：乐观锁代替悲观锁，降低事务隔离级别（如从 Serializable 降到 RC），避免死锁。
5. 消息队列削峰：突发流量先进 MQ，后端按照可控 TPS 消费，保护数据库。

通用策略

• 服务无状态化：便于水平扩展，增加服务器节点即可线性增加吞吐量。
• 连接池调优：数据库连接池、HTTP 连接池设得太小会成为瓶颈，太大可能消耗过多资源。
• 监控与压测：只有用真实流量比例的压测，才能发现最大吞吐量拐点。持续监控 QPS/TPS 趋势，提前预警。

常见误区与注意事项

1. 混淆平均与峰值：说一个系统 QPS 3000，如果没说明是平均值还是峰值，这个数字几乎没用。峰值往往更重要（比如秒杀场景）。
2. 遗忘读写比例：一个电商页接口可能包含 30 次缓存读取和 1 次数据库查询，仅看总 QPS 容易忽视后端真实压力，需细分到组件。
3. 用 TPS 衡量纯读系统：如果你的系统只有数据展示没有事务，TPS 概念并不适用，用 QPS 就够了。
4. 忽略硬件环境：4 核 8G 的 ECS 和 16 核 32G 物理机得到的吞吐量完全不同，任何性能指标必须与硬件规格挂钩。
5. 只看吞吐不看错误率：一个系统 TPS 很高，但成功率为 50%，那么有效吞吐量其实已经大打折扣。健康度需要结合成功率（或可用性）共同判断。
6. 过度追求极限吞吐量：系统在最高吞吐量附近运行时，响应时间往往呈指数上升，用户体验极差。通常建议将容量水位维持在峰值能力的 60~70%。

实战小结

对于运维、开发和测试人员：

• 搭建监控面板时，务必同时展示 QPS 和 TPS，并根据业务拆分为读接口 QPS、写事务 TPS。
• 在进行容量评估时，使用 峰值 QPS × 余量倍数（如 2~3 倍） 来规划集群规模。
• 线上排查突然卡顿时，对比 QPS/TPS 与响应时间的变化曲线，若吞吐量不升反降，通常指向过载和资源瓶颈。
• 把利特尔法则当作口袋工具，随时估算并发数或发现异常。

掌握了 QPS 与 TPS 的核心含义、计算方式和应用场景，你就迈出了成为性能分析高手的坚实一步。后续可以继续学习“系统容量模型”、“全链路压测”、“限流与降级”等专题。