高频面题： 你们线上 QPS 多少？你 怎么知道的？

本文原文链接

尼恩说在前面

在45岁老架构师 尼恩的读者交流群(50+) 中，很多小伙伴要拿高薪，这就要面大厂、面架构，拿高薪。

在高级开发面试、大厂面试、架构师的面试过程中，常常会遇到下面的问题：

你们系统qps多少？你是怎么知道的？

假设每天有几千万请求，你的系统如何部署？

.....

尼恩在指导简历、指导面试的过程中，很多小伙伴，都有遇到这个问题。

可以说是一个面试的高频题目，极致的高频题目。

大家一定要把此文收藏起来， 好好背熟悉， 并且，在面试之前，都翻出好好复习一下。

尼恩不知道做过多少架构方案。目前尼恩已经专门从事架构师转型辅导 + 逆天改命帮扶工程 已经5年了，也不知道指导了多少开发完成了架构师的华丽转身、逆天改命。

现在，给大家提供一份比较全面的参考答案。使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让你的主管、同事爱到 “不能自已、口水直流”。

也一并把这个题目以及参考答案，收入咱们的 《尼恩Java面试宝典》V94版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

注：本文以 PDF 持续更新，最新尼恩 架构笔记、面试题 的PDF文件，请关注本公众号【技术自由圈】领取，回复：领电子书

来，咱们从基础概念入手，一步一步，给出上面的面试题答案。

本文目录

一、什么是QPS？

QPS Queries Per Second 是每秒查询率 ,

是一台服务器每秒能够相应的查询次数，

是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数，也即是最大吞吐能力。

二、什么是TPS？

TPS Transactions Per Second 也就是事务数/秒。

什么是事务？

一个事务是指一个客户机向服务器发送一起完整的 开始 start 请求，内部各种ACID 事务属性的 并发数据操作， 最后 提交一个commit操作结束整个Transaction的过程。

所以从上面可以看出来，一个事务包含明确的三阶段：开始，处理，commit/rollback。

一个事务的中间环节，会包含多个并行的sql的操作。

本质上事务是对多个并发操作进行数据一致性的管理，事务的ACID规则如下：

spring框架有本身自带的事务传播性，数据库也有事务，

数据库事务包含事务的start，数据操作，事务commit等非常清晰的阶段。当数据库开启事务后，当前线程改变数据库数据，并未提交当前事务，那其他线程读数据库的时候会出现脏读，幻读。

在web服务器领域来说，事务可以指用户的一次完整的交互处理，这次交互处理里边， 包含了多次的服务端api调用。

一个web服务器包含包含多次api请求，多次api响应。

比如，在尼恩指导做过的《亿级数据 搜索中台》中，用户执行一次搜索操作，浏览器 client通过vue框架要调用后端的上10个api接口，类似如下：

三、QPS和TPS的关系

1、Tps 即每秒处理事务数，从web应用的角度来说，包括了

1）用户通过client工具，开始发起请求

2）client工具执行N个服务端的API调用

3）client进行API结果的聚合再渲染，最后呈现给用户

这三个过程组成一个事务，每秒能够完成N事务，Tps也就是N；

2、Qps Queries Per Second 是每秒查询率，从web应用的角度来说，就是单次api的调用

Qps 基本类似于 Tps，但是不同的是：

• 用户通过client工具完成一个页面的一次访问，形成一个Tps；
• 如果一次页面请求，产生多次对服务器的api请求，这个Tps 包含多个 qps。
• 如果一次页面请求，产生1次对服务器的api请求，这个Tps 包含1个 qps。也就是 tps=qps

四、什么是RT，响应时间

四、什么是RT，响应时间

响应时间：执行一个请求从开始到最后收到响应数据所花费的总体时间。

RT 即从客户端发起请求到收到服务器响应结果的时间。

响应时间RT(Response-time)，是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。

单节点QPS公式：QPS=1000ms/RT

假设一个节点RT是10ms,则可以很容易的计算出QPS,QPS = 1000/10 = 100

对同一个分布式系统而言，支持的节点数越多，QPS越高。

多节点场景，如果把节点提升到2，那么整个系统的QPS则为 2*（1000/10） = 200,

可见QPS随着节点横向扩展、节点的增加而线性增长，

