后臺架構設計—數據存儲層
數據存儲重要性：
- 數據是企業最重要的財產；
- 數據可靠性是企業的命根，一定要保證。
單機存儲原理：
存儲引擎：存儲系統的發動機，它決定存儲系統的功能和性能；
引擎類型：哈希存儲引擎、B樹存儲引擎、LSM存儲引擎
- 哈希存儲引擎：基于哈希表結構 ：數組+鏈表；支持Create\Update\Delete\隨機Read
- B樹存儲引擎：基于B Tree實現，支持單條記錄的CURD，支持順序查找。RDBMS使用較多。
- LSM樹存儲引擎：對數據的修改增量保存在內存，達到一定條件再批量更新到磁盤；優勢在于批量寫入；劣勢在于讀取需合并磁盤和內存；
避免內存數據丟失：修改操作寫入到CommitLog日志。
數據模型：
- 文件：以目錄樹組織，如linux,mac,windows；
- 關系型：每個關系是一個表格，多行組成，每行多列；
- 鍵值(Key-Value)：Memcached, Tokey, Redis；
- 列存儲型：Casadra, Hbase;
- 圖形數據庫：Neo4J, InfoGrid, Infinite Graph
- 文檔型：MongoDB, CouchDB
事務與并發控制：
事務4個基本屬性：ACID 原子性、一致性、隔離性、持久性
并發控制：
鎖粒度：Process->DB->Table->Row
提供Read并發，Read不加鎖：寫時復制、MVCC
數據恢復：通過操作日志
多機存儲原理：
單機存儲原理在多機存儲仍然可用；多級存儲基于單機存儲；
數據分布：
分布在多個節點，節點間負載均衡；
分布方式：
靜態：取模、uid%32；
動態：一致性hash，數據飄移問題（A節點更新前出現故障，更新遷移到B節點后A節點又恢復）；
復制：
分布式存儲多個副本；保證高可靠和高可用；Commit Log。
故障檢測：
心跳機制、數據遷移、故障恢復；
FLP定理與設計：
FLP Impossiblity（FLP不可能性）:
在異步消息通信場景，即使只有一個進程失敗，沒有任何方法能保證非失敗進程達到一致性。
CAP定理與設計：
CAP：一致性（Consistency）、可用性(Availabilty)、分區容忍性(Tolerance of network Partition)。
一致性和可用性需要折中權衡
分布式存儲系統需要能夠自動容錯，也就是說分區容忍性需要保證。
2PC（Two Phase Commit）協議與設計：
用于分布式事務;
兩類節點組成：
協調者（1個）；
事務參與者（多個）；
分兩階段：
請求階段：協調者通知參與者準備提交或取消事務，所有參與者都需要表決同意或者不同意。
提交階段：
收到參與者所有決策后，協調者進行決策（提交或取消）；
通知參與者執行操作，所有參與者都同意就提交，否則取消；
參與者收到協調者的通知后執行操作。
2PC協議是阻塞式：
事務參與者可能發生故障
--設置超時時間；
協議者可能發生故障
--日志記錄、備用協調者
應用：交易訂單 等；
Paxos協議與設計：
作用：
解決節點間的一致性問題；
主節點宕掉，則選擇新節點；
主節點常以操作日志的形式同步備節點。
分兩種角色：提議者(Prpposer)、接受者(Acceptor)；
執行步驟：
批準：Proposer發送accept消息給Accepter要求接受某個提議者；
確認：超一半的Accepter接受，則提議值生效，Proposer發送acknowledge消息通知所有的Accepter提議生效。
與2PC比較：：
2PC協議保證多個數據分片上操作的原子性；
Paxos協議保證一個數據分片多個副本之間的數據一致性；
Paxos協議用法：
實現全局的鎖服務或者命名和配置服務；
---Apache Zookeeper
將用戶數據復制到多個數據中心；
---Google Megastore
數據存儲層冗余：
多個副本，實現訪問的高可用性。
如何實現：
數據復制：
基于日志；
Master-Slave：mysql\MongoDB
Replic Set:MongoDB
雙寫：
存儲層多主對等結構；比較靈活，但數據模塊層成本較高；
數據備份：
冷備份：
定期將數據復制到某個存儲介質，是傳統的數據保護手段；
優點：簡單、廉價，技術難度低；
缺點：定期存在數據不一致；恢復數據時間長；
熱備份：
online備份；提供更好的高可用性；
異步熱備份：
從主存儲寫入即返回給應用端，由存儲系統異步寫入其他副本；
同步熱備份：
多份數據副本寫入同步完成，無主從之分；
為提高性能，應用程序并發寫入；
響應延遲是最慢的那臺服務器；
數據存儲層失效轉移機制：
失效確認：是否宕機、心跳；
訪問轉移：訪問路由到非宕機機器；存儲數據完全一致；
數據恢復：主從、日志；
