TPS和QPS达到多少才算高并发？本文一次讲透

一、从两个常见场景说起

场景一： 需求评审会上，产品经理提出“登录接口要能承受秒级1000并发”。这里的“并发”，指的是TPS？并发数？还是线程数？不同角色往往会给出完全不同的答案。

场景二： 有面试官问：“已知系统TPS是1000，如何估算系统支持的最大在线用户数？”

这两个问题极具代表性，它们暴露出行业里对性能指标理解的普遍模糊。要回答“TPS和QPS达到多少才算高并发”这个标题问题，必须先把基础概念钉死，再讨论量级问题。

二、四个核心概念的严格定义

1. TPS：每秒事务数

TPS（Transactions Per Second）指系统每秒成功处理的事务数量。这里的“事务”是业务语义层面的单位，其边界由测试人员在脚本中定义：它可以是一次简单的接口调用，也可以是“登录→浏览→下单”这样包含多次交互的完整业务流程。TPS衡量的是系统的业务吞吐能力，是性能测试中最核心的产出指标。

2. QPS：每秒请求数

QPS（Queries Per Second）通常指系统每秒处理的请求（或查询）数量，是接口层面的速率指标。两者关系取决于事务边界：

• 若一个事务只包含一次请求，则 TPS = QPS；
• 若一个事务由多次请求组成（例如一次下单事务包含查库存、扣减、创建订单等调用），则 QPS > TPS。

日常沟通中两者常被混用，但在严格的性能报告中应当区分：QPS看接口压力，TPS看业务能力。

3. 并发数：某一时刻正在处理的请求数

并发数指同一时刻系统中“已到达但尚未返回响应”的请求数量，这是相对并发的定义。与之对应的绝对并发，指同一时间点（如同一毫秒）同时发出的请求量，只有在秒杀、整点开抢等极端场景下才有意义。平时口头说的“并发”，多数情况其实指的是一段时间内的吞吐量（TPS），而非瞬时并发数——这正是概念混乱的源头。

4. 线程数：压测工具中的虚拟用户数

线程数一般指压测脚本中的虚拟用户数。一个线程模拟一个用户，循环执行“发起请求→等待响应→思考→再发起”的动作。必须强调：线程数是施压侧（负载机）的概念。服务端根本不关心请求从哪里来、由多少线程发出，它只关心“一段时间内到达并处理了多少请求”。

举例：要打出10000个请求，用100个线程各循环100次，或用1000个线程各循环10次，对服务端产生的压力基本等价（仅请求到达的时间分布略有差异，通常可忽略）。施压方式只是负载机的实现细节，不应与被测系统的容量指标混为一谈。

三、场景一解读：“秒级1000并发”到底指什么？

在绝大多数业务中，除秒杀、整点开抢等特殊活动外，并不存在严格意义的绝对并发，因此性能测试一般也不做狭义并发验证。据此，“登录接口承受秒级1000并发”的合理解读是：登录接口的TPS达到1000，即系统每秒能成功处理1000次登录请求。

之所以出现“并发”的表述，是因为该词在日常语境中被严重泛化：产品说“并发”可能指在线人数，开发说“并发”可能指线程数，测试说“并发”才更可能指TPS或瞬时并发请求数。术语不统一，是需求扯皮与测试返工的重要根源。

更专业的做法，是在需求评审时把模糊表述翻译成可测量、可验收的指标组合，例如：

在1000 TPS的压力下，登录接口P99响应时间不超过500ms，错误率低于0.1%，服务器CPU利用率不超过70%。

四、场景二解读：为什么TPS推不出在线用户数

“TPS是1000，最大在线用户数是多少？”——这个问题本身在逻辑上不成立，因为两者之间不存在确定的函数关系：

1. 在线不等于发起请求。 用户在线可能只是在浏览、输入甚至挂机，并不对服务端产生压力。百万级在线用户若操作频率很低，实际TPS可能只有几百。
2. 请求不等于目标场景。 在线用户产生的请求分散在大量不同接口上，未必命中你所关注的链路。
3. 用户行为差异巨大。 重度用户和轻度用户的操作频率可能相差百倍，用“平均在线用户”推算没有意义。

正确的方向是反向估算：从业务数据出发推算系统需要承载的目标TPS。常用的是二八原则——80%的请求集中在20%的时间内。例如日请求量1.2亿次的应用：

峰值TPS ≈ 日请求量 × 80% ÷ (86400秒 × 20%)
        = 1.2亿 × 0.8 ÷ 17280
        ≈ 5556 TPS