当然，那QPS上不去就加节点，听起来很有道理，但是往往现实并非如此，

为啥：一个请求的处理链路上受影响的环节很多， 不能只解决某一层的吞吐量，而是需要所有的层都要同步提升。

五、什么是并发数？

并发数（并发度）：指系统同时能处理的请求数量，同样反应了系统的负载能力。

并发数：系统同时处理的request/事务数

并发数 = QPS*平均响应时间

这个是一个理论的并发数。

注意，这个并发数，和jemeter的并发数不一样。jmeter中的并发数，就是同时启动的线程数

线程组设置为100个线程，运行过程中未出现任何异常，满足100个线程并发操作需求，那么并发数就是100

六、吐吞量

系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。

单个request 对CPU消耗越高，IO速度越慢，那么，系统吞吐能力越低，

反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间。

1. QPS（TPS）：（Query Per Second）每秒钟request/事务 数量
2. 并发数：系统同时处理的request/事务数
3. 响应时间：一般取平均响应时间

理解了上面三个要素的意义之后，就能推算出它们之间的关系：

QPS（TPS）= 并发数 / 平均响应时间并发数 = QPS * 平均响应时间

七、什么是PV、UV、DAU、MAU

还有一些相关的概念

PV

PV（Page View）：页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次。

可以统计服务一天的访问日志得到。

UV

UV（Unique Visitor）：独立访客，统计1天内访问某站点的用户数。

可以统计服务一天的访问日志并根据用户的唯一标识去重得到。

响应时间（RT）：响应时间是指系统对请求作出响应的时间，一般取平均响应时间。

可以通过Nginx、Apache之类的Web Server得到。

DAU

DAU（Daily Active User）：日活跃用户数量。

常用于反映网站、互联网应用或网络游戏的运营情况。

DAU通常统计一日（统计日）之内，登录或使用了某个产品的用户数（去除重复登录的用户），与UV概念相似

MAU

MAU（Month Active User）：月活跃用户数量，指网站、app等去重后的月活跃用户数量

八、最佳线程数量

刚好消耗完服务器的瓶颈资源的临界线程数，公式如下

最佳线程数量=（（线程等待时间+线程cpu时间）/线程cpu时间）* cpu数量

在尼恩《Java高并发核心编程 卷2 加强版》一书中，对以上公式进行了细致的介绍。

无论io密集型线程池、cpu密集型线程池，都满足上面的公式。

特性：

• 在达到最佳线程数的时候，线程数量继续递增，则QPS不变，而响应时间变长，持续递增线程数量，则QPS开始下降。
• 每个系统都有其最佳线程数量，但是不同状态下，最佳线程数量是会变化的。
• 瓶颈资源可以是CPU，可以是内存，可以是锁资源，IO资源：超过最佳线程数-导致资源的竞争，超过最佳线程数-响应时间递增。

九、吞吐量 评估

比较关键的关键的问题来了：

假设你的项目的用户量有百万级，然后每天有几千万请求，高峰期每秒有好几千请求。

每个服务会有多高的QPS？

那么这个时候，你的服务会有多高的QPS？

按二八定律来看，如果每天 80% 的访问集中在 20% 的时间里，这 20% 时间就叫做峰值时间。

• 公式：( 总PV数 80% ) / ( 每天秒数 20% ) = 峰值时间每秒请求数(QPS)
• 机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器

1、每天300w PV 的在单台机器上，这台机器需要多少QPS？

( 3000000 0.8 ) / (86400 0.2 ) = 139 (QPS)

2、如果一台机器的QPS是58，需要几台机器来支持？ 139 / 58 = 3

十、 你们线上QPS 多少，你是怎么知道的？

为什么需要监控 QPS？

QPS 是衡量后端服务性能的关键指标，可以帮助你及时发现性能瓶颈和问题。

Prometheus 是什么？

Prometheus 是一个开源监控框架，用于收集和存储时序数据，例如度量标准和日志。

如何配置 Prometheus 监控后端服务？

在springboot 应用中完成指标 my_app_requests_total 的暴露，在 prometheus.yml 配置文件中指定要监控的指标。

Grafana 是什么？

Grafana 是一个开源的可视化工具，用于创建和共享交互式仪表盘，展示 Prometheus 等监控系统收集的数据。

如何可视化 QPS 数据？

