TPS 与 QPS 达到多少才算高并发？概念、测算与实践

在性能测试与容量评估的讨论中，“高并发”几乎是最常被提及、也最容易被误用的词。有人问“系统能扛 1000 并发吗”，有人问“TPS 到多少才算高并发”，还有人试图用 TPS 直接推算“最大在线用户数”。这些问题看似简单，背后却混用了好几个不同的概念。本文尝试把 TPS、QPS、并发数、线程数这几个指标拆开讲清楚，再给出可落地的估算与测试思路。

一、先把定义摆清楚

TPS（Transactions Per Second）：单位时间（每秒）内系统成功处理的事务数。一个“事务”可以是一次登录、一笔下单、一次支付，具体粒度由业务定义。TPS 强调的是“完整业务动作”的吞吐能力。

QPS（Queries Per Second）：单位时间（每秒）内系统处理的查询请求数。它更偏向“请求级别”的计数，一个事务可能包含多次查询，也可能只有一次。因此在很多场景下，QPS 数值会大于等于 TPS。

并发数：同一时刻系统同时处理的请求数。这里要区分两种口径：

• 强并发（绝对并发）：同一瞬间真正同时到达的请求数，典型场景是秒杀、整点开抢、定时任务集中触发。
• 弱并发（相对并发）：一段时间窗口内（秒级、分钟级）系统需要处理的总请求量。日常业务绝大多数属于这一类。

线程数：性能测试工具中用于模拟用户行为的虚拟用户数。一个线程通常代表一个虚拟用户，按脚本逻辑向服务端发起请求。线程数只存在于负载端，服务端并不关心请求来自多少个线程。

把这四个概念放在一起，可以得出一个关键结论：线程数是我们模拟请求的手段，并发数是请求到达的形态，TPS/QPS 才是服务端真正处理能力的体现。

二、场景一：“登录接口能承受 1000 并发”到底指什么？

这句话在面试和需求评审中非常常见，但它至少有两种完全不同的解读：

• 如果指强并发：意味着同一瞬间有 1000 个登录请求同时打到服务端，这对应秒杀级别的瞬时压力。
• 如果指弱并发：意味着在某个时间窗口内，系统累计处理了 1000 个登录请求，实际每秒压力可能只有几十到几百。

在绝大多数性能测试实践中，除了秒杀、整点抢购等特殊场景，我们不会做狭义上的强并发测试。因此这句话更合理的解读是：该登录接口的 TPS 约为 1000，即每秒能稳定完成约 1000 次登录事务。

这里还有一个常被忽略的点：TPS 是结果指标，不是配置指标。 它不是我们“设定”出来的，而是通过施加一定压力后“测”出来的。所以当有人说“我们系统支持 1000 TPS”时，严谨的问法应该是：在多大的响应时间要求下、多长的持续时间内、什么样的数据分布下测得的 1000 TPS？

三、场景二：已知 TPS，能否推算最大在线用户数？

这是最典型的逻辑误区。答案很明确：不能。

原因在于，“在线用户”和“产生请求的用户”之间没有稳定的换算关系：

1. 用户在线不等于产生请求。大量用户可能只是打开页面后长时间停留在浏览状态。
2. 产生请求不等于产生我们关心的那类请求。用户可能在看推荐、翻历史记录，而不是走核心交易链路。
3. 用户行为分布高度依赖业务形态。社交类、工具类、交易类产品的活跃比例差异巨大。

如果一定要建立联系，只能通过业务模型而非数学公式：先统计真实系统中“在线用户数”与“核心接口 QPS”的历史比例关系，再结合峰值系数做容量规划。这属于容量评估的范畴，需要监控数据、压测数据和业务增长预测共同支撑，不能靠一个 TPS 数字反推。

所以，当下次有人拿一个 TPS 数字要求你估算在线用户数时，可以礼貌地说明：这两个指标之间没有可直接推导的关系，需要结合业务行为模型来分析。

四、并发数的两种口径与测试策略

理解强并发与弱并发的区别，对设计压测方案至关重要。

强并发测试的目标是验证系统在瞬时冲击下的稳定性，关注点包括：

• 瞬时连接数是否触顶
• 线程池、连接池是否被耗尽
• 限流、降级、排队机制是否按预期生效
• 恢复时间是否可接受

