共计 3073 个字符，预计需要花费 8 分钟才能阅读完成。
开发一个利用并不是一件难事，然而对利用的整体架构有一个深刻的理解的确是一件了不起的事。个别，零碎设计面试题都会放在最初来考查 candidata 的更高 level 的程度。
零碎设计能够让面试官更充沛的理解 candidata 的全方面的程度。波及到操作系统、网络、模块化、设计模式、分布式等等系列的问题。面试官只有抓住一点感兴趣的点，就能够很快的理解 candidata 在这个畛域的理解和深度。
1、首先，零碎设计面试考你什么？
答：考你对问题的剖析，trade off，考你对一项技术的理解水平。
2、怎么样答复才比拟好？
答：最现实的状况是——根本题目给进去，你就可能晓得这个零碎的大略构造会是怎么样的，所有的考点散布在哪里。
3、如何去做能力达到答复得比拟好的状况？
答：你得看过这些构造并且晓得它所有的 tradeoff，晓得它用到的所有技术等等，现场凭借教训想是只有大牛能力做的活。咱们个别人还是老老实实的学习现有的零碎吧。
4、如何晓得考点在哪里？
答：想想如果你是面试官你会问什么？在看其他人设计的构造的时候带着问题去看，构想哪里你能够提出什么样的问题，这样缓缓的你就会有领会了。
例如：零碎设计要用到 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，注明来意 + 简历即可。