在 Grafana 中创建一个仪表盘，添加一个图形面板，显示 my_app_requests_total{method="GET"} 度量标准。

从0到1 实现线上 QPS的监控 的核心流程

SpringBoot添加actuator和prometheus依赖，然后使用 actuator暴露prometheus 端点；SpringBoot中配置prometheus数据采集Bean，实现端点数据的url 暴露服务。

Prometheus启动文件中添加监控的后台服务信息，如数据采集间隔、服务IP:PROT等；进行指标数据的拉取和时序数据的打标。

Grafana配置：使用 Metrics browser配置监控的指标：包括uri、outcome等等；完成 Transform配置数据转换：最后进行Labels to fields配置图例名称的配置。

1. 配置 Spring Boot 项目

SpringBoot添加actuator和prometheus依赖，然后使用 actuator暴露prometheus 端点；SpringBoot中配置prometheus数据采集Bean，实现端点数据的url 暴露服务。

添加依赖

在 pom.xml 文件中添加 Spring Boot Actuator 和 Prometheus 依赖：

<dependencies>
    <!-- Spring Boot Actuator -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-actuator</artifactId>
    </dependency>
    <!-- Micrometer Prometheus Registry -->
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-registry-prometheus</artifactId>
    </dependency>
</dependencies>

配置 Actuator 暴露的端点

在 application.properties 或 application.yml 中配置 Actuator 暴露的端点

# 暴露所有 Actuator 端点
management.endpoints.web.exposure.include=*
# 暴露 Prometheus 端点
management.endpoints.web.exposure.include=prometheus

management.metrics.web.server.request.metric-name = http.server.requests

配置 Prometheus 数据采集 Bean

创建一个配置类，配置 Prometheus 数据采集 Bean：

@SpringBootApplication
@ServletComponentScan
public class OneApplication {
   

    public static void main(String[] args) {
   
        SpringApplication.run(OneApplication.class, args);
    }

    // 非常重要
    @Bean
    MeterRegistryCustomizer<MeterRegistry> configurer(
            @Value("${spring.application.name}") String applicationName) {
   
        return (registry) -> registry.config().commonTags("application", "spring-boot-app");
    }
}

这个应用程序可能是一个 Web 服务，使用 Spring Boot 框架开发，并且可能集成了一些监控功能，如使用 Micrometer 进行指标监控。

MeterRegistry 是 Micrometer 库中的核心组件，用于收集和管理指标，例如记录请求计数、请求时长、内存使用等, 这个是非入侵的。

通过这个 configurer Bean，我们为所有的指标添加了一个通用的标签，使得在监控系统中查看指标时，可以清晰地知道这些指标来自哪个应用程序。

启动springboot项目后，查看输出的指标

http://localhost:8080/actuator/prometheus

参考如下：

# HELP http_server_requests_seconds  
# TYPE http_server_requests_seconds summary
# http_server_requests_seconds_count 表示请求次数3次
http_server_requests_seconds_count{application="hello",exception="None",method="POST",outcome="SUCCESS",status="200",uri="/prometheus/post/{id}",} 3.0
# http_server_requests_seconds_sum 表示3次请求总响应时长是 3.021s
http_server_requests_seconds_sum{application="hello",exception="None",method="POST",outcome="SUCCESS",status="200",uri="/prometheus/post/{id}",} 3.0210991
http_server_requests_seconds_count{application="hello",exception="None",method="GET",outcome="SUCCESS",status="200",uri="/actuator/prometheus",} 110.0
http_server_requests_seconds_sum{application="hello",exception="None",method="GET",outcome="SUCCESS",status="200",uri="/actuator/prometheus",} 3.8388842
# HELP 是对这个指标的描述
# HELP http_server_requests_seconds_max  
# 这个指标类型
# TYPE http_server_requests_seconds_max gauge
# http_server_requests_seconds_max 表示所有请求中，最长响应时间的一次是 2.00s
http_server_requests_seconds_max{application="hello",exception="None",method="POST",outcome="SUCCESS",status="200",uri="/prometheus/post/{id}",} 2.0021618
http_server_requests_seconds_max{application="hello",exception="None",method="GET",outcome="SUCCESS",status="200",uri="/actuator/prometheus",} 0.0345458

数据统计标识：

