一、开篇一场关于“性能指标”的面试很多 Java 后端开发者在面试时都遇到过类似的问题面试官你们系统现在每秒能扛多少请求你说的 QPS 是多少这是峰值还是平均值RT 大概在什么范围如果流量翻一倍你的系统还能稳住吗这类问题表面上是让你报几个数字实际上考察的是你对QPS、TPS、RT、吞吐量、并发数这些高并发性能指标的理解程度。很多候选人能把概念背下来但一旦被追问“它们之间是什么关系”“怎么测出来的”“怎么根据这些指标做容量规划和性能优化”就容易卡壳。这篇文章会以面试为主线用大量场景和示例把高并发性能指标从概念、公式、区别、计算方式讲到压测工具、生产案例和优化思路。文章会优先使用 Java 生态中的场景来举例方便后端开发者直接对照理解。二、先建立一个共同语境在深入各个指标之前我们需要先明确一个朴素道理性能指标不是孤立存在的它们描述的是“系统在处理请求这件事上的表现”。一个请求从进入系统到返回结果通常要经历网络传输、应用处理、数据库访问、缓存访问、下游调用等环节。所谓高并发性能指标本质上就是在回答三个问题系统处理得快不快——对应 RT、响应时间、延迟。系统单位时间内能处理多少——对应 QPS、TPS、吞吐量。系统当前承载了多少压力——对应并发数、连接数、线程数。理解了这三类问题的分工再去记每一个指标的定义就不会把它们混为一谈。三、QPS每秒查询次数3.1 QPS 是什么QPSQueries Per Second中文一般翻译为“每秒查询数”或“每秒请求数”指一个系统在单位时间通常是一秒内能够处理的查询请求数量。它是最常被问到、也最容易在面试中出现的性能指标。举一个直观的例子一个电商系统的商品详情页用户每次打开页面都会触发“查询商品信息”的请求。如果系统在一秒钟内成功处理了 5000 次商品查询那么对于这个查询接口来说QPS 就是 5000。3.2 QPS 的公式QPS 的通用计算公式如下QPS 总请求数 / 总耗时秒例如在压测过程中我们用 100 个并发线程持续请求某个接口总耗时 60 秒一共完成了 300000 次请求那么QPS 300000 / 60 5000也就是说该接口在这个压测场景下的平均 QPS 是 5000。3.3 峰值 QPS 和平均 QPS面试时经常被追问的一个点是你说的 QPS是平均 QPS 还是峰值 QPS平均 QPS 适合用来描述一段时间内的整体水平但它在某些情况下会“掩盖”系统的真实压力。比如一个系统白天平均 QPS 是 1000但晚上 8 点大促期间峰值可能冲到 8000。如果只按平均 QPS 做容量规划系统在峰值流量下很可能被打垮。因此在生产环境中我们通常更关注下面几个口径平均 QPS一段时间内的总请求数除以总秒数。峰值 QPS按更小时间粒度统计后取最大值例如按秒统计后的最大 QPS。P99 或 P95 的 QPS 分布用于观察流量波动的分位数表现。面试回答时建议主动说明“这是压测环境下的稳态 QPS”“这是线上某个大促时段的峰值 QPS”会显得更严谨。3.4 QPS 和“查询”的关系QPS 里的 Q 是 Query但在实际工程中很多人把它泛化为“任意请求”并不严格区分读请求还是写请求。不过严格来说如果接口以查询类、读请求为主用 QPS 描述比较自然。如果接口以事务型、写请求为主更推荐用 TPS 描述。例如 Redis 的 GET 操作、商品详情查询、订单状态查询这些适合用 QPS而创建订单、扣减库存、转账这些涉及数据变更且有事务语义的场景用 TPS 更准确。3.5 QPS 的典型量级不同技术组件的 QPS 能力差异很大下面给出一组常见参考范围方便在面试中形成直觉组件或场景大致 QPS 能力参考说明单机 Nginx 静态资源数万到数十万 QPS受 CPU、内存、网卡、文件缓存影响单机 Redis数万到十几万 QPS纯内存操作单线程模型取决于命令复杂度单机 MySQL 简单查询数千到一万上下 QPS受索引、数据量、连接池、磁盘 IO 影响典型 Java Web 应用单机几百到几千 QPS取决于业务复杂度、框架、GC、下游依赖简单静态 CDN 节点可达百万级 QPS 以上边缘缓存能力强需要注意的是这些量级只是经验参考不能当作绝对结论。实际 QPS 一定和具体机器配置、业务逻辑、数据规模、网络环境强相关。四、TPS每秒事务数4.1 TPS 是什么TPSTransactions Per Second中文一般翻译为“每秒事务数”指系统在单位时间内能够完成的事务数量。事务Transaction这个概念来自数据库和业务处理领域通常表示一组需要保证一致性的操作。例如用户下单这个业务动作在系统内部可能包含校验库存创建订单记录扣减库存写入订单流水发送消息通知下游。这一系列操作如果作为一个整体成功完成才算完成一笔“事务”。因此 TPS 描述的是系统每秒能完成多少笔这样的完整业务操作。4.2 TPS 的公式TPS 的计算公式与 QPS 类似只是统计口径从“请求”变成了“事务”TPS 总事务数 / 总耗时秒例如一次压测中完成了 60000 笔下单事务压测持续 60 秒那么TPS 60000 / 60 1000表示这个下单链路平均每秒能够完成 1000 笔订单。4.3 TPS 与数据库事务的关系严格意义上的 TPS 与数据库事务密切相关。数据库层面常用 TPS 来衡量数据库每秒能够提交的事务数量。常见的压测工具或监控平台中TPS 往往指的是业务事务而不是单纯的一条 SQL。这里有一个容易混淆的点一次业务事务可能包含多条 SQL一次数据库事务也可能是同一个业务事务的一部分。4.4 TPS 与 QPS 的核心区别很多面试题会把 QPS 和 TPS 放在一起让你区分它们最核心的差别是统计口径QPS 偏向“请求次数”TPS 偏向“完整业务事务数”。可以从三个维度理解粒度不同一个业务事务往往由多个请求组成。例如下单链路里一次下单事务可能包含商品查询、优惠查询、库存校验、订单创建、库存扣减等多个内部请求。适用场景不同读多写少、以查询为主的场景习惯用 QPS写多、强事务一致性的场景习惯用 TPS。衡量目标不同QPS 更关注“接口调用频率”TPS 更关注“业务处理能力”后者离业务价值更近。一个粗略但不绝对的关系是在同一个系统或接口中如果每一次请求恰好对应一次业务事务那么 QPS 和 TPS 在数值上可能接近如果一次事务对应多次请求TPS 会明显低于 QPS。面试时能把这个关系讲清楚很容易加分。4.5 如何定义一个事务TPS 的准确性高度依赖“事务边界”的定义。同样一个下单场景不同团队可能统计出完全不同的 TPS只把“创建订单成功”算作事务把“创建订单 扣库存 发消息”整体算作事务把上游网关到最终响应的整个链路算作事务。所以在描述 TPS 时最好同步说明事务范围。真正严谨的压测方案会先定义业务操作清单和成功判定标准例如“HTTP 返回码为 200 且订单确实落库”再统计完成的事务数。五、RT响应时间5.1 RT 是什么RTResponse Time即响应时间指从客户端发出请求开始到客户端收到完整响应结果所经历的时间。它是衡量“快不快”的直接指标也是用户体验最敏感的指标。一个请求的 RT 通常包括网络传输时间应用排队等待时间业务处理时间数据库、缓存、下游服务调用时间结果序列化和返回时间。所以 RT 不是单纯的应用计算耗时而是端到端的时间开销。5.2 平均 RT 的陷阱与分位数面试中非常高频的一个问题是为什么不能只看平均响应时间因为平均值会掩盖长尾。假设某接口 100 次请求中99 次都是 10ms只有 1 次因为 Full GC 或慢 SQL 变成 2000ms平均 RT 约 30ms。单看平均值系统似乎很健康但实际上已经存在明显的长尾请求少量用户会感到卡顿甚至超时。更科学的做法是看分位数P5050% 的请求响应时间不超过该值反映典型体验P90/P95反映大多数用户的体验边界P99反映长尾请求常用于发现毛刺、GC 停顿、慢 SQL 等问题。例如线上接口 P5020ms、P9560ms但 P99800ms说明大部分请求很快但少量请求有明显延迟需要重点排查。5.3 RT 如何影响 QPSRT 和 QPS 并不是孤立的。在固定并发数的情况下RT 越短单位时间内能处理的请求通常越多RT 变长往往也意味着系统处理效率下降或资源接近瓶颈。这个关系可以用后面的并发数和 Littles Law 做量化说明见第八章。六、吞吐量6.1 吞吐量是什么吞吐量Throughput是一个更宽泛的概念指系统在单位时间内成功处理的工作量。不同的上下文里它的单位可能不同网络层面每秒传输的字节数如 Mbps、MB/s应用层面每秒处理的请求数或事务数与 QPS/TPS 口径接近数据层面每秒读写的数据条数或数据量。在 Web 应用和高并发面试中吞吐量通常可以理解为“单位时间内成功完成的请求数或事务数”这时它和 QPS/TPS 的差异主要在于使用场景和强调重点。6.2 吞吐量与 QPS/TPS 的关系可以这样理解QPS 侧重于“查询请求”这个粒度TPS 侧重于“业务事务”这个粒度吞吐量更强调“整体产出能力”既可以是请求数也可以是数据量。面试回答时建议表达为吞吐量是系统处理能力的统称QPS 和 TPS 是它在不同场景下的具体口径。讨论接口层性能时用 QPS讨论交易类业务时用 TPS讨论网络或存储时用带宽或数据量吞吐。七、并发数压力到底有多大7.1 并发用户数、并发连接数、并发线程数提到高并发很多人会把“并发用户数”和“同时在线的设备数”搞混。这里需要区分几个概念在线用户数当前登录或保持连接的用户数量但不一定都在发请求并发用户数同一时刻正在向系统发起请求的用户数量通常远小于在线用户数并发连接数客户端与服务器之间同时建立的连接数量例如 Tomcat、Nginx 的连接数并发线程数应用内部同时处理请求的线程数量例如线程池中的活跃线程数。比如一个系统在线用户有 10 万但大部分用户在看页面、不发起请求真正同时发请求的并发用户可能只有 2000 到 5000。因此做容量规划时要以“实际并发请求量”为准而不是在线人数。7.2 并发数与线程池在 Java 后端的语境下并发数直接影响线程池设置。以 Tomcat 为例线程池最大线程数决定了应用同一时刻最多能有多少个线程并行处理请求。如果并发请求数长期超过线程池容量请求就会排队RT 随之变长甚至出现拒绝或超时。通常我们不会简单地把线程池调得越大越好。线程过多会带来CPU 上下文切换开销增加内存占用上升锁竞争和资源争抢加剧反而拖垮吞吐。合理的做法是结合 CPU 核数、任务耗时结构CPU 密集还是 IO 密集和压测结果综合评估。例如 Java 中常用的经验公式会根据 CPU 密集型和 IO 密集型任务采用不同的线程数范围但最终仍要以压测数据为准。八、核心指标之间的关系Littles Law8.1 三个指标怎么串起来面试官很喜欢问QPS、RT、并发数之间有什么关系这个关系可以用 Littles Law 描述。它源于排队论在稳定系统下表达为并发数 QPS × 平均响应时间含义是系统中同时在处理的请求数等于单位时间到达的请求数乘以每个请求在系统中停留的平均时间。8.2 公式的实战用法这个公式可以做很多实用推算。例如某接口平均 QPS 是 4000平均 RT 是 100ms也就是 0.1 秒那么并发数 4000 × 0.1 400说明平均约有 400 个请求同时在处理。这为线程池、连接池预估提供了重要参考。反过来如果你已经知道系统能承载的并发数是 500平均 RT 是 200ms那么理论上可支撑的稳态 QPS 大约是QPS 并发数 / 平均响应时间 500 / 0.2 2500再结合 RT 的优化就可以推演出扩容或性能优化的收益在并发数不变的情况下把平均 RT 从 200ms 降到 100ms理论 QPS 可以从 2500 提升到 5000。需要注意的是Littles Law 的前提是系统处于稳定状态且使用的是平均指标。真实系统会有波动所以它更适合做量级预估和趋势分析不能替代实际压测。九、如何测量常用压测工具与方法9.1 常用压测工具面试时如果能把指标落到“怎么测”上会显得更有实战深度。常见工具有工具特点适用场景JMeter功能全面、图形化操作、插件丰富入门成本适中HTTP 接口、数据库、消息队列等综合压测Gatling基于 Scala/Java DSL异步高性能报表清晰HTTP 接口压测、持续集成压测wrk轻量级Lua 脚本扩展单机即可产生较大压力HTTP 服务快速加压适合快速验证LocustPython 编写分布式容易可编程能力强自定义压测场景、分布式压测生产级压测通常不会只用一台压测机因为压测机本身也可能成为瓶颈。一般会使用多台压测机组成集群再从低到高逐步加压观察各项指标的变化。9.2 压测中的注意点做压测时需要避免几个常见误区压测环境与生产环境不一致机器配置、网络、数据量不同结果无法直接推算线上能力只报 QPS 不报 RT 和错误率高 QPS 如果伴随大量超时或错误是没有意义的不清理测试数据压测产生的脏数据可能影响后续测试和业务统计把压测结果当绝对值压测只能得到特定条件下的参考值线上需结合监控持续观察。十、容量规划与性能优化思路10.1 容量规划容量规划就是回答一个问题未来流量增长后系统还能不能扛住简单流程如下梳理核心接口的当前 QPS/TPS、RT、错误率按业务增长预期估算未来一段时间的目标峰值 QPS通过压测得到单机在可接受 RT 下的最大承载能力用“目标峰值 ÷ 单机能力”反推需要的机器数量并预留一定冗余结合降级、限流、缓存等手段让系统在流量超预期时仍能保持核心链路可用。例如某核心接口压测下单机可稳定支撑 3000 QPS预计大促峰值是 30000 QPS至少需要 10 台以上服务节点再考虑冗余和上下游瓶颈。10.2 常见优化手段从指标角度出发优化方向大致分三类降低 RT优化慢 SQL、消除缓存击穿、减少远程调用、异步化非关键链路等提高 QPS/TPS水平扩容、增加缓存层、提升并行度、减少锁粒度等提高系统韧性限流、熔断、降级、隔离防止峰值流量把系统打垮。优化时不要盲目追求某个数字要回到业务目标在满足 RT 和错误率要求的前提下稳定支撑目标峰值流量即可。十一、面试高频追问与回答要点最后整理几个围绕这些指标的高频追问方便快速复习QPS 和 TPS 的区别是什么答QPS 统计请求次数TPS 统计完整业务事务数一次事务可能包含多个请求写多、事务型场景更常用 TPS。为什么平均 RT 不够答平均值掩盖长尾需要结合 P95、P99 才能看到大部分用户的体验和毛刺请求。QPS、RT、并发数是什么关系答用 Littles Law 表达为“并发数 QPS × 平均响应时间”可用于容量预估和优化收益评估。怎么确认系统能撑住预期流量答先明确峰值目标再通过全链路压测观察 QPS、RT、错误率、资源水位结合限流、降级等机制保障稳定性。十二、总结高并发性能指标不是孤立的名词而是一套用于描述系统运行状态的语言RT回答“快不快”QPS/TPS/吞吐量回答“单位时间能处理多少”并发数回答“当前承受多大压力”Littles Law把三者串起来帮助做容量预估和优化分析。面试回答时建议不要只背定义而是结合一个具体业务场景说清楚统计口径、压测条件、峰值与平均值、RT 分位数以及如何用这些指标指导容量规划和性能优化。这样你的回答就从“背概念”上升到了“有实战经验”的层次。
面试官：你了解 QPS、TPS、RT、吞吐量这些高并发性能指标吗？
一、开篇一场关于“性能指标”的面试很多 Java 后端开发者在面试时都遇到过类似的问题面试官你们系统现在每秒能扛多少请求你说的 QPS 是多少这是峰值还是平均值RT 大概在什么范围如果流量翻一倍你的系统还能稳住吗这类问题表面上是让你报几个数字实际上考察的是你对QPS、TPS、RT、吞吐量、并发数这些高并发性能指标的理解程度。很多候选人能把概念背下来但一旦被追问“它们之间是什么关系”“怎么测出来的”“怎么根据这些指标做容量规划和性能优化”就容易卡壳。这篇文章会以面试为主线用大量场景和示例把高并发性能指标从概念、公式、区别、计算方式讲到压测工具、生产案例和优化思路。文章会优先使用 Java 生态中的场景来举例方便后端开发者直接对照理解。二、先建立一个共同语境在深入各个指标之前我们需要先明确一个朴素道理性能指标不是孤立存在的它们描述的是“系统在处理请求这件事上的表现”。一个请求从进入系统到返回结果通常要经历网络传输、应用处理、数据库访问、缓存访问、下游调用等环节。所谓高并发性能指标本质上就是在回答三个问题系统处理得快不快——对应 RT、响应时间、延迟。系统单位时间内能处理多少——对应 QPS、TPS、吞吐量。系统当前承载了多少压力——对应并发数、连接数、线程数。理解了这三类问题的分工再去记每一个指标的定义就不会把它们混为一谈。三、QPS每秒查询次数3.1 QPS 是什么QPSQueries Per Second中文一般翻译为“每秒查询数”或“每秒请求数”指一个系统在单位时间通常是一秒内能够处理的查询请求数量。它是最常被问到、也最容易在面试中出现的性能指标。举一个直观的例子一个电商系统的商品详情页用户每次打开页面都会触发“查询商品信息”的请求。如果系统在一秒钟内成功处理了 5000 次商品查询那么对于这个查询接口来说QPS 就是 5000。3.2 QPS 的公式QPS 的通用计算公式如下QPS 总请求数 / 总耗时秒例如在压测过程中我们用 100 个并发线程持续请求某个接口总耗时 60 秒一共完成了 300000 次请求那么QPS 300000 / 60 5000也就是说该接口在这个压测场景下的平均 QPS 是 5000。3.3 峰值 QPS 和平均 QPS面试时经常被追问的一个点是你说的 QPS是平均 QPS 还是峰值 QPS平均 QPS 适合用来描述一段时间内的整体水平但它在某些情况下会“掩盖”系统的真实压力。比如一个系统白天平均 QPS 是 1000但晚上 8 点大促期间峰值可能冲到 8000。如果只按平均 QPS 做容量规划系统在峰值流量下很可能被打垮。因此在生产环境中我们通常更关注下面几个口径平均 QPS一段时间内的总请求数除以总秒数。峰值 QPS按更小时间粒度统计后取最大值例如按秒统计后的最大 QPS。P99 或 P95 的 QPS 分布用于观察流量波动的分位数表现。面试回答时建议主动说明“这是压测环境下的稳态 QPS”“这是线上某个大促时段的峰值 QPS”会显得更严谨。3.4 QPS 和“查询”的关系QPS 里的 Q 是 Query但在实际工程中很多人把它泛化为“任意请求”并不严格区分读请求还是写请求。不过严格来说如果接口以查询类、读请求为主用 QPS 描述比较自然。如果接口以事务型、写请求为主更推荐用 TPS 描述。例如 Redis 的 GET 操作、商品详情查询、订单状态查询这些适合用 QPS而创建订单、扣减库存、转账这些涉及数据变更且有事务语义的场景用 TPS 更准确。3.5 QPS 的典型量级不同技术组件的 QPS 能力差异很大下面给出一组常见参考范围方便在面试中形成直觉组件或场景大致 QPS 能力参考说明单机 Nginx 静态资源数万到数十万 QPS受 CPU、内存、网卡、文件缓存影响单机 Redis数万到十几万 QPS纯内存操作单线程模型取决于命令复杂度单机 MySQL 简单查询数千到一万上下 QPS受索引、数据量、连接池、磁盘 IO 影响典型 Java Web 应用单机几百到几千 QPS取决于业务复杂度、框架、GC、下游依赖简单静态 CDN 节点可达百万级 QPS 以上边缘缓存能力强需要注意的是这些量级只是经验参考不能当作绝对结论。实际 QPS 一定和具体机器配置、业务逻辑、数据规模、网络环境强相关。四、TPS每秒事务数4.1 TPS 是什么TPSTransactions Per Second中文一般翻译为“每秒事务数”指系统在单位时间内能够完成的事务数量。事务Transaction这个概念来自数据库和业务处理领域通常表示一组需要保证一致性的操作。例如用户下单这个业务动作在系统内部可能包含校验库存创建订单记录扣减库存写入订单流水发送消息通知下游。这一系列操作如果作为一个整体成功完成才算完成一笔“事务”。因此 TPS 描述的是系统每秒能完成多少笔这样的完整业务操作。4.2 TPS 的公式TPS 的计算公式与 QPS 类似只是统计口径从“请求”变成了“事务”TPS 总事务数 / 总耗时秒例如一次压测中完成了 60000 笔下单事务压测持续 60 秒那么TPS 60000 / 60 1000表示这个下单链路平均每秒能够完成 1000 笔订单。4.3 TPS 与数据库事务的关系严格意义上的 TPS 与数据库事务密切相关。数据库层面常用 TPS 来衡量数据库每秒能够提交的事务数量。常见的压测工具或监控平台中TPS 往往指的是业务事务而不是单纯的一条 SQL。这里有一个容易混淆的点一次业务事务可能包含多条 SQL一次数据库事务也可能是同一个业务事务的一部分。4.4 TPS 与 QPS 的核心区别很多面试题会把 QPS 和 TPS 放在一起让你区分它们最核心的差别是统计口径QPS 偏向“请求次数”TPS 偏向“完整业务事务数”。可以从三个维度理解粒度不同一个业务事务往往由多个请求组成。例如下单链路里一次下单事务可能包含商品查询、优惠查询、库存校验、订单创建、库存扣减等多个内部请求。适用场景不同读多写少、以查询为主的场景习惯用 QPS写多、强事务一致性的场景习惯用 TPS。衡量目标不同QPS 更关注“接口调用频率”TPS 更关注“业务处理能力”后者离业务价值更近。一个粗略但不绝对的关系是在同一个系统或接口中如果每一次请求恰好对应一次业务事务那么 QPS 和 TPS 在数值上可能接近如果一次事务对应多次请求TPS 会明显低于 QPS。面试时能把这个关系讲清楚很容易加分。4.5 如何定义一个事务TPS 的准确性高度依赖“事务边界”的定义。同样一个下单场景不同团队可能统计出完全不同的 TPS只把“创建订单成功”算作事务把“创建订单 扣库存 发消息”整体算作事务把上游网关到最终响应的整个链路算作事务。所以在描述 TPS 时最好同步说明事务范围。真正严谨的压测方案会先定义业务操作清单和成功判定标准例如“HTTP 返回码为 200 且订单确实落库”再统计完成的事务数。五、RT响应时间5.1 RT 是什么RTResponse Time即响应时间指从客户端发出请求开始到客户端收到完整响应结果所经历的时间。它是衡量“快不快”的直接指标也是用户体验最敏感的指标。一个请求的 RT 通常包括网络传输时间应用排队等待时间业务处理时间数据库、缓存、下游服务调用时间结果序列化和返回时间。所以 RT 不是单纯的应用计算耗时而是端到端的时间开销。5.2 平均 RT 的陷阱与分位数面试中非常高频的一个问题是为什么不能只看平均响应时间因为平均值会掩盖长尾。假设某接口 100 次请求中99 次都是 10ms只有 1 次因为 Full GC 或慢 SQL 变成 2000ms平均 RT 约 30ms。单看平均值系统似乎很健康但实际上已经存在明显的长尾请求少量用户会感到卡顿甚至超时。更科学的做法是看分位数P5050% 的请求响应时间不超过该值反映典型体验P90/P95反映大多数用户的体验边界P99反映长尾请求常用于发现毛刺、GC 停顿、慢 SQL 等问题。例如线上接口 P5020ms、P9560ms但 P99800ms说明大部分请求很快但少量请求有明显延迟需要重点排查。5.3 RT 如何影响 QPSRT 和 QPS 并不是孤立的。在固定并发数的情况下RT 越短单位时间内能处理的请求通常越多RT 变长往往也意味着系统处理效率下降或资源接近瓶颈。这个关系可以用后面的并发数和 Littles Law 做量化说明见第八章。六、吞吐量6.1 吞吐量是什么吞吐量Throughput是一个更宽泛的概念指系统在单位时间内成功处理的工作量。不同的上下文里它的单位可能不同网络层面每秒传输的字节数如 Mbps、MB/s应用层面每秒处理的请求数或事务数与 QPS/TPS 口径接近数据层面每秒读写的数据条数或数据量。在 Web 应用和高并发面试中吞吐量通常可以理解为“单位时间内成功完成的请求数或事务数”这时它和 QPS/TPS 的差异主要在于使用场景和强调重点。6.2 吞吐量与 QPS/TPS 的关系可以这样理解QPS 侧重于“查询请求”这个粒度TPS 侧重于“业务事务”这个粒度吞吐量更强调“整体产出能力”既可以是请求数也可以是数据量。面试回答时建议表达为吞吐量是系统处理能力的统称QPS 和 TPS 是它在不同场景下的具体口径。讨论接口层性能时用 QPS讨论交易类业务时用 TPS讨论网络或存储时用带宽或数据量吞吐。七、并发数压力到底有多大7.1 并发用户数、并发连接数、并发线程数提到高并发很多人会把“并发用户数”和“同时在线的设备数”搞混。这里需要区分几个概念在线用户数当前登录或保持连接的用户数量但不一定都在发请求并发用户数同一时刻正在向系统发起请求的用户数量通常远小于在线用户数并发连接数客户端与服务器之间同时建立的连接数量例如 Tomcat、Nginx 的连接数并发线程数应用内部同时处理请求的线程数量例如线程池中的活跃线程数。比如一个系统在线用户有 10 万但大部分用户在看页面、不发起请求真正同时发请求的并发用户可能只有 2000 到 5000。因此做容量规划时要以“实际并发请求量”为准而不是在线人数。7.2 并发数与线程池在 Java 后端的语境下并发数直接影响线程池设置。以 Tomcat 为例线程池最大线程数决定了应用同一时刻最多能有多少个线程并行处理请求。如果并发请求数长期超过线程池容量请求就会排队RT 随之变长甚至出现拒绝或超时。通常我们不会简单地把线程池调得越大越好。线程过多会带来CPU 上下文切换开销增加内存占用上升锁竞争和资源争抢加剧反而拖垮吞吐。合理的做法是结合 CPU 核数、任务耗时结构CPU 密集还是 IO 密集和压测结果综合评估。例如 Java 中常用的经验公式会根据 CPU 密集型和 IO 密集型任务采用不同的线程数范围但最终仍要以压测数据为准。八、核心指标之间的关系Littles Law8.1 三个指标怎么串起来面试官很喜欢问QPS、RT、并发数之间有什么关系这个关系可以用 Littles Law 描述。它源于排队论在稳定系统下表达为并发数 QPS × 平均响应时间含义是系统中同时在处理的请求数等于单位时间到达的请求数乘以每个请求在系统中停留的平均时间。8.2 公式的实战用法这个公式可以做很多实用推算。例如某接口平均 QPS 是 4000平均 RT 是 100ms也就是 0.1 秒那么并发数 4000 × 0.1 400说明平均约有 400 个请求同时在处理。这为线程池、连接池预估提供了重要参考。反过来如果你已经知道系统能承载的并发数是 500平均 RT 是 200ms那么理论上可支撑的稳态 QPS 大约是QPS 并发数 / 平均响应时间 500 / 0.2 2500再结合 RT 的优化就可以推演出扩容或性能优化的收益在并发数不变的情况下把平均 RT 从 200ms 降到 100ms理论 QPS 可以从 2500 提升到 5000。需要注意的是Littles Law 的前提是系统处于稳定状态且使用的是平均指标。真实系统会有波动所以它更适合做量级预估和趋势分析不能替代实际压测。九、如何测量常用压测工具与方法9.1 常用压测工具面试时如果能把指标落到“怎么测”上会显得更有实战深度。常见工具有工具特点适用场景JMeter功能全面、图形化操作、插件丰富入门成本适中HTTP 接口、数据库、消息队列等综合压测Gatling基于 Scala/Java DSL异步高性能报表清晰HTTP 接口压测、持续集成压测wrk轻量级Lua 脚本扩展单机即可产生较大压力HTTP 服务快速加压适合快速验证LocustPython 编写分布式容易可编程能力强自定义压测场景、分布式压测生产级压测通常不会只用一台压测机因为压测机本身也可能成为瓶颈。一般会使用多台压测机组成集群再从低到高逐步加压观察各项指标的变化。9.2 压测中的注意点做压测时需要避免几个常见误区压测环境与生产环境不一致机器配置、网络、数据量不同结果无法直接推算线上能力只报 QPS 不报 RT 和错误率高 QPS 如果伴随大量超时或错误是没有意义的不清理测试数据压测产生的脏数据可能影响后续测试和业务统计把压测结果当绝对值压测只能得到特定条件下的参考值线上需结合监控持续观察。十、容量规划与性能优化思路10.1 容量规划容量规划就是回答一个问题未来流量增长后系统还能不能扛住简单流程如下梳理核心接口的当前 QPS/TPS、RT、错误率按业务增长预期估算未来一段时间的目标峰值 QPS通过压测得到单机在可接受 RT 下的最大承载能力用“目标峰值 ÷ 单机能力”反推需要的机器数量并预留一定冗余结合降级、限流、缓存等手段让系统在流量超预期时仍能保持核心链路可用。例如某核心接口压测下单机可稳定支撑 3000 QPS预计大促峰值是 30000 QPS至少需要 10 台以上服务节点再考虑冗余和上下游瓶颈。10.2 常见优化手段从指标角度出发优化方向大致分三类降低 RT优化慢 SQL、消除缓存击穿、减少远程调用、异步化非关键链路等提高 QPS/TPS水平扩容、增加缓存层、提升并行度、减少锁粒度等提高系统韧性限流、熔断、降级、隔离防止峰值流量把系统打垮。优化时不要盲目追求某个数字要回到业务目标在满足 RT 和错误率要求的前提下稳定支撑目标峰值流量即可。十一、面试高频追问与回答要点最后整理几个围绕这些指标的高频追问方便快速复习QPS 和 TPS 的区别是什么答QPS 统计请求次数TPS 统计完整业务事务数一次事务可能包含多个请求写多、事务型场景更常用 TPS。为什么平均 RT 不够答平均值掩盖长尾需要结合 P95、P99 才能看到大部分用户的体验和毛刺请求。QPS、RT、并发数是什么关系答用 Littles Law 表达为“并发数 QPS × 平均响应时间”可用于容量预估和优化收益评估。怎么确认系统能撑住预期流量答先明确峰值目标再通过全链路压测观察 QPS、RT、错误率、资源水位结合限流、降级等机制保障稳定性。十二、总结高并发性能指标不是孤立的名词而是一套用于描述系统运行状态的语言RT回答“快不快”QPS/TPS/吞吐量回答“单位时间能处理多少”并发数回答“当前承受多大压力”Littles Law把三者串起来帮助做容量预估和优化分析。面试回答时建议不要只背定义而是结合一个具体业务场景说清楚统计口径、压测条件、峰值与平均值、RT 分位数以及如何用这些指标指导容量规划和性能优化。这样你的回答就从“背概念”上升到了“有实战经验”的层次。