再乘以1.5~2倍的安全冗余，即可得到约8000~11000 TPS的压测目标。这类估算的前提是掌握真实的业务数据（日活、操作频次、接口分布），而不是拿一个TPS数字反推本就不存在的“在线用户数上限”。

五、三者的数学关系：从排队论到压测脚本

性能领域有一条经典公式（Little定律）：

系统内平均并发请求数 = 到达速率(TPS) × 平均响应时间(秒)
即：L = λ × W

举例：TPS为1000、平均响应时间为0.2秒，则系统内瞬时并发请求约为 1000 × 0.2 = 200个。可见1000 TPS的系统，实际并发数可能只有200——“1000并发”与“1000 TPS”完全是两回事。

由该公式还可推导线程数配置。单线程串行发请求、不加思考时间时：

单线程TPS ≈ 1 ÷ 平均响应时间
所需线程数 ≈ 目标TPS × (响应时间 + 思考时间)

若目标TPS为1000、响应时间0.2秒，理论线程数约为200个；若脚本加入思考时间，线程数需相应增加。这也解释了为什么压测报告中的“线程数”不能直接当作“并发数”汇报——两者之间相差的是响应时间的秒数倍，可能是数倍的关系。

六、TPS和QPS达到多少才算高并发？

这是标题的问题，但答案不是一个数字，因为“高”高度依赖参照系。

1. 按业务量级粗略分级（经验参考，非行业标准）

• 100 TPS以下： 小型系统。内部管理后台、工具类应用多处于这一档，单体架构即可承载。
• 100~1000 TPS： 中型系统。中型电商或内容平台的非核心链路常见量级，需要合理的缓存与连接池调优。
• 1000~10000 TPS： 较高并发。核心交易链路通常位于此区间，需要缓存、异步化、读写分离等手段支撑。
• 10000 TPS以上： 严格意义上的高并发。大型互联网平台核心场景所在，需要分库分表、消息削峰、多级缓存、限流降级等完整的分布式技术栈，并依赖负载均衡与集群化部署。

2. “高”是相对的：资源投入与业务复杂度决定参照系

同样的数字，对单机与集群的意义完全不同。一台常规配置的服务器处理简单的内存查询，几百上千QPS并不困难；但若单个事务涉及多表事务、复杂计算或多次外部调用，单机TPS可能只有几十。脱离业务复杂度谈“高并发”，就像脱离载重谈车速。

3. 脱离响应时间与错误率谈TPS没有意义

“系统支持10000 TPS”必须附带约束条件：P99响应时间是多少？错误率是多少？资源水位如何？如果为了拉高TPS而放宽超时、牺牲响应时间，压测报告会很好看，但线上体验早已崩塌。专业的性能结论必须是一组指标：TPS + 响应时间分位值 + 错误率 + 资源利用率，缺一不可。

七、高并发是系统工程，不是单点数字

当目标TPS确定后，如何“达到”就是架构问题。业界通用的手段包括：

• 多级缓存： 将读请求挡在数据库之外，缓存命中率的提升往往比加机器更有效；
• 异步化与消息队列： 削峰填谷，把瞬时洪峰转化为可平滑消费的任务流；
• 数据库优化： 读写分离、分库分表、索引与慢查询治理；
• 无状态与水平扩容： 让应用层可以随流量弹性伸缩；
• 流量防护： 限流、熔断、降级，保证洪峰之下系统不被整体压垮；
• 压测常态化： 通过定期的全链路压测持续验证容量水位。

在使用云基础设施时，负载均衡、弹性伸缩、容器编排等通用能力可以显著降低扩容的操作成本，例如借助百度智能云等云平台提供的弹性伸缩能力，可在流量洪峰时自动增加实例。但要明确一点：工具解决的是“扩容快不快”，容量规划解决的是“要扩到多大”——后者的前提，仍然是先算清楚目标TPS。

八、结语：性能测试的五点实践建议

1. 统一术语： 需求、开发、测试三方对齐“并发”的确切含义，把口语需求翻译成可测量的指标组合。
2. 目标先行： 从日活、请求量等业务数据出发估算目标TPS，而不是拍脑袋定数字，更不要用TPS反推无意义的在线用户数。
3. 带约束报数据： 性能结论必须同时包含TPS、响应时间分位值、错误率与资源水位。
4. 区分施压与被压： 线程数只是负载机的施压手段，不要拿线程数冒充并发数。
5. 尊重工程方法： 性能测试是严谨的工程学科，需要系统学习与实践积累，而不是用一个TPS数字强人所难。

回到标题的问题：TPS和QPS达到多少才算高并发？答案是——先定义清楚你的业务量级、资源约束与响应时间要求，再来回答这个问题，才具有真正的工程意义。