Redis集群模式-有解無憂

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對節點數量取模），這就實作了集群的橫向擴展，
    - 缺點：
    1. 存在資料傾斜問題，一旦發生傾斜將不能成分利用集群資源，消除傾斜需要額外設計演算法，耗時耗力，
    2. 代理層存在單點缺陷，
    3. 節點數量變動后必須對歷史資料全量再分發，
  - 官方集群方案（3.x后）：將整個集群劃分為16384個邏輯slot，每個服務實體集群構成master-slave分片，各分片各自來認領一批邏輯slot，所有的key都會被路由到某個邏輯slot上，計算公式為【slot_num = crc16(key) % 16384】，式中crc16函式是16位回圈冗余校驗和函式，（一致性hash）
    1. 當需要橫向擴容時，舊節點讓出一部分slot給新節點，這部分資料也隨slot遷移到新節點上，這就避免了全量資料的重分發，
    2. 當發生資料傾斜時可以手動瓜分較重節點上的slot，實作資料的分攤，從而解決了傾斜問題，
    3. 每個分片都是一個master-slave結構，保證本分片內的高可用（當前模式將sentinel行程融合到了server行程中，方便分片內節點的狀態和角色管理），
    4. 每個分片的主節點都具有slot計算能力，當某個主節點接收到一個key的添加時，都會計算其應該歸屬的slot，如果恰好命中本分片，就存盤資料，如果未命中則會告訴客戶端讓其重新計算，讀資料時，分片主節點會計算key的slot，如果恰好命中則回傳value，如果未命中則會返給正確的存盤節點位置，
    5. 部署時至少要啟動6各節點，三個分片，每個分片內一主一從，

3、Redis主從復制（哨兵模式）

一個Redis主服務擁有多個副本服務，形成master-slave結構，
只要網路正常，master會一直將自己的資料更新同步給slave，保持主從資料一致，
只有master能接收寫命令，master和slave都可以接收讀命令，實作讀操作的負載均衡，

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/19774.html

標籤：NoSQL

上一篇：Java 操作Redis

下一篇：Redis持久化機制