常见问题:你的系统什么配置,架构是什么样的、并发量多少、
qps
、
pv
、
up
是多少
...........
https://zhuanlan.zhihu.com/p/337708438
https://www.cnblogs.com/dayu2019/p/11906855.html
https://blog.csdn.net/qq_23101033/article/details/74977874
1. 基本关键词的含义理解
并行
同一个时间多个执行多个任务;称之为并行;
比如:
4
核的电脑,同一时间的可以
4
个程序并行同时运行
并发
在一定时间内,一刻不停切换完成多个任务;称之为并发;
比如:一个人不同的重复接待客户,那他就出现了并发;
访问量 , 浏览量 , 点击量
- 点击量:首先我们先来了解一下网站点击量,什么是点击量?点击量是指用户点击网站的次数的数据,是用来衡量网站流量的标准。
- 浏览量:用户在网站页面上查看的数量被称为浏览量,打个比方吧,比如我们的网站页面上有2张图片,用户点击网站页面一次,在服务器上会显示有3次点击,一次是网站页面的点击量,其他两次是因为网站页面上的2张图片,这也就是说每一张图片在网页中都是一个独立的文件
- 访问量:访问量是用户或者蜘蛛来访问你的网站,所产生的数据,一个用户可以多次访问你的网站。
请求数 /QPS/RPS
==>>>
如下是针对单机器的
QPS
;也就是机器可以在
1s
下处理的请求数量
简单的讲:
1s
可以处理多少请求
-- -
项目运行中所承载的
qps
,并非系统的最高
qps
请求数
= QPS = RPS
QPS
:
Queries Per Second
是衡量信息检索系统(例如搜索引擎或数据库)在一秒钟内接收到的搜索流量的一种常见度量。该术语在任何请求-
响应系统中都得到更广泛的使用,更正确地称为每秒请求数(
RPS
:
Request Per Second
)。
计算公式:
QPS = (PV * 0.8) / (86400 * 0.2)
机器数
= QPS /
一台机器
QPS
实例:
(10w * 0.8) / (86400 * 0.2) ~~ 4.629629629
- 10wPV的QPS = (10w * 0.8) / (86400 * 0.2) = 4.62
0.8
与
0.2
解释;基于
28
原则、一天的时间
80%
用户访问集中在
20%
的时间范围内,也就是
80%
的用户集中在
4.8
个小时内访问;不考虑活动qps
---->>
还可以通过下面的方式计算
QPS = (PV * 0.8) / (3 * 60 * 60)
3
是一个经验因子,相当于对访问任务在
3
个小时内完成
QPS
达到
1000
已经可以满足大多数中型公司,几百万用户数的需求。一般来说,
QPS
只要能够达到
500
的,就可以被认为是高并发了
TPS
简单的讲:
1s
可以处理多少事务
QPS
基本类似于
TPS
,但是不同的是,对于一个页面的一次访问,形成一个
TPS
;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就可计入“QPS”
之中。如,访问一个页面会请求服务器
2
次,一次访问,产生一个“T”
,产生
2
个
“Q”
。
平均时间 RT
简单理解为系统从输入到输出的时间间隔,宽泛的来说,他代表从客户端发起请求到服务端接受到请求并响应所有数据的时间差。一般取平均响应时间。
并发量 / 并发数
是指在一定时间内完成多少任务;在业界主要看中
1s
完成的任务量、
1
分钟完成的任务量、
1
小时完成的任务量
比如:一个人
1
小时可以回复
100
个人的信息;那么他的并发量就是
100
人
/
小时
主要是指系统层面的量
吞吐量
主要是指一段时间内完成了多少量,
qps*
时间
2. 宽带:影响的是传输效率
思考问题?
1M/S
的宽带下载速度多快、假设网页大小为
30kb
不计算其他因素、并发量多大?
科普知识 - 单位转化
- 位/比特(bit):内存中最小的单位,二进制数序列中的一个0或一个1就是一比比特
- 1Byte=8bit(位) 1KB=1024Byte(字节) 1MB=1024KB 1MB=1024KB 1GB=1024MB 1TB=1024GB
- 1比特 = 一个二进制位,只有0和1两种状态
- 1字节 = 8 比特
- 1k字节 = 1024字节(字节英文为byte,注意与bit区分)
- 1M字节= 1024k字节
宽带单位
- bps:位/每秒,通常对于串行总线设备使用bps为单位,如串口,USB口,以太网总线等。
- Bps:字节/每秒,通常对于并行总线设备使用Bps为单位,如并口,IDE硬盘等。
1m/s宽带下的计算方式
1Byte=8bit
,意思就是
1
字节占用
8
个二进制位。
因为:
bit
缩写为小写
b
,所以
1M/s
(速度单位,后面接秒,简称
s
)
=1Mbit/s
缩写为1M/s=1Mb/s=1024Kbit/s=128KByte/s(这一步根据
1Byte=8bit
)
=128KB/s
(根据
Byte
缩写为
B
)
因为:
Byte
缩写为大写
B
,所以
1M=1MByte
缩写为
1M=1MB=1024KB
(这个
1M
是存储单位,所以后面接
Byte
,缩写为大写B
)。
通常所说的
1M
宽带的理论速度就是
1Mbit/s=1024 Kbit/s=128 KByte/s=128KB/s
1m/s宽带下的并发计算
1m/s = 128kb/s,
如果一个网页的大小在优化后为
30kb
、那么
1M
带宽可支撑
4
个用户在
1
秒内同时打卡网页,所以,
1M
带宽1
秒内的并发数为
4
、根据网站
8S
的原则(用户会等待网页
8s
时间,如果超过就会关闭网站),在
2s
内
1M
宽带可支持8个用户以此内推;
理想上:一天
86400
秒,一天可支撑
34
万
IP
、但不现实;网站一天访问量高峰集中在上午
9
点到
11
点、下午
3
点到
5
点和晚上8
点到
10
点,这个时间段并发数
4
也是不小的访问量。
实例:如果网站日均
IP2000
左右,使用的就是
1M
带宽的云服务器基本足够,还可以在网站上接入了
CDN
,
CDN
和
OSS这种成本是低廉的,拿CDN
来讲,用户遍布五湖四海,从用户体验的角度来考虑,网站也要接入
CDN
3.机器选型
https://ecs-buy.aliyun.com/wizard?spm=5176.13329450.res-empty-sale.buy.6ae54df5hktOcj#/prepay/cn-hangzhou?or
derSource=buyWizard-console-overview
4.经典面试问题解析
4.1有一个实时排名预计的pv 1kw 高峰qps 1k 请画出此服务的技术及网络架构图
第一步:计算系统每天正常 QPS :
计算公式
: QPS = (PV * 0.8) / (86400 * 0.2)
1kw PV
的
QPS
约为
463
;
(1kw * 0.8) / (86400 * 0.2) = 462.9629629..
对于最高峰值
1k QPS
可暂时忽略,视为双十一的秒杀特殊场景
第二步:机器选择与计算
这一步,在题目中是没有回答的;我们可以自己拟定好数据,并和面试官讲;拟定如下数据
机器选型暂定为:
8
核
16G/32
核
16G
计算:
10
个线程
- 500ms
;
1
分钟下每个线程平均运行
0.5s /
等待被运行
1.5s =
》
80%
1.
最佳线程数
公式
: (1 +
线程等待时间
/
线程运行时间
) * CPU
利用率
* CPU
核数
最佳线程数:约为
26
,
(1 + 1.5 / 0.5) * 80% * 8 = 25.6
2.
单线程的
QPS
公式
: (1000ms / RT),
其中
1000ms
指的是
1s
单线程的
QPS
:约为
5
;
1000 / 200 = 5
3.
当前机器的理论
qps
机器
QPS
约为
120,
单线程的
QPS *
最佳线程数
= 26 * 5 = 130 (
可选:我们可以在这个理论的基础上再减去
10
个点
;
因为实际程序的运行还会因io/
请求
/
业务
/
网络
/
内存等因素影响
)
130
并发量 、网页大小计算宽带大小
4.
初步估算基本机器数
机器数约为
4
台
8
核
16G
;
463 / 120 = 3.8333
约为
4
台(最低
-
此处非整个系统
-
实际会高出这个值)
第三步:实时排名:对业务的分析与思考
需要注意这里只是提到排行、但并未指明具体是那块类型的排行比如商品排行、文章排行
思考:
0.
排名的方式规则浏览量
/
访问量
/
点击量
/
评论量
--
》浏览量
/
访问量
/
点击量
/
评论量
=
》可以先到
Redis
中
->
入库
思考:
1.
实时的延时容忍度控制在多少时间范围以内,另外用户对排行的浏览是刷新更新还是实时推送更新;
--
》如果是页面刷新排行
=
》就是点击页面的时候去查询即可 (一般)
--
》如果是在页面在线刷新
=
》需要考虑利用
websocket
推送,可以考虑单独构建一个推送信息的服务器(特殊)
思考:
2.
另外排名一般是指前
10
、程序需要加载前
20
或
50
的数据;
--
》可以考虑先把热点数据加载进入
Redis
中,利用
zset
存储
思考:
3.
聚合统计规则查询性能问题,一般这种查询排行的性能都不是特别好
--
》可以考虑,在
mysql
层面设计物化视图统计表,记录性能较快的数据;并利用异步的脚本进行监控,
mysql
的binlog日志的数据信息变化;
--
》定期对
mysql
进行数据的聚合更新物化视图的数据
第四步:围绕整体的项目架构思维; 7 个不可信
主要围绕:高并发、高可用、高性能;还有个话题就是低成本,突发应对
思维
1
:对机器不可信
任何机器都会存在宕机崩溃问题
思维
2
:流量不可信
用户的访问和运营策略有关必须做好监控监听,以及顶峰限流
思维
3
:响应不可信
无论是对
mysql
查询、
redis
查询还是
mongodb
等都会存在不确定性的因素造成访问需要特别久的时间因此程序层面要
考虑超时处理
思维
4
:稳定发展不可信
任何项目不可能一直稳定,持续的状态;必须保持发展的眼光去考虑项目的扩容和缩容问题;
思维
5
:那东西简单不可信
要是所有事情都像看的那么简单,那就不存在什么架构师去设计规划了;实际做起来往往很复杂,需要的时间也很多;
思维
6
:万一不会不可信
你担心会存在问题,那就一定会存在不要问为什么,可能出错就一定会出错只是时候未到,做好应对预防;
思维
7
:自以为不可信
一定要对自己也有否定的观点,往往很多问题自以为是结果确不是,要多自以为可以世界上就没有谈论开会的话题了;
第五步:基本设计
基础实现、以文章为话题
以文章为话题
1. 首先基础结构
![](https://i-blog.csdnimg.cn/blog_migrate/84546a3255806f9a4a42626253d0fba2.png)
目的就是具备实现该功能
- redis: 用与存储排行的文章id/短标题/排行字段/
- mongodb: 存储文章的详细信息包括id/用户/文章内容等聚合信息
- mysql: 可以利用物化视图,额外建立一个统计表存储热点排行数据
- app server: 在流量访问的时候,会更新排行的数据信息(入库; 或者缓存统计;)
2. 日常流量QPS的满足及实时推送
- elasticsearch: 在目前的业务上的说明中可以暂时不用,如果只是排行的话,当然如果有复杂查询还是可以考虑
- app server: 我们以8核16G或32G的机器,部署4台(建议是5台这样可以提高系统的高可用)
- 用户行为与排行: 对于排行的规则不明确,但是可以设置合理的缓冲,如果只是评论量排序则可以考虑写入到mysql,如果是像点击量浏览量的更新则推荐异步更新
- 数据同步服务: 该服务会在系统启动的时候就会去mysql中聚合排序的结果并存入到redis和mongodb中预热(热点, 前50条的数据);在有新的排行信息变动的时候,根据binlog日志信息,同步到redis中即可更新顺序,并且通知推送服务推送最新排行给用户
- 推送服务: 在用户访问的时候可利用websocket与推送服务建立连接,在有新的排行更新的时候,推送服务通过websocket推送信息到用户的界面更新
- nginx+lua: 这一层主要是用于快速响应实时排行的数据信息结果,需要查询的时候可根据id去mongodb中获取对应信息内容
-> 成本核算在 1.6w ~ 3w 一月
3. 高峰期的应对处理1k qps
理论上
1k qps
需要
9
台机器,但如果一次性就
9
台机器是比较浪费的,平时用不上;因此这个环节主要是考察系统内部是否拥有系统状态的监控以及应对;
这个话题我们需要从两个角度来考虑
a.
是特殊活动可达到这么高的
QPS
、
b.
偶然的情况才会出现这么高的
QPS
a.
是特殊活动可达到这么高的
QPS:
针对这个话题最合理的方案就是加临时服务器,如双十一很多商家都会选择购买临时服务器来应对
b.
偶然的情况才会出现这么高的
QPS
- 监控: 需要自主对系统的流量进行监控(可以购买云产品)
- 应对: 可以针对监控情况第一个是通知、第二个是应对如降级或者扩容
- 降级: 比如用户请求的时候我们可以响应已经准备的缓存页面、排队页面(将用户导流到排队页面等一会重试)、无货(直接告知用户没货了)、错误页(如活动太火爆了,稍后重试)等等
![](https://i-blog.csdnimg.cn/blog_migrate/c66002cb7f1fcc1313b1d649cecd3d25.png)