序号	标识	描述
1	http_server_requests_seconds_count	请求量
2	http_server_requests_seconds_sum	请求总耗时
3	http_server_requests_seconds_max	请求最大耗时

指标的最后的部分是类型， 主要的类型有：

Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）

一般 需要的 常规 指标 数据， 都可以通过上面的指标统计出来的。

1. 当前在线总数, 折线图, 时间线和人数
2. 吞吐量 - 每个时间点处理的请求数 - 折线图
3. 接口响应时长 - 每个接口的响应时长，横坐标是时间线，折线图
4. 错误分布 - 状态码各个请求分布

具体，请参见配套视频《第47章：工业级底座：基于GPA 实现 Springcloud 底座的 工业级 监控治理》

2. 配置 Prometheus

2.1 下载并启动 Prometheus

从 Prometheus 官网下载相应版本的 Prometheus，并解压。

2.2 配置 Prometheus 启动文件 prometheus.yml

在 prometheus.yml 中添加以下内容：

global:
  scrape_interval: 15s  # 采集间隔
scrape_configs:
  - job_name: 'prometheus'
    metrics_path: '/actuator/prometheus'  # 从 Spring Boot Actuator 的 Prometheus 端点采集数据
    static_configs:
      - targets: ['localhost:9090']  # 替换为你的服务 IP 和端口

解释

• scrape_interval 定义了 Prometheus 从目标拉取数据的时间间隔，这里是 15 秒。
• job_name 是监控任务的名称，这里叫 prometheus。
• metrics_path 是 Prometheus 采集数据的路径，这里指向 Spring Boot Actuator 的 Prometheus 端点。
• targets 是要监控的服务地址。

3. 启动 Prometheus

在 Prometheus 的根目录下运行：

./prometheus --config.file=prometheus.yml

4. 配置 Grafana

4.1 下载并启动 Grafana

从 Grafana 官网下载并启动 Grafana。

4.2 配置数据源

打开 Grafana 页面，登录后添加 Prometheus 作为数据源。

在 Configuration -> Data Sources 中添加一个新的数据源，选择 Prometheus，并输入 Prometheus 的 URL（默认是 http://localhost:9090）。

4.3 配置指标

在 Create -> Dashboard -> Add Query 中，使用 PromQL 表达式进行指标查询。

例如，使用 下面的公式统计qps

rate(http_server_requests_seconds_count{uri="/api/v1/prometheus/test"}[5m])

上面是一个 PromQL表达式，PromQL （Prometheus Query Language）是 Prometheus 的查询语言，用于从 Prometheus 的时间序列数据库中检索和操作数据。它可以用来计算和聚合指标数据，以生成有用的统计信息，例如计算速率、总和、平均值等。

http_server_requests_seconds_count 这是一个指标名称，通常是在使用 Spring Boot Actuator 与 Micrometer 集成时，用于统计 HTTP 服务器请求的数量。这个指标会记录每个请求的计数，根据不同的标签（如 uri）进行区分。

{uri="/api/v1/prometheus/test"} 这是一个标签选择器，用于筛选出 http_server_requests_seconds_count 指标中 uri 标签等于 /api/v1/prometheus/test 的时间序列数据。通过使用标签选择器，可以将指标数据进行分类和筛选，以便你只关注特定的请求或服务。

[5m]这表示时间范围，这里是 5 分钟。这个时间范围用于指定 rate 函数的计算窗口。

rate() 函数用于计算时间序列在给定时间范围内的每秒平均增长率。具体计算步骤如下：

• 它首先查看在指定的 5 分钟（[5m]）时间窗口内的 http_server_requests_seconds_count 指标数据。
• 然后计算该指标，在这个时间窗口内的每秒平均增长率。对于 http_server_requests_seconds_count 指标，这可以看作是在过去 5 分钟内每秒请求的平均增长率。

5. 查看和分析 QPS

在 Grafana 中创建一个面板，将 QPS 指标添加到面板中，使用上述 PromQL 表达式进行绘制。

你可以查看 QPS 的实时趋势、历史趋势，以及不同时间范围的 QPS 数据。

6. 优化和调整

根据 QPS 监控结果，你可以调整 Spring Boot 应用程序的性能，如添加缓存、优化数据库查询、增加服务器等。

调整 Prometheus 的采集间隔和配置，以获取更精确的数据。

