系统设计面试面试指北

系统设计在面试中一定是最让面试者头疼的事情之一。因为系统设计相关的问题通常是开放式的,所以没有标准答案。你在和面试官思想的交流碰撞中会慢慢优化自己的系统设计方案。理论上来说,系统设计面试也是和面试官一起一步一步改进原有系统设计方案的过程。

系统设计题往往也非常能考察出面试者的综合能力,回答好的话,很容易就能在面试中脱颖而出。不论是对于参加社招还是校招的小伙伴,都很有必要重视起来。

接下来,我会带着小伙伴们从我的角度出发来谈谈:如何准备面试中的系统设计部分。

由于文章篇幅有限,就不列举实际例子了,可能会在后面的文章中单独提一些具体的例子。

个人能力有限。如果文章有任何需要改善和完善的地方,欢迎在评论区指出,共同进步!

系统设计面试一般怎么问?

我简单总结了一下系统设计面试相关问题的问法:

设计一个某某系统比如秒杀系统、微博系统、抢红包系统、短网址系统。设计某某系统中的一个功能比如哔哩哔哩的点赞功能。设计一个框架比如RPC框架、消息队列、缓存框架、分布式文件系统等等。某某系统的技术选型比如缓存用Redis还是Memcached、网关用SpringCloudGateway还是NetflixZuul2。系统设计怎么做?

我们将步骤总结成了以下4步。

Step1:问清楚系统具体要求

当面试官给出了系统设计题目之后,一定不要立即开始设计解决方案。你需要先理解系统设计的需求:功能性需求和非功能性需求。

为了避免自己曲解题目所想要解决的问题,你可以先简要地给面试官说说自己的理解,

为啥要询问清楚系统的功能性需求也就是说系统包含哪些功能呢?

毕竟,如果面试官冷不丁地直接让你设计一个微博系统,你不可能把微博系统涵盖的功能比如推荐信息流、会员机制等一个一个都列举出来,然后再去设计吧!你需要筛选出系统所提供的核心功能(缩小边界范围)!

为啥要询问清楚系统的非功能性需求或者说约束条件比如系统需要达到多少QPS呢?

让你设计一个1w人用的微博系统和w人用的微博系统能一样么?不同的约束系统对应的系统设计方案肯定是不一样的。

Step2:对系统进行抽象设计

我们需要在一个HighLevel的层面对系统进行设计。

你可以画出系统的抽象架构图,这个抽象架构图中包含了系统的一些组件以及这些组件之间的连接。

Step3:考虑系统目前需要优化的点

对系统进行抽象设计之后,你需要思考当前抽象的系统设计有哪些需要优化的点,比如说:

当前系统部署在一台机器够吗?是否需要部署在多台机器然后进行负载均衡呢?数据库处理速度能否支撑业务需求?是否需要给指定字段加索引?是否需要读写分离?是否需要缓存?数据量是否大到需要分库分表?是否存在安全隐患?系统是否需要分布式文件系统?......Step4:优化你的系统抽象设计

根据Step3中的“系统需要优化的点”对系统的抽象设计做进一步完善。

系统设计该如何准备?

知识储备

系统设计面试非常考察你的知识储备,系统设计能力的提高需要大量的理论知识储备。比如说你要知道大型网站架构设计必备的三板斧:

高性能架构设计:熟悉系统常见性能优化手段比如引入读写分离、缓存、负载均衡、异步等等。高可用架构设计:CAP理论和BASE理论、通过集群来提高系统整体稳定性、超时和重试机制、应对接口级故障:降级、熔断、限流、排队。高扩展架构设计:说白了就是懂得如何拆分系统。你按照不同的思路来拆分软件系统,就会得到不同的架构。实战

虽然懂得了理论,但是自己没有进行实践的话,很多东西是无法体会到的!

因此,你还要不断通过实战项目锻炼自己的系统设计能力。

保持好奇心

多思考自己经常浏览的网站是怎么做的。比如:

你刷微博的时候可以思考一下微博是如何记录点赞数量的?你看哔哩哔哩的时候可以思考一下消息提醒系统是如何做的?你使用短链系统的时候可以考虑一下短链系统是如何做的?......技术选型