弱并发测试的目标是验证系统在持续压力下的吞吐能力，关注点包括：

• TPS/QPS 是否稳定
• 响应时间分布（P50、P95、P99）是否达标
• 错误率是否在可接受范围
• 资源利用率（CPU、内存、IO）是否合理

两类测试的施压方式、持续时间、观测指标都不同，不能混为一谈。

五、TPS 的估算公式与线程数的关系

一个简化的估算关系可以写成：

TPS ≈ 总请求数 / (响应时间 + 思考时间)

这里暂不考虑网络传输时间，思考时间也可以根据场景决定是否忽略。将复杂问题简单化，有助于快速估算。

而“总请求数”从哪来？在模拟大批量请求时，不可能手动点击，必须借助压测工具。这就引入了线程数：

• 一个线程代表一个虚拟用户
• 线程在设定的执行时间或执行次数内，按脚本向服务端发起请求
• 线程数只是负载端的模拟手段，与服务端性能没有直接关系

服务端只关心：在一段时间内收到了多少请求、处理了多少请求、处理得多快。至于这些请求是由 100 个线程各发 100 次，还是由 1000 个线程各发 10 次，服务端并不感知。

举个例子：

目标：向服务端发送 10000 个请求
方案 A：100 线程 × 100 次
方案 B：1000 线程 × 10 次

只要负载机性能足够，两种方案到达服务端的请求总量基本一致。差异主要体现在请求到达的时间分布上：线程越多，单位时间内并发到达的请求可能越密集，对负载机自身的资源消耗也越大。但从服务端视角看，核心指标仍然是 TPS、响应时间和错误率。

这也解释了一个常见现象：压测结果上不去，未必是服务端不行，可能是负载机先到了瓶颈。 因此在大规模压测中，常采用分布式施压，用多台负载机共同产生压力。

六、那到底多少才算“高并发”？

这个问题没有绝对答案，因为它取决于业务场景、SLA 要求和成本约束。但可以从几个维度建立判断标准：

1. 相对业务峰值
如果系统日常 TPS 是 100，大促峰值到 1000，那 1000 对这个系统就是高并发。脱离业务背景谈绝对值意义不大。

2. 相对单机能力
单机 TPS 从几百提升到几千，往往需要架构层面的优化（缓存、异步、分片）。当单机无法承载、必须引入水平扩展时，说明已经进入高并发范畴。

3. 相对稳定性要求
高并发不仅是“能处理”，还包括“稳定处理”。如果 TPS 上去后响应时间急剧恶化、错误率飙升，那说明系统并未真正具备高并发能力。

4. 相对资源成本
同样达到 5000 TPS，有的方案需要 50 台机器，有的只需 10 台。高并发能力也体现在资源效率上。

一个粗略的经验参考（仅作示意，具体以实测为准）：

量级	典型特征
百级 TPS	中小型业务，单机或简单集群可支撑
千级 TPS	需要缓存、连接池优化、读写分离
万级 TPS	需要分布式架构、消息队列削峰、分库分表
十万级及以上	需要多级缓存、异步化、单元化等系统性设计

再次强调，这些数字只是帮助建立直觉，不能作为技术选型的唯一依据。

七、实践建议：如何正确做容量评估

1. 明确业务指标：先定义什么是“事务”，再谈 TPS。
2. 建立业务模型：统计在线用户、活跃用户、核心接口调用比例。
3. 区分并发类型：日常弱并发压测 + 特殊场景强并发验证。
4. 关注响应时间分布：平均值会骗人，P95/P99 更能反映用户体验。
5. 压测环境尽量贴近生产：数据量、网络拓扑、依赖服务都会影响结果。
6. 持续观测与回归：容量不是一次测出来的，而是持续运营出来的。

八、小结

TPS、QPS、并发数、线程数，这四个概念本身并不复杂，复杂的是使用它们时的语境。记住三点：

• 线程数是手段，TPS/QPS 是结果，并发数是形态。
• 强并发与弱并发要分开讨论，绝大多数业务属于弱并发。
• TPS 与在线用户数之间没有直接换算关系，容量评估必须结合业务模型。

把这些厘清之后，再面对“多少才算高并发”这样的问题时，就能给出一个既专业又务实的回答：先看业务，再看指标，最后看成本和稳定性。