1、常見的三種數據的集群存儲模式 1. full mirror：全量鏡像模式，單純備份模式，各個節點數據相同，都包含了全量數據，僅主節點可寫，保證了數據冗餘和讀的負載均衡。數據安全性高，橫向擴展能力差，資源利用率不高。 2. pure sharding：數據分片，每個節點的數據不相同，所有節點中數據 ...
1、常見的三種數據的集群存儲模式
full-mirror：全量鏡像模式，單純備份模式，各個節點數據相同，都包含了全量數據，僅主節點可寫，保證了數據冗餘和讀的負載均衡。數據安全性高，橫向擴展能力差，資源利用率不高。
pure-sharding：數據分片，每個節點的數據不相同，所有節點中數據的並集就是全量數據。橫向擴展能力強，資源利用率高，但是數據安全性低。
mirrored-sharding：結合兩種模式的優點，既滿足高數據安全性要求，又能實現規模的橫向擴展。
2、Redis集群的必要性和分類
必要性：單實例服務存在單點故障，集群模式能提高服務的整體可用性。
分類：
主從複製（Replication）：數據在主從間全量鏡像，僅主節點可寫，所有節點都可讀，但仍不具備橫向擴展能力。
靜態主從：在啟動服務時，在配置文件中指定，給slave指定其從屬的master，可以實現數據的備份和讀操作的負載均衡，但是缺乏對master實例的高可用保障。
redis-server --port 6380 slavaof 127.0.0.1 6379 //將6379配置為本實例的master
還可以在服務運行過程中通過客戶端命令手動改變實例的角色：
redis > slaveof 127.0.0.1 6381 //將本實例的master改為6381
redis > slaveof no one //將本實例從主從結構中獨立出來，但會保留之前的數據
利用哨兵（Sentinel ）實現高可用：每個服務實例都啟動一個哨兵守護進程，負責集群中節點狀態的監控和主節點的選舉，此時主節點也就實現了高可用。哨兵可以單實例管理單集群，也可以單實例管理多集群，還可以組成無中心哨兵集群，哨兵集群內部使用paxos理論進行協調管理。
分散式集群（Cluster）：
twemproxy：twitter開發的一個針對key提供路由功能的代理曾，代理層上方時客戶端，下方是多個Redis服務實例，形成分片集群，客戶端針對key的讀寫操作都必須經過代理層路由到分片集群中指定的服務實例上（key的hashcode對節點數量取模），這就實現了集群的橫向擴展。
- 缺點：
- 存在數據傾斜問題，一旦發生傾斜將不能成分利用集群資源，消除傾斜需要額外設計演算法，耗時耗力。
- 代理層存在單點缺陷。
- 節點數量變動後必須對歷史數據全量再分發。
官方集群方案（3.x後）：將整個集群劃分為16384個邏輯slot，每個服務實例集群構成master-slave分片，各分片各自來認領一批邏輯slot。所有的key都會被路由到某個邏輯slot上，計算公式為【slot_num = crc16(key) % 16384】，式中crc16函數是16位迴圈冗餘校驗和函數。
當需要橫向擴容時，舊節點讓出一部分slot給新節點，這部分數據也隨slot遷移到新節點上，這就避免了全量數據的重分發。
當發生數據傾斜時可以手動瓜分較重節點上的slot，實現數據的分攤，從而解決了傾斜問題。
- 每個分片都是一個master-slave結構，保證本分片內的高可用（當前模式將sentinel進程融合到了server進程中，方便分片內節點的狀態和角色管理）。
- 每個分片的主節點都具有slot計算能力，當某個主節點接收到一個key的添加時，都會計算其應該歸屬的slot，如果恰好命中本分片，就存儲數據，如果未命中則會告訴客戶端讓其重新計算。讀數據時，分片主節點會計算key的slot，如果恰好命中則返回value，如果未命中則會返給正確的存儲節點位置。
部署時至少要啟動6各節點，三個分片，每個分片內一主一從。
3、Redis主從複製（哨兵模式）
- 一個Redis主服務擁有多個副本服務，形成master-slave結構。
- 只要網路正常，master會一直將自己的數據更新同步給slave，保持主從數據一致。
- 只有master能接收寫命令，master和slave都可以接收讀命令，實現讀操作的負載均衡。
