与哪些因素有关

1. 后端服务器集群节点数量，数量越多，QPS越高
2. 后端服务器节点的运行配置：运行内存、Cpu核数等等，硬件资源决定单节点处理能力
3. 接口本身做的事情

a. 做的事情多耗时长（预估QPS会相对应低）

b. 做的事情少耗时短（预估QPS会相对应高）

4.系统架构

a. 完善的流量负载均衡架构，实现流量的有效分发和负载均衡，避免成为QPS瓶颈

b. 缓存技术，减轻数据库的压力，避免数据库成为QPS瓶颈

c. 集群模式的数据库，避免数据库成为QPS瓶颈

d. 静态资源通过CDN加速，避免成为QPS瓶颈

如何预估？

首先需要知道一个请求处理完毕的时间（这个请求里可能做很多事情，但是这个我们暂时不管），一个请求处理完毕的时间我们是可以知道的。（我们去调用这个接口多次得到平均值即可）

理论计算公式

1. QPS（单节点） = 线程数（如 Tomcat 线程池）/ 平均请求处理时间（秒）

a. 例如：若线程池大小为 200，单个请求处理时间为 50ms（0.05秒）

ⅰ. SprigBoot 默认使用Tomcat，而Tomcat线程池的最大线程数就是200，所以在默认配置下，SprigBoot 应用可以并发处理 200 请求

则 QPS（单节点） = 200 / 0.05= 4000

2.QPS（集群）= QPS（单节点）* 节点数

例如集群有4个节点，则 QPS（集群）= 4000 * 4 = 16000

单个请求处理的时间是受到

“系统架构”、“接口本身做的事情”“后端服务器节点运行配置”“后端服务器节点数量”

等等因素共同影响的 但这实际上是一个近似已知值（我们去调用这个接口多次得到平均值即可）

QPS瓶颈

我们想想QPS的瓶颈在哪？其实很多方面，就像前面说的QPS与哪些因素有关

但一般来说 QPS 最可能的瓶颈在于数据库 (例如MySQL)

应该说多少QPS

面试官如果问接口的QPS多少，如何回答比较合理？

首先我们一定可以知道这个接口处理的平均耗时是多久？假设是200ms

一些项目背景暂时假设为如下情况，因个人而定

• 假设有 n 台后端服务器
• 假设后端服务器的配置是 2核4G内存
• 假设接口做了一些事情
• 假设对于一些系统架构上，做了一些优化、或者没有做优化

那么

1. QPS（单节点） = 线程数（如 Tomcat 线程池）/ 平均请求处理时间（秒）

a. 若线程池大小为 200，单个请求处理时间为 100ms（0.01秒）

b. 则 QPS（单节点） = 200 / 0.01= 2000

2.QPS（集群）= QPS（单节点）* 节点数 = 2000 * n

没有压测的情况下，我们就可以说这个理论计算得出的值。但是理论仅仅是理论

如果有压测，那其实是另外更好的一种情况，因为压测得到的数据往往是更加准确的。

例如压测过程：使用 JMeter 进行了压力测试，逐步增加并发线程数，直到接口的响应时间超过预设阈值（如 200ms）或错误率超过 1%。此时就可以知道接口可以抗住的QPS

示例：

面试官：“你在项目中负责的订单查询接口，QPS 是多少？”你的回答：“订单查询接口的 QPS 在‘双11’大促期间峰值达到 5,000，日常平均 QPS 约为 1,200。我们通过以下步骤得出这一数据：

1. 压测阶段：JMeter 进行了压力测试，逐步增加并发线程数，发现当 QPS 达到 2,000 时，响应时间达到300ms。
2. 瓶颈分析：通过 Arthas 追踪发现，80% 的请求耗时在数据库查询上。
3. 优化措施(仅为举例，具体情况依据个人而定)：

○ 引入 Redis 缓存热点商品数据，缓存命中率提升至 90%；

○ 对订单表按用户 ID 进行分库分表，单表数据量从 1 亿减少到 1 千万；

○ 将日志记录改为异步写入 Kafka，减少主线程耗时。

4.优化结果：最终压测 QPS 提升到 5,000，且响应时间稳定在 80ms 以内。此外，线上监控显示，实际高峰期的 QPS 与压测结果基本一致，系统未出现超时或宕机。”