高并发下的TPS与QPS：指标解析与容量评估实践

一、先厘清概念：TPS、QPS、并发数与线程数

在性能测试和系统容量评估中，有几个术语反复出现，但经常被混用。要讨论“高并发”，首先需要把这些概念边界划清楚。

TPS（Transactions Per Second）
指系统每秒能够处理的事务数。一个事务通常代表一次完整的业务操作，例如“登录”“下单”“支付”。事务可能包含多个请求，因此 TPS 反映的是业务视角下的吞吐能力。

QPS（Queries Per Second）
指系统每秒能够处理的查询请求数。它更偏向请求视角，常用于 HTTP 接口、数据库查询、缓存读取等场景。在没有明确事务边界时，QPS 可以近似视为“每秒请求数”。

并发数（Concurrency）
指同一时刻系统正在处理的请求数量。并发数可以进一步分为两类：

• 强并发：极短时间内同时到达的请求数，例如秒杀开始的瞬间。
• 弱并发：一段时间内持续存在的请求压力，例如几分钟内的平均在线请求量。

线程数（Threads / Virtual Users）
指压测工具或客户端模拟的用户数量。线程数只代表请求发起方的规模，并不能直接等价于服务端承受的并发压力。

这些指标并不孤立。TPS 和 QPS 描述的是“处理结果”，并发数和线程数描述的是“压力形态”。理解它们的差异，是避免性能分析跑偏的前提。

---

二、同一个“1000并发”，可能有三种含义

以一个常见说法为例：“某登录接口能够承受秒级 1000 并发”。这里的“1000 并发”到底指什么，往往取决于上下文。

1. 如果理解为 TPS

在大多数常规性能测试中，所谓“并发 1000”更合理的解读是：该接口每秒能够稳定处理 1000 次登录事务。也就是说，TPS 约为 1000。这种表述通常来自压测报告中的吞吐指标，而非瞬时同时请求数。

2. 如果理解为并发数

如果场景是秒杀、抢券、整点开抢，那么“1000 并发”可能指同一瞬间有 1000 个请求同时打到服务端。此时考察的是系统在极短时间内的抗冲击能力，与持续吞吐能力并不完全等价。

3. 如果理解为线程数

压测工具中配置 1000 个线程，并不代表服务端同时收到 1000 个请求。线程之间存在启动间隔、思考时间、网络延迟等，实际到达服务端的并发量会低于线程数。

因此，脱离具体场景讨论“1000 并发”没有统一答案。更严谨的做法是明确指标：是 TPS 1000，还是瞬时并发数 1000，抑或压测线程数 1000。

---

三、TPS 与在线用户数之间没有简单换算公式

一个经常被问到的问题是：“TPS 是 1000，能支持多少在线用户？”这个问题看似合理，实际上缺少关键约束条件。

在线用户数描述的是“有多少人挂着”，TPS 描述的是“每秒完成多少业务”。一个用户在线但不操作，不会产生 TPS；多个用户轮流操作，TPS 又会受到请求间隔和业务复杂度影响。

举例来说，假设 TPS 为 1000：

• 如果每个在线用户平均每 10 秒发起一次请求，那么理论在线用户数约为 10000；
• 如果每个在线用户平均每 1 秒发起一次请求，那么理论在线用户数约为 1000；
• 如果每个在线用户平均每 60 秒发起一次请求，理论在线用户数可能达到 60000。

可以看出，影响结果的核心变量是“用户活跃频率”，而非 TPS 本身。没有这个变量，任何换算都只是猜测。

更合理的评估方式是采用“用户行为模型”：先定义目标用户群体的操作路径、请求频率、业务混合比例，再结合压测得到的 TPS，反推可支撑的用户规模。这种方式虽然复杂，但远比简单乘除法可靠。

---

四、线程数如何影响压测结果

在压测工具中，线程数通常用来模拟虚拟用户。一个线程可以循环执行某个业务脚本，向服务端持续发起请求。

需要明确的是：服务端只关心它收到多少请求、处理了多少请求，并不关心这些请求来自多少个线程。也就是说，服务端的性能表现与请求到达速率有关，与请求来源的线程划分关系不大。

举个例子，目标是在 60 秒内发出 60000 个请求：

• 方案 A：100 个线程，每个线程执行 600 次；
• 方案 B：1000 个线程，每个线程执行 60 次。

如果负载机性能足够，两种方案最终都会在 60 秒内发出约 60000 个请求，服务端承受的压力基本相同。差异主要在于请求到达的时间分布：方案 B 的瞬时冲击可能更集中，方案 A 则相对平缓。

因此，线程数只是压测工具侧的配置参数。真正影响服务端评估结果的是请求到达速率和持续时间。压测时更应关注“目标 TPS”和“压力模型”，而不是盲目堆线程数。

---

五、如何判断“高并发”的临界值

“高并发”并不是一个绝对数值。同样的 TPS，对于不同业务、不同系统架构，意义完全不同。

以下是一些参考维度：

1. 业务类型

• 内部管理系统：TPS 几十到几百已属正常；
• 普通 Web 应用：TPS 数百到数千；
• 电商大促、票务秒杀：TPS 可能达到数万甚至更高。

2. 单接口与全链路

单接口 TPS 高，不代表全链路 TPS 高。一个下单操作可能涉及库存校验、价格计算、订单写入、消息通知等多个环节，任一环节成为瓶颈，都会拉低整体事务吞吐。

3. 响应时间约束

脱离响应时间谈 TPS 没有意义。系统在 10ms 内完成 1000 TPS 和在 500ms 内完成 1000 TPS，对资源占用和用户体验的影响完全不同。通常性能目标应同时约束“TPS”与“P99 响应时间”。

4. 错误率

高并发下如果错误率上升，即使 TPS 达标也不能认为系统合格。压测报告应同时关注吞吐、响应时间和错误率三类指标。

综合来看，判断是否达到“高并发”，应结合业务场景、系统复杂度、响应时间目标和错误率要求，而非简单套用一个固定数值。

---

六、一个可操作的容量评估流程

为了避免凭感觉估算，建议采用以下步骤进行系统容量评估：

第一步：明确核心业务场景
列出系统最关键的几个事务，例如登录、查询、下单、支付。

第二步：定义性能目标
为每个事务设定 TPS 目标、响应时间目标（如 P95、P99）和可接受错误率。

第三步：构建压测模型
根据真实用户行为，定义请求比例、思考时间、数据分布等。避免只测单接口而忽略真实调用链路。

第四步：执行压测并记录数据
从低压力开始逐步提升，记录不同压力下的 TPS、响应时间和错误率变化。

第五步：识别瓶颈
当响应时间陡增或错误率上升时，结合监控数据分析 CPU、内存、数据库连接、线程池、网络等环节。

第六步：推算容量
在满足性能目标的前提下，取系统稳定运行的最大 TPS 作为基准。再结合用户活跃频率模型，反推可支撑的用户规模。

这套流程不依赖单点公式，而是用工程化手段逼近真实容量，更适合生产环境使用。

---

七、总结

TPS、QPS、并发数和线程数各有明确含义，不能混用。高并发的判断需要结合业务类型、响应时间、错误率等多维指标，不能只看一个数字。在线用户数无法仅凭 TPS 推算，必须引入用户行为模型。线程数只是压测工具配置，服务端真正关心的是请求到达速率和持续时间。

准确理解这些指标，并在性能评估中坚持场景化、工程化的方法，才能避免“数字很好看，上线就崩溃”的尴尬，为系统留下合理的容量余量。