Java后端面试被追问QPS和瓶颈：一套能落地的项目答法
这期拆解 Java 后端面试里常见的 QPS 与性能瓶颈追问：怎么限定场景、怎么说压测边界、看哪些监控指标，以及如何把「系统能扛多少」答成可信的项目经历。
你被问到「你这个项目能扛多少 QPS，瓶颈在哪里」，先别急着报一个漂亮数字。更稳的答法是：先说业务边界，再说压测方法，再说监控指标，最后说你怎么定位和验证瓶颈。
面试官问的不是「你会不会背 QPS 定义」。他在判断三件事：你有没有真实参与过项目；你能不能把性能问题从一句口号拆成指标；你遇到压力上不去时，是靠猜，还是会拿数据一步步排查。
一句话回答模板
可以先用这一版打底：
我不会单独报一个「最高 QPS」。我会先限定场景，比如登录、查询、下单这类接口的请求链路不同。我们看吞吐量时会同时看响应时间、错误率和资源饱和情况。之前做过的做法是：先用压测工具模拟稳定流量和阶梯流量，再接入服务端监控，看 CPU、线程池、数据库连接池、缓存命中率和慢查询。最后得到的结论不是「系统能扛 X」，而是「在某个场景、某个数据量、某个错误率约束下，系统稳定在 X 左右，主要瓶颈在 Y」。
这段话的好处是，它把你从「背答案」的位置拉回「做过事」的位置。哪怕你没有完整压测经历，也可以把真实边界说清楚，而不是硬编一个 5 万 QPS。
先把 4 个词说准
性能面试里，很多人会把 QPS、并发数、响应时间、机器配置混在一起说。面试官一追问，马上露馅。
| 词 | 面试里该怎么说 | 不要怎么说 |
|---|---|---|
| QPS / 吞吐量 | 单位时间内处理的请求量。JMeter 文档把 throughput 定义为 requests/unit of time，并给出「请求数 / 总时间」的计算方式。Apache JMeter Glossary | 「QPS 越高越好」，但不说错误率和响应时间 |
| 响应时间 / 延迟 | JMeter 把 elapsed time 记为从发送请求前到最后响应收到后的时间，latency 记为从发送请求前到收到第一个响应后的时间。Apache JMeter Glossary | 只说平均 RT，不看 P95、P99 |
| 流量 / traffic | Google SRE 书把 traffic 作为四个黄金信号之一，对 Web 服务来说通常可用每秒 HTTP 请求数衡量。1 | 把「并发用户数」直接等同于 QPS |
| 饱和度 / saturation | Google SRE 书把 saturation 解释为系统有多「满」，并提醒很多系统在达到 100% 利用率之前就会变慢。1 | CPU 没到 100%，就断定系统没有瓶颈 |
真正能打动面试官的，不是你说「我懂高并发」，而是你能把「快不快、稳不稳、哪里卡」拆成可观察的指标。Prometheus 文档也把 metrics 解释为数值化测量，并说明 Web 服务可以记录 request times，数据库可以记录活跃连接数或活跃查询数。2
面试官真正想听什么
你可以按「四层」组织答案。
第一层：业务场景
先说接口类型，不要一上来就说系统整体。
同一个项目里，首页查询、搜索、下单、支付回调、报表导出不是一回事。查询接口可能主要卡缓存命中率；下单接口可能卡库存锁、事务、消息一致性；报表接口可能卡数据库扫描和导出队列。
可以这样说：
如果是商品详情查询，我会关注缓存命中率、Redis 和数据库读压力、P95 响应时间。如果是下单链路，我不会只看 QPS，还会看库存扣减、订单写入、消息发送和支付回调是否出现错误或堆积。
这句话已经比「我们系统 1 万 QPS」更可信。因为真实系统里，容量从来不是一个总数，而是一条链路在某个约束下的表现。
第二层：压测边界
压测不是随便开个工具打接口。JMeter 官方说明，它可以模拟对服务器、服务器组、网络或对象的重负载，用来测试强度或分析不同负载下的整体性能。3 但 JMeter 也明确说自己不是浏览器，不会执行页面里的 JavaScript，也不会像浏览器一样渲染 HTML。3
所以你回答时要补上边界：
- 压的是哪个接口，还是完整业务链路；
- 请求数据是不是接近真实分布，比如热门商品、普通商品、新用户、老用户；
- 流量模型是稳定流量、阶梯增压，还是模拟高峰突刺；
- 成功标准是什么，比如错误率不超过多少、P95 不超过多少、核心服务没有持续排队；
- 压测环境和生产环境有什么差异，比如机器数量、数据库规格、缓存容量、网络环境。
如果这些没说，单独报一个结果就没意义。一个在测试库、空数据、单接口、无鉴权条件下跑出来的 QPS，不能拿去证明线上真实承载能力。
第三层：监控指标
AWS Well-Architected 的性能效率文档建议用数据驱动方式构建高性能架构，并收集从高层设计到资源类型选择和配置等各方面的数据。4 面试回答也一样，要让面试官听到「我会看数据」。
最少要讲清这几类：
- 入口指标：QPS、P95/P99 响应时间、错误率、超时率。
- 应用指标：线程池活跃线程数、队列长度、GC、JVM 内存、接口耗时分布。
- 依赖指标：数据库连接池、慢 SQL、Redis 命中率、消息队列堆积、第三方接口耗时。
- 机器指标：CPU、内存、磁盘 I/O、网络 I/O。
Google SRE 书把延迟、流量、错误和饱和度称为监控的四个黄金信号。1 你不一定要在面试里照搬这个名词，但可以按这个思路组织答案：用户看到慢不慢，流量有没有上来，请求有没有失败，资源是不是已经排队。
一套可直接背的项目话术
如果你有真实项目经历，可以这样答：
我这个项目里最核心的是订单查询接口。我们先按业务入口拆了几类请求：订单列表、订单详情、物流状态。压测时没有只打一个固定订单号，而是准备了不同用户、不同订单状态的数据，避免缓存把结果抹平。指标上我主要看 QPS、P95、错误率、应用线程池、数据库连接池和慢查询。压到某个阶段后，QPS 不再增长，P95 开始上升，但 CPU 还没打满。继续看监控发现数据库连接池等待变长，慢查询集中在订单列表的状态筛选。后面做了索引调整和查询条件收敛，再复测，瓶颈从数据库等待转移到了应用线程池队列。这个结果说明我们不是单纯「加机器」解决，而是先确认瓶颈在哪里。
注意，这段里面没有具体数字。你面试时当然可以加数字，但前提是数字真实。如果你没有压测报告，宁可说「我参与了排查和监控，没有独立主导全链路压测」，也不要报一个听起来厉害但经不起追问的数。
如果你是应届生或项目经验比较轻，可以换成这一版：
我没有在生产项目里主导过完整压测，所以不会直接说项目能扛多少 QPS。但我会这样分析：先按业务链路估算峰值请求，比如用户数、活跃比例、核心接口访问频次；再用 JMeter 或类似工具做接口层压测；同时接入服务端监控，至少看 QPS、P95、错误率、CPU、内存、数据库连接数和慢查询。真正回答「瓶颈在哪里」时，要看压测过程中哪个指标先异常，而不是凭感觉说数据库或 Redis。
这版的重点是诚实。很多面试官并不要求应届生真做过线上大流量，但会看你有没有把问题想清楚。
被追问「QPS 上不去怎么排查」
可以用一条从外到内的路径回答。
1. 先确认压测本身有没有问题
先看压测机是不是先到瓶颈。比如压测机 CPU 打满、连接数不够、网络带宽不够、请求数据太单一，都会让结果失真。
也要确认压测模型是不是贴近业务。只打一个商品 ID、一个用户 token、一个查询参数，很可能压出来的是缓存命中，而不是系统真实容量。
2. 再看入口指标
如果 QPS 上不去，同时 P95、P99 开始上升，说明系统在排队或等待。如果错误率也上升，要区分是超时、限流、连接失败，还是业务异常。
JMeter 文档把 90th Percentile 解释为 90% 样本落在该值以下，剩余样本至少耗时这么长。5 所以面试里别只说平均值。平均 RT 可能还不错，但 P99 已经很差，这说明少量请求在严重阻塞。
3. 再按资源查瓶颈
这里可以借用 Brendan Gregg 的 USE Method：对每个资源检查 utilization、saturation 和 errors。它的总结是「for every resource, check utilization, saturation, and errors」。6
翻成面试语言，就是：
- CPU 忙不忙，有没有 run queue；
- 内存够不够，有没有频繁 GC 或换页；
- 磁盘 I/O 有没有排队；
- 网络有没有丢包、带宽打满或连接异常；
- 数据库连接池、线程池、消息队列这类软件资源有没有排队。
这套说法比「可能是数据库」更像工程师。它告诉面试官：你不是拿某个组件背锅，而是在按资源逐项排除。
4. 最后回到业务链路
很多性能瓶颈不在机器指标上，而在业务链路里。比如库存锁粒度太粗、接口同步调用太多、第三方服务超时重试、缓存 key 设计导致热点集中、数据库分页越翻越慢。
如果你能把「指标异常」和「代码路径」连起来，面试官会继续追项目细节；如果你只说「加缓存、加机器、分库分表」，对方基本会判断你在背八股。
四类常见追问和安全答法
追问 1：你们系统到底能扛多少 QPS？
答法：
这个要限定接口和成功标准。以订单查询为例，在测试环境、某批数据、错误率和 P95 约束下，我们测到的是某个范围。这个范围不能直接等同于生产容量，因为生产环境的数据量、机器规格、外部依赖和流量分布不同。我更愿意把它说成「在这些条件下的稳定吞吐」，而不是系统整体上限。
这句话看起来保守，但很安全。它比拍脑袋给一个整数更专业。
追问 2：为什么不直接加机器？
答法：
如果瓶颈在无状态应用层，加机器通常有效；如果瓶颈在数据库锁、连接池、慢查询、热点缓存或外部接口，加应用机器可能只会把压力更快打到下游。所以我会先看饱和资源在哪里，再决定是扩容、缓存、限流、异步化，还是改 SQL 和索引。
追问 3：平均响应时间 100ms，是不是就很好？
答法：
不一定。平均值会掩盖长尾请求。我会同时看 P95、P99 和错误率。比如大多数请求很快，但少量请求卡在数据库锁或第三方接口上，平均值可能还行，用户却会明显感到卡顿。
追问 4：你怎么证明优化有效？
答法：
优化前后要保持压测条件一致。比如同样的数据集、同样的并发模型、同样的机器规格，比较 QPS、P95、错误率和关键资源指标。只看一次跑分不够，至少要看指标变化方向和瓶颈是否转移。
这道题最容易翻车的 6 个点
- 只报数字，不说场景：比如「我们系统 3 万 QPS」，但说不清哪个接口、什么数据、什么错误率。
- 只看平均响应时间：平均值好看，不代表长尾体验好。
- 把并发数等同于 QPS：并发用户数、线程数、QPS、响应时间之间有关联，但不能简单互换。
- 一上来就说分库分表：如果瓶颈是线程池排队或慢第三方接口，分库分表解决不了。
- 把缓存当万能药：缓存能减轻读压力，但也会带来一致性、击穿、穿透、热点 key 等问题。
- 编造压测经历：面试官顺着问「压测脚本怎么写、数据怎么造、监控怎么看、瓶颈怎么确认」，很快就能分辨真假。
面试前 20 分钟自查清单
准备这道题时，把你的项目按下面几行写在纸上：
- 核心接口：你最熟的 1 个接口，不要选整个系统。
- 请求链路：入口服务、缓存、数据库、消息队列、第三方依赖。
- 关键指标：QPS、P95/P99、错误率、CPU、内存、线程池、连接池、慢 SQL。
- 已知瓶颈：哪一步最容易慢，证据是什么。
- 优化动作：你做过什么，或你会优先怎么做。
- 边界说明：哪些数字来自真实压测，哪些只是估算。
最后再准备一个 60 秒版本。面试不是写论文，先把主线说清楚：场景、指标、压测、瓶颈、验证。面试官想深挖时，你再把监控图、代码路径和优化细节往下展开。
References
- 1
- 2Overview | Prometheus
prometheus.io
- 3Apache JMeter™
jmeter.apache.org
- 4Definition - Performance Efficiency Pillar
docs.aws.amazon.com
- 5Apache JMeter Glossary
jmeter.apache.org
- 6The USE Method
brendangregg.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.