如何准备System Design的面试

开发一个应用并非一件难事，可是对应用的总体架构有一个深刻的了解确实是一件了不得的事。通常，系统设计面试题都会放在最后来考察 candidata 的更高 level 的水平。

系统设计可让面试官更充分的了解 candidata 的全方面的水平。涉及到操做系统、网络、模块化、设计模式、分布式等等系列的问题。面试官只要抓住一点感兴趣的点，就能够很快的了解 candidata 在这个领域的了解和深度。

一、首先，系统设计面试考你什么？

答：考你对问题的分析，trade off，考你对一项技术的了解程度。

二、怎么样回答才比较好？

答：最理想的状况是——基本题目给出来，你就可以知道这个系统的大概结构会是怎么样的，全部的考点分布在哪里。

三、如何去作才能达到回答得比较好的状况？

答：你得看过这些结构而且知道它全部的 tradeoff，知道它用到的全部技术等等，现场凭借经验想是只有大牛才能作的活。咱们通常人仍是老老实实的学习现有的系统吧。

四、如何知道考点在哪里？

答：想一想若是你是面试官你会问什么？在看其余人设计的结构的时候带着问题去看，设想哪里你能够提出什么样的问题，这样慢慢的你就会有体会了。
例如：系统设计要用到 message queue，大半会提到 kafka。这个时候你得知道面试官会问 kafka 什么？他八成会问到用 kafka 有什么问题。那么有什么问题呢？ kafka 只保证了 at least one time delivery。因此你最好给每一个 message 加 sequence number 来防止 duplictes（是的我知道 kafka 后来 promise 了 exact one time delivery 的 feature，不过没人用）

相似这样，你得在面试官问出来以前就知道问题是啥。这是能够作的到的。只要你老是带着问题去看。

通常系统设计面试题的解法分为四个步骤：

Step1：

明确需求和规范。这个是最重要的，确保你的目标清晰明确，保证接下来的任务可以分解和实施，可以确保实现你的目标。

Step2：

描绘出高层次的设计。在这个阶段还没必要去仔细描绘具体的实施细节。只须要将几个大的模块给肯定好，规划出他们之间的交互就能够了。

Step3：

评估和计算。针对不一样用户数量级别，不一样性能需求的条件，来肯定后面的机器硬件配置及数量等支撑条件。

其中，系统设计有主要的三个话题：分别是 交互、存储和 CAP 均衡。

交互：即网络交互，是采用可靠但慢的 TCP，仍是采用不可靠可是快速的 UDP。HTTP 是在应用层，而且基于 TCP 协议。

存储：设计到关系型数据库，内存数据库和分布式数据库等等概念。不少问题也不仅是只能依靠某一个数据可来解决的。只要设计合理，能够知足条件就行。

CAP均衡：根据 CAP 定理，在 consistency，availability 和 partition tolerance 上只能达到一张 trade off。那么，看什么，或者说学习什么会让你知道考点在哪里呢？我以前跟着 Justin 老师学了 SDE 的课程，这套课程学完后，SDE 上岸须要掌握的题型基本均可以刷通关。

如何作呢？下面举一个例子来详细的说一下：好比说如今要设计一个 hash

第一步和第二步：

我要首先问问 requirement：

我：多少资料须要进 cache？面试官：30TB

我：expected QPS？面试官：10M

我：eviction strategy？面试官：LRU

我：Access pattern？面试官：Write Back（有空的话 Write through，Write around、write back 都要知道什么意思，利弊等等）

我：Latency 重要吗？面试官：cache的用途就是下降 latency

我：C or A：A（什么是 CAP？）

第三步：

须要我本身手动简单计算一些问题。须要多少台机器，大概须要用什么，storage （并非说多么精确，可是也不要离谱）

下面是计算流程：

假设咱们如今要用 72GB RAM 4 core 的 machine

那总共以存储 data 来讲须要 30TB/72GB = 420台

这样的话每台的 QPS = 10M/420 = 23000，即便全部 core 都用了，每一个 core 要处理 6000QPS

表明说 1/6000 = 167 us 搭配上面那个 Link 可知道即便是 ram sequentially read 1MB 要 250M，因此咱们若是用这个 size 的 machine 会没法负荷

改变主意 假设如今用 16GB RAM 4 core 的 machine

30TB/16GB = 1875 台，QPS per CPU = 10M/1875/4 = 1400 QPS = 700 us per queries。这个数字负担小多了。

总结一下，上面的流程大概是：

先用 data constrain 算出要几台机器->再用 traffic constrain 算看看这样的配置合不合理->这样作完你就知道你的 system 是须要猛一点的机器少台一点仍是差一点的机器多台一点。

第四步：

画出大致架构

见 Notes for Harvard CS75 Web Development Lecture 9 Scalability（解答系统设计中的 scale 的问题）述

第五步：

scale：

这时候小 system 画完了，若是要 scale 的话须要什么东西，不外乎就是 load balancer，DB 就是可能要 master-slave 或是 multi-master 这种东西

至于怎么 fault tolerance 呢？常见的处理就是 replication，就是同样的资料存不少地方，假设有 P 个 replication。

由于每次写和读都写进/读出这 P 个地方很是花时间，那咱们该怎么办呢？

假设写的时候，只要有 W 个 replication confirm update 我就 return to user

假设读的时候，只要有 R 个 replication 给我一个同样的 value，我就 return 这个 value 给 user

depends on design 的 use case（这就是为何 use case 很重要的缘由）你要看 read 跟write 哪个 operation 能够承受高一些的 latency

若是要求 read 很快 write 能够慢一点不要紧，那就能够设 R=1，W=P，反之能够设 R=P，W=1

总之，只要 R+W > N 那这 database 就是 strong consistent！若是真的要求高速度的话就必须牺牲 consistent，那 R+W 就会 < P（weak consistent）

最重要的并且并无多少人提到的，请看各个大公司的 engineer blog，是很是很是重要的。

那么为何要看 blog？

blog 提到的系统就是如今在生产环境的系统

blog 会提到各类 tradeoff 以及作这种设计的缘由

好的 blog 会给出各类相详细的细节，甚至源代码（固然你不须要阅读源码这么深刻）

blog 提到的系统很容易拿来触类旁通

举例：[https://eng.uber.com/cherami/]

请仔细阅读这一篇文章。若是读懂了而且在读的过程当中不停的问本身考点，那么这一篇文章能够解决不下10个不一样的 system design 问题：如何设计一个 job queue？如何保证 job 必定执行？deadleatter 如何去设计（uber blog 里还有单独一篇讲这个），如何设计一个分布式爬虫？等等问题

那么哪里有好的 blog？

uber、airbnb 的我都看得不少。我时间少，你能够把大公司得都看了。

深刻看了 10 来篇高质量得就以为融会贯通了。

但愿能对你们有所帮助。

---

文章篇幅有限，若是你们但愿更加深刻的了解，欢迎你们加个人微信号 L13509543893，注明来意+简历便可。