前言

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

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

你们系统qps多少？怎么部署的？

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

…

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

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

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

40岁老架构师尼恩，不知道做过多少架构方案。目前尼恩已经专门从事架构师转型辅导2年了，也不知道指导了多少开发完成了架构师的华丽转身。现在，给大家提供一份比较全面的参考答案。使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让你的主管、同事爱到 “不能自已、口水直流”。

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

注：本文以 PDF 持续更新，最新尼恩 架构笔记、面试题 的PDF文件，请到文末公号【技术自由圈】取

尴尬的面试现场：

首先，给大家复盘一下， 很多小伙伴尴尬的面试现场

于是面试官和候选人可能会展开如下一系列的问题：

面试官：你说说，你们项目目前有多少注册用户？

候选人：这个。。。。好像大概几万？

面试官：好吧，那你说一下你们系统每天日活是多少？

候选人：这个。。。。还真的没统计过啊。。大概可能有几千或者几万个人？

面试官：好吧，那你们的系统高峰期QPS有多大呢？

候选人：这个。。。。也没统计过，大概500吧！

面试官：好吧，那这样吧，假设每天几千万请求，如何进行qps评估？ 然后，如何进行部署架构？

候选人：嗯嗯… 这个… 我真的不知道啊。。。

面试官：咦？你怎么支支吾吾的，难道你项目线上如何部署，也不清楚？

候选人：…………

候选人卒

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

一、什么是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(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

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

最后的问题，也是最为关键的问题来了：

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

你的系统如何部署？

那么这个时候，每个服务需要部署多少台机器才可以保证不雪崩？ 这些服务器的配置是多高？

项目中涉及的MySQL、Redis、ES、RocketMQ中间件，的如何做高并发架构？

项目中涉及的MySQL、Redis、ES、RocketMQ中间件，的如何做高可用架构？

以上组件的架构方案，可以参照 尼恩的《价值10W架构师知识图谱》，

在《价值10W架构师知识图谱》里边，有MySQL、Redis、ES、RocketMQ、Nginx等中间件的核心吞吐量性能指标，然后再结合自己的项目，简单的规划一下，就可以了。

注意，这里没有标准答案。一定要再结合自己的项目去规划，

其实，只要简单的规划一下，就可以了。

可以参照 《价值10W架构师知识图谱》，一路从 网关接入层，进入到 服务层、缓存、DB层、消峰解耦层等等，一层一层的进行系统的部署架构。

《价值10W架构师知识图谱》是一个庞大的架构师的知识地图，具体的链接，可以找尼恩获取。

推荐相关阅读

《问懵了…美团一面索命44问，过了就60W+》

《炸裂了…京东一面索命40问，过了就50W+》

《问麻了…阿里一面索命27问，过了就60W+》

《百度狂问3小时，大厂offer到手，小伙真狠！》

《饿了么太狠：面个高级Java，抖这多硬活、狠活》

《字节狂问一小时，小伙offer到手，太狠了！》

《收个滴滴Offer：从小伙三面经历，看看需要学点啥？》

《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