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保證高可用。