如何应对系统设计的面试2

https://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview

Part 2: 三个公共主题

有三个公共主题适用于所有的系统设计题目，具体是通讯，存储和CAP；

1. 通讯

组件通讯，涉及到的通讯协议如下：

协议	工作层	特点	备注
UDP	传输层	无连接，不可靠
TCP	传输层	连接，可靠协议
HTTP	应用层	基于TCP，可靠
RPC	应用层	进程间的通讯，可基于http/tcp，为使用者屏蔽了协议细节	难以调试，公共api使用http

RPC进一步讨论：

打桩过程: 负责序列化进程标示以及参数为请求；然后通过通讯模块发送序列化之后的消息；接受请求消息时，会反序列化。

• 谷歌protobuf：只有api没有rpc实现；文档齐全。
• facebook thrift：多语言，多数据结构，文档少。

2. 存储

关系型存储

默认存储，主要因为ACID特性，这里的一致性C是指事物transaction一定会让数据库发生状态转移。不同于CAP中的一致性。

a. 减少冗余以及提高数据一致性，设计数据库需要遵循以下原则：

• 扁平化，行列交叉口只有一个数值
• 仅主键能决定所有属性
• 从键决定所有属性？

DB代理

代理解决两个问题：单点故障和海量数据存储

• clustering：去中心化，数据自动分布，移动和自平衡；节点之间互相通信；
• sharding：中心化方案，数据手动分布，不会自动迁移，节点之间不通信。

NOSQL

常规的互联网服务都是读写比例100:1，甚至1000:1；解决关系型存储的读性能问题，join操作昂贵，大量时间花费在磁盘seek；更不要说分布式join操作的网络开销了。

解决读性能的方法论：增加冗余或者数据分组；

KV存储

why KV存储？

• 降低读取热点数据的时延：O(1)读写更快的存储媒介（内存/SSD），而不是传统的O(logn)读写HD。

设计cache的三个标准

• pattern：HOW to cache，read-through/write-through/wirte-around/write-back/cache-aside
• placement: WHERE to cache，client-side/distinct-side/server-side
• replacement: WHEN to expire/replace cache，LRU/LFU/ARC

Document 存储

why？

• value是一个XML/JSON，更加灵活，迭代更快，不用每次都改KV；性能更好，读取次数少了。

Column-oriented 存储

• 嵌套map，ColumnFamily<RowKey, Columns<Name, Value, Timestamp>>
• 分布式，高可用，写优化
• Hbase，Amazon simpleDB

Graph 存储

• 实现类似关系型数据库的关系

3. CAP

• 一致性C：所有节点在同一时刻的数据相同
• 可用性A：所有请求都会得倒失败/成功的响应
• 分区容忍P：系统部分的消息丢失，仍可以正常运行

一致性保障：协议，2PC/最终一致性（vector clock + RWN）/Paxos/
可用性保证：数据副本，cold standby/warn standby/hot standby/active-active保证高可用。