【⾯试必看】系统设计⾯试该如何回答？
系统设计在⾯试中⼀定是最让⾯试者头疼的事情之⼀。 因为系统设计相关的问题通常是开放式的，所以没有标准答案。你在和⾯试官思想的交流碰撞中会慢慢优化⾃⼰的系统设计⽅案。理论上来说，系统设计⾯试也是和⾯试官⼀起⼀步⼀步改进原有系统设计⽅案的过程。
系统设计题往往也⾮常能考察出⾯试者的综合能⼒，回答好的话，很容易就能在⾯试中脱颖⽽出。不论是对于参加社招还是校招的⼩伙伴，都很有必要重视起来。
接下来，我会带着⼩伙伴们从我的⾓度出发来谈谈：如何准备⾯试中的系统设计部分。
由于⽂章篇幅有限，就不列举实际例⼦了，可能会在后⾯的⽂章中单独提⼀些具体的例⼦。
个⼈能⼒有限。如果⽂章有任何需要改善和完善的地⽅，欢迎在评论区指出，共同进步！
我也给⼤家整理了⼀份+，需要的可以点击领取
系统设计⾯试⼀般怎么问？
我简单总结了⼀下系统设计⾯试相关问题的问法：
设计⼀个某某系统⽐如秒杀系统、微博系统、抢红包系统、短⽹址系统。
设计某某系统中的⼀个功能⽐如哔哩哔哩的点赞功能。
设计⼀个框架⽐如 RPC 框架、消息队列、缓存框架、分布式⽂件系统等等。
某某系统的技术选型⽐如缓存⽤Redis 还是Memcached、⽹关⽤Spring Cloud Gateway 还是Netflix Zuul2 。
系统设计怎么做？
我们将步骤总结成了以下 4 步。
Step1：问清楚系统具体要求vbs命令参考手册
当⾯试官给出了系统设计题⽬之后，⼀定不要⽴即开始设计解决⽅案。 你需要先理解系统设计的需求：功能性需求和⾮功能性需求。
移动端静态网页制作
为了避免⾃⼰曲解题⽬所想要解决的问题，你可以先简要地给⾯试官说说⾃⼰的理解，
为啥要询问清楚系统的功能性需求也就是说系统包含哪些功能呢？
毕竟，如果⾯试官冷不丁地直接让你设计⼀个微博系统，你不可能把微博系统涵盖的功能⽐如推荐信息流、会员机制等⼀个⼀个都列举出来，然后再去设计吧！你需要筛选出系统所提供的核⼼功能（缩⼩边界范围）！
为啥要询问清楚系统的⾮功能性需求或者说约束条件⽐如系统需要达到多少QPS呢？
让你设计⼀个1w⼈⽤的微博系统和100w⼈⽤的微博系统能⼀样么？不同的约束系统对应的系统设计⽅案肯定是不⼀样的。
Step2：对系统进⾏抽象设计
我们需要在⼀个 High Level 的层⾯对系统进⾏设计。
你可以画出系统的抽象架构图，这个抽象架构图中包含了系统的⼀些组件以及这些组件之间的连接。
Step3：考虑系统⽬前需要优化的点
对系统进⾏抽象设计之后，你需要思考当前抽象的系统设计有哪些需要优化的点，⽐如说：
1. 当前系统部署在⼀台机器够吗？是否需要部署在多台机器然后进⾏负载均衡呢？
2. 数据库处理速度能否⽀撑业务需求？是否需要给指定字段加索引？是否需要读写分离？是否需要缓存？
3. 数据量是否⼤到需要分库分表？
4. 是否存在安全隐患？
5. 系统是否需要分布式⽂件系统？
6. …
Step4：优化你的系统抽象设计
根据 Step 3 中的“系统需要优化的点” 对系统的抽象设计做进⼀步完善。
系统设计该如何准备？
知识储备
系统设计⾯试⾮常考察你的知识储备，系统设计能⼒的提⾼需要⼤量的理论知识储备。⽐如说你要知道⼤型⽹站架构设计必备的三板斧：
1.⾼性能架构设计： 熟悉系统常见性能优化⼿段⽐如引⼊ 读写分离、缓存、负载均衡、异步等等。
2.⾼可⽤架构设计 ：CAP理论和BASE理论、通过集来提⾼系统整体稳定性、超时和重试机制、应对接⼝级故障：降级、熔断、限流、排队。
3. ⾼扩展架构设计 ：说⽩了就是懂得如何拆分系统。你按照不同的思路来拆分软件系统，就会得到不同的架构。
实战
虽然懂得了理论，但是⾃⼰没有进⾏实践的话，很多东西是⽆法体会到的！
因此，你还要不断通过实战项⽬锻炼⾃⼰的系统设计能⼒。
保持好奇⼼
多思考⾃⼰经常浏览的⽹站是怎么做的。⽐如：
你刷微博的时候可以思考⼀下微博是如何记录点赞数量的？
你看哔哩哔哩的时候可以思考⼀下消息提醒系统是如何做的？
你使⽤短链系统的时候可以考虑⼀下短链系统是如何做的？
…
技术选型
实现同样的功能，⼀般会有多种技术选择⽅案，⽐如缓存⽤Redis 还是Memcached、⽹关⽤ Spring Cloud Gateway还是Netflix Zuul2 。 很多时候，⾯试官在系统设计⾯过程中会具体到技术的选型，因⽽，你需要区分不同技术的优缺点。
系统设计⾯试必知
系统设计的时候必然离不开描述性能相关的指标⽐如 QPS。
性能相关的指标
响应时间
响应时间RT(Response-time)就是⽤户发出请求到⽤户收到系统处理结果所需要的时间。
RT是⼀个⾮常重要且直观的指标，RT数值⼤⼩直接反应了系统处理⽤户请求速度的快慢。
并发数
并发数可以简单理解为系统能够同时供多少⼈访问使⽤也就是说系统同时能处理的请求数量。
并发数反应了系统的负载能⼒。
QPS 和 TPS
QPS（Query Per Second） ：服务器每秒可以执⾏的查询次数；
TPS（Transaction Per Second） ：服务器每秒处理的事务数（这⾥的⼀个事务可以理解为客户发出请求到收到服务器的过程）；
书中是这样描述 QPS 和 TPS 的区别的。
QPS vs TPS：QPS 基本类似于
TPS，但是不同的是，对于⼀个页⾯的⼀次访问，形成⼀个TPS；但⼀次页⾯请求，可能产⽣多次对服务器的请求，服务器对这些请求，就可计⼊“QPS”之中。如，访问⼀个页⾯会请求服务器2次，⼀次访问，产⽣⼀个“T”，产⽣2个“Q”。
吞吐量
吞吐量指的是系统单位时间内系统处理的请求数量。
⼀个系统的吞吐量与请求对系统的资源消耗等紧密关联。请求对系统资源消耗越多，系统吞吐能⼒越低，反之则越⾼。
TPS、 QPS都是吞吐量的常⽤量化指标。
QPS（TPS） = 并发数/平均响应时间(RT)
并发数 = QPS * 平均响应时间(RT)
系统活跃度
介绍⼏个描述系统活跃度的常见名词，建议牢牢记住。你不光会在回答系统设计⾯试题的时候碰到，⽇常⼯作中你也会经常碰到这些名词。PV(Page View)
访问量, 即页⾯浏览量或点击量，衡量⽹站⽤户访问的⽹页数量；在⼀定统计周期内⽤户每打开或刷新⼀个页⾯就记录1次，多次打开或刷新同⼀页⾯则浏览量累计。UV 从⽹页打开的数量/刷新的次数的⾓度来统计的。
UV(Unique Visitor)
独⽴访客，统计1天内访问某站点的⽤户数。1天内相同访客多次访问⽹站，只计算为1个独⽴访客。UV 是从⽤户个体的⾓度来统计的。DAU(Daily Active User)
⽇活跃⽤户数量。
MAU(monthly active users)
⽉活跃⽤户⼈数。
举例：某⽹站 DAU为 1200w， ⽤户⽇均使⽤时长 1 ⼩时，RT为0.5s，求并发量和QPS。
平均并发量 = DAU（1200w）* ⽇均使⽤时长（1 ⼩时，3600秒） /⼀天的秒数（86400）=1200w/24 = 50w
真实并发量（考虑到某些时间段使⽤⼈数⽐较少） = DAU（1200w）* ⽇均使⽤时长（1 ⼩时，3600秒） /⼀天的秒数-访问量⽐较⼩的时间段假设为8⼩时（57600）=1200w/16 = 75w
峰值并发量 = 平均并发量 * 6 = 300w
QPS = 真实并发量/RT = 75W/0.5=100w/s
常⽤性能测试⼯具
后端常⽤
android studio基础教程
既然系统设计涉及到系统性能⽅⾯的问题，那在⾯试的时候，⾯试官就很可能会问：你是如何进⾏性能测试的？
推荐 4 个⽐较常⽤的性能测试⼯具：
1. Jmeter：Apache JMeter 是 JAVA 开发的性能测试⼯具。
2. LoadRunner：⼀款商业的性能测试⼯具。
3. Galtling：⼀款基于Scala 开发的⾼性能服务器性能测试⼯具。
4. ab：全称为 Apache Bench 。Apache 旗下的⼀款测试⼯具，⾮常实⽤。
没记错的话，除了 LoadRunner 其他⼏款性能测试⼯具都是开源免费的。
前端常⽤
1. Fiddler：抓包⼯具，它可以修改请求的数据，甚⾄可以修改服务器返回的数据，功能⾮常强⼤，是Web 调试的利器。
2. HttpWatch: 可⽤于录制HTTP请求信息的⼯具。
常见软件的QPS
这⾥给出的 QPS 仅供参考，实际项⽬需要进⾏压测来计算。
Nginx ：⼀般情况下，系统的性能瓶颈基本不会是 Nginx。单机 Nginx 可以达到 30w +。
Redis: Redis 官⽅的性能测试报告：redis.io/topics/benchmarks 。从报告中，我们可以得出 Redis 的单机 QPS 可以达到 8w+（CPU性能有关系，也和执⾏的命令也有关系⽐如执⾏ SET 命令甚⾄可以达到10w+QPS）。
MySQL: MySQL 单机的 QPS 为 ⼤概在 4k 左右。
Tomcat ：单机 Tomcat 的QPS 在 2w左右。这个和你的 Tomcat 配置有很⼤关系，举个例⼦Tomcat ⽀持的连接器有 NIO、NIO.2和 APR。 AprEndpoint 是通过 JNI 调⽤ APR 本地库⽽实现⾮阻塞 I/O 的，性能更好，Tomcat 配置 APR 为 连接器的话，QPS 可以达到 3w左右。更多相关内容可以⾃⾏搜索 Tomcat 性能优化。
系统设计原则
合适优于先进 > 演化优于⼀步到位 > 简单优于复杂
常见的性能优化策略
性能优化之前我们需要对请求经历的各个环节进⾏分析，排查出可能出现性能瓶颈的地⽅，定位问题。
mysql面试题sql优化下⾯是⼀些性能优化时，我经常拿来⾃问的⼀些问题：
1. 当前系统的SQL语句是否存在问题？
2. 当前系统是否需要升级硬件？
3. 系统是否需要缓存？
4. 系统架构本⾝是不是就有问题？
5. 系统是否存在死锁的地⽅？
6. 数据库索引使⽤是否合理？
7. 系统是否存在内存泄漏？（Java 的⾃动回收内存虽然很⽅便，但是，有时候代码写的不好真的会造成内存泄漏）
8. 系统的耗时操作进⾏了异步处理？
9. ……
性能优化必知法则
网页制作代码模版SQL优化，JVM、DB，Tomcat参数调优 > 硬件性能优化（内存升级、CPU核⼼数增加、机械硬盘—>固态硬盘等等）> 业务逻辑优化/缓存 > 读写分离、集等 > 分库分表
系统设计⾯试的注意事项
1.想好再说
没必要⾯试官刚问了问题之后，你没准备好就开始回答。这样不会给⾯试官带来好印象的！系统设计本就需要⾯试者结合⾃⼰的以往的经验进⾏思考，这个过程是需要花费⼀些时间的。
2.没有绝对的答案
系统设计没有标准答案。重要的是你和⾯试官⼀起交流的过程。
⼀般情况下，你会在和⾯试官的交流过程中，⼀步⼀步完成系统设计。这个过程中，你会在⾯试官的引导下不断完善⾃⼰的系统设计⽅案。因此，你不必要在系统设计⾯试之前很多题⽬，然后只是单纯记住他们的答案。
3.勿要绝对
php个人简历信息代码
系统设计没有最好的设计⽅案，只有最合适的设计⽅案。这就类⽐架构设计了：软件开发没有银弹，架构设计的⽬的就是选择合适的解决⽅案。 何为银弹？ 狼⼈传说中，只有银弹(银质⼦弹)才能制服这些猛兽。对应到软件开发活动中，银弹特指开发者们寻求的⼀种克服软件开发这个难缠的猛兽的“ ”。
4.权衡利弊
知道使⽤某个技术可能会为系统带来的利弊。⽐如使⽤消息队列的好处是解耦和削峰，但是，同样也让系统可⽤性降低、复杂性提⾼，同时还会存在⼀致性问题（消息丢失或者消息未被消费咋办）。
5.慢慢优化
刚开始设计的系统不需要太完美，可以慢慢优化。
6.不追新技术
使⽤稳定的、适合业务的技术，不必要过于追求新技术。
7.追简避杂
系统设计应当追求简单避免复杂。KISS（ Keep It Simple, Stupid）原则——保持简单，易于理解。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。