我们将步骤总结成了以下 4 步。
[](
)Step1:问清楚系统具体要求
当面试官给出了系统设计题目之后，一定不要立即开始设计解决方案。 你需要先理解系统设计的需求：功能性需求和非功能性需求。
为了避免自己曲解题目所想要解决的问题，你可以先简要地给面试官说说自己的理解，
为啥要询问清楚系统的功能性需求也就是说系统包含哪些功能呢？
毕竟，如果面试官冷不丁地直接让你设计一个微博系统，你不可能把微博系统涵盖的功能比如推荐信息流、会员机制等一个一个都列举出来，然后再去设计吧！你需要筛选出系统所提供的核心功能（缩小边界范围）！
为啥要询问清楚系统的非功能性需求或者说约束条件比如系统需要达到多少QPS呢？
让你设计一个1w人用的微博系统和100w人用的微博系统能一样么？不同的约束系统对应的系统设计方案肯定是不一样的。
[](
)Step2:对系统进行抽象设计
我们需要在一个 High Level 的层面对系统进行设计。
你可以画出系统的抽象架构图，这个抽象架构图中包含了系统的一些组件以及这些组件之间的连接。
[](
)Step3:考虑系统目前需要优化的点
对系统进行抽象设计之后，你需要思考当前抽象的系统设计有哪些需要优化的点，比如说：
-
当前系统部署在一台机器够吗？是否需要部署在多台机器然后进行负载均衡呢？
-
数据库处理速度能否支撑业务需求？是否需要给指定字段加索引？是否需要读写分离？是否需要缓存？
-
数据量是否大到需要分库分表？
-
是否存在安全隐患？
-
系统是否需要分布式文件系统？
-
…
[](
)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
[](
)常用性能测试工具
后端常用
既然系统设计涉及到系统性能方面的问题，那在面试的时候，面试官就很可能会问：你是如何进行性能测试的？
推荐 4 个比较常用的性能测试工具：
-
Jmeter：Apache JMeter 是 JAVA 开发的性能测试工具。
-
LoadRunner：一款商业的性能测试工具。
-
Galtling：一款基于Scala 开发的高性能服务器性能测试工具。
-
ab：全称为 Apache Bench 。Apache 旗下的一款测试工具，非常实用。
没记错的话，除了 LoadRunner 其他几款性能测试工具都是开源免费的。
前端常用
-
Fiddler：抓包工具，它可以修改请求的数据，甚至可以修改服务器返回的数据，功能非常强大，是Web 调试的利器。
-
HttpWatch: 可用于录制HTTP请求信息的工具。
[](
)常见软件的QPS
这里给出的 QPS 仅供参考，实际项目需要进行压测来计算。
-
Nginx ：一般情况下，系统的性能瓶颈基本不会是 Nginx。单机 Nginx 可以达到 30w +。
-
Redis: Redis 官方的性能测试报告：https://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 性能优化。
[](
)系统设计原则
合适优于先进 > 演化优于一步到位 > 简单优于复杂
最后
在面试前我整理归纳了一些面试学习资料，文中结合我的朋友同学面试美团滴滴这类大厂的资料及案例
CodeChina开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】
由于篇幅限制，文档的详解资料太全面，细节内容太多，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！
大家看完有什么不懂的可以在下方留言讨论也可以关注。
觉得文章对你有帮助的话记得关注我点个赞支持一下！
最后
在面试前我整理归纳了一些面试学习资料，文中结合我的朋友同学面试美团滴滴这类大厂的资料及案例
CodeChina开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】
[外链图片转存中…(img-4nhwUiBK-1630670366528)]
[外链图片转存中…(img-VY2ZEdnO-1630670366529)]
由于篇幅限制，文档的详解资料太全面，细节内容太多，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！
大家看完有什么不懂的可以在下方留言讨论也可以关注。
觉得文章对你有帮助的话记得关注我点个赞支持一下！