实现同样的功能,一般会有多种技术选择方案,比如缓存用Redis还是Memcached、网关用SpringCloudGateway还是NetflixZuul2。很多时候,面试官在系统设计面过程中会具体到技术的选型,因而,你需要区分不同技术的优缺点。

系统设计面试必知

系统设计的时候必然离不开描述性能相关的指标比如QPS。

性能相关的指标

响应时间

响应时间RT(Response-time)就是用户发出请求到用户收到系统处理结果所需要的时间。

RT是一个非常重要且直观的指标,RT数值大小直接反应了系统处理用户请求速度的快慢。

并发数

并发数可以简单理解为系统能够同时供多少人访问使用也就是说系统同时能处理的请求数量。

并发数反应了系统的负载能力。

QPS和TPS

QPS(QueryPerSecond):服务器每秒可以执行的查询次数;TPS(TransactionPerSecond):服务器每秒处理的事务数(这里的一个事务可以理解为客户发出请求到收到服务器的过程);书中是这样描述QPS和TPS的区别的。

QPSvsTPS:QPS基本类似于TPS,但是不同的是,对于一个页面的一次访问,形成一个TPS;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就可计入“QPS”之中。如,访问一个页面会请求服务器2次,一次访问,产生一个“T”,产生2个“Q”。

吞吐量

吞吐量指的是系统单位时间内系统处理的请求数量。

一个系统的吞吐量与请求对系统的资源消耗等紧密关联。请求对系统资源消耗越多,系统吞吐能力越低,反之则越高。

TPS、QPS都是吞吐量的常用量化指标。

QPS(TPS)=并发数/平均响应时间(RT)并发数=QPS*平均响应时间(RT)系统活跃度

介绍几个描述系统活跃度的常见名词,建议牢牢记住。你不光会在回答系统设计面试题的时候碰到,日常工作中你也会经常碰到这些名词。

PV(PageView)

访问量,即页面浏览量或点击量,衡量网站用户访问的网页数量;在一定统计周期内用户每打开或刷新一个页面就记录1次,多次打开或刷新同一页面则浏览量累计。UV从网页打开的数量/刷新的次数的角度来统计的。

UV(UniqueVisitor)

独立访客,统计1天内访问某站点的用户数。1天内相同访客多次访问网站,只计算为1个独立访客。UV是从用户个体的角度来统计的。

DAU(DailyActiveUser)

日活跃用户数量。

MAU(monthlyactiveusers)

月活跃用户人数。

举例:某网站DAU为w,用户日均使用时长1小时,RT为0.5s,求并发量和QPS。

平均并发量=DAU(w)*日均使用时长(1小时,秒)/一天的秒数()=w/24=50w

真实并发量(考虑到某些时间段使用人数比较少)=DAU(w)*日均使用时长(1小时,秒)/一天的秒数-访问量比较小的时间段假设为8小时()=w/16=75w

峰值并发量=平均并发量*6=w

QPS=真实并发量/RT=75W/0.5=w/s

常用性能测试工具

后端常用

既然系统设计涉及到系统性能方面的问题,那在面试的时候,面试官就很可能会问:你是如何进行性能测试的?

推荐4个比较常用的性能测试工具:

Jmeter:ApacheJMeter是JAVA开发的性能测试工具。LoadRunner:一款商业的性能测试工具。Galtling:一款基于Scala开发的高性能服务器性能测试工具。ab:全称为ApacheBench。Apache旗下的一款测试工具,非常实用。没记错的话,除了LoadRunner其他几款性能测试工具都是开源免费的。

前端常用

Fiddler:抓包工具,它可以修改请求的数据,甚至可以修改服务器返回的数据,功能非常强大,是Web调试的利器。HttpWatch:可用于录制HTTP请求信息的工具。常见软件的QPS

这里给出的QPS仅供参考,实际项目需要进行压测来计算。

Nginx:一般情况下,系统的性能瓶颈基本不会是Nginx。单机Nginx可以达到30w+。Redis:Redis官方的性能测试报告:


转载请注明:http://www.aierlanlan.com/rzdk/3433.html