进一步优化 Grafana 面板，添加告警规则等。

具体实操，请参见视频《第47章：工业级底座：基于GPA 实现 Springcloud 底座的 工业级 监控治理》

十一：假设每天有几千万请求，你的系统如何部署？

45岁资深老架构师尼恩的参考答案，点此查看

100W 高薪 招行P8 架构面试真题

被狠狠拷打了，问的人都懵了。项目场景题太难了，不好好准备，真的答不出!

尼恩将给出全部答案：

1.如何让系统抗住双十一的预约抢购活动?

45岁资深老架构师尼恩的参考答案，点此查看

2.如何从零搭建10万级QPS大流量、高并发优惠券系统?

45岁资深老架构师尼恩的参考答案，点此查看

3.百万级别数据的 Excel 如何快速导入到数据

45岁资深老架构师尼恩的参考答案，点此查看

4.如何设计一个支持万亿GB网盘实现秒传与限速的系统?

45岁资深老架构师尼恩的参考答案，点此查看

5.如何根据应用场景选择合适的消息中间件?

45岁资深老架构师尼恩的参考答案，点此查看

6.如何提升 RocketMQ 顺序消费性能?

45岁资深老架构师尼恩的参考答案，点此查看

7.设计分布式调度框架，该考虑哪些问题?

45岁资深老架构师尼恩的参考答案，点此查看

9.如何让系统抗住双十一的预约抢购活动?

45岁资深老架构师尼恩的参考答案，点此查看

10.问 ：如何解决高并发下的库存抢购超卖少买？

45岁资深老架构师尼恩的参考答案，点此查看

11.为什么高并发下数据写入不推荐关系数据？

45岁资深老架构师尼恩的参考答案，点此查看

12.如果让你设计一个分布式链路跟踪系统?

即将发布。

前几天 尼恩给一个 小伙伴改造过一个 100wtps 链路跟踪平台简历， 非常NB， 牛到暴表。

yMTM1NQ==&mid=2247504465&idx=1&sn=2bb789691a64c4de1100669ca89136a9&scene=21#wechat_redirect)

9.如何让系统抗住双十一的预约抢购活动?

45岁资深老架构师尼恩的参考答案，点此查看

10.问 ：如何解决高并发下的库存抢购超卖少买？

45岁资深老架构师尼恩的参考答案，点此查看

11.为什么高并发下数据写入不推荐关系数据？

45岁资深老架构师尼恩的参考答案，点此查看

12.如果让你设计一个分布式链路跟踪系统?

即将发布。

前几天 尼恩给一个 小伙伴改造过一个 100wtps 链路跟踪平台简历， 非常NB， 牛到暴表。

说在最后：有问题找老架构取经‍

只要按照上面的 尼恩团队梳理的 方案去作答， 你的答案不是 100分，而是 120分。 面试官一定是 心满意足， 五体投地。

按照尼恩的梳理，进行 深度回答，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

在面试之前，建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》，里边有大量的大厂真题、面试难题、架构难题。

很多小伙伴刷完后， 吊打面试官， 大厂横着走。

在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

另外，如果没有面试机会， 可以找尼恩来改简历、做帮扶。前段时间，刚指导一个小伙 暴涨200%（涨2倍），29岁/7年/双非一本 ， 从13K一次涨到 37K ，逆天改命。

狠狠卷，实现 “offer自由” 很容易的， 前段时间一个武汉的跟着尼恩卷了2年的小伙伴， 在极度严寒/痛苦被裁的环境下， offer拿到手软， 实现真正的 “offer自由” 。

尼恩技术圣经系列PDF

• 《NIO圣经：一次穿透NIO、Selector、Epoll底层原理》
• 《Docker圣经：大白话说Docker底层原理，6W字实现Docker自由》
• 《K8S学习圣经：大白话说K8S底层原理，14W字实现K8S自由》
• 《SpringCloud Alibaba 学习圣经，10万字实现SpringCloud 自由》
• 《大数据HBase学习圣经：一本书实现HBase学习自由》
• 《大数据Flink学习圣经：一本书实现大数据Flink自由》
• 《响应式圣经：10W字，实现Spring响应式编程自由》
• 《Go学习圣经：Go语言实现高并发CRUD业务开发》

……完整版尼恩技术圣经PDF集群，请找尼恩领取