集群 節點 一致性hash 哈希槽 異步復制 網絡分區
Redis的集群方案
- redis cluster集群方案；
- master/slave主從方案；
- 哨兵模式來進行主從替換以及故障恢復。
Redis Sentinal著眼于高可用，在master宕機時會自動將slave提升為master，繼續提供服務。
Redis Cluster著眼于擴展性，在單個redis內存不足時，使用Cluster進行分片存儲。
Redis Cluster實現了分布式且允許單點故障，沒有中心節點，各節點地位一致，具有線性可伸縮的功能。節點之間通過二進制協議進行通信，節點與客戶端之間通過ascii協議進行通信。
集群介紹
Redis集群從3.0版本開始。集群不支持同時處理多個keys的命令，因為這需要在不同的節點間移動數據，會嚴重影響性能，在高負載的情況下可能會導致錯誤。
Redis集群通過節點提供一定程度的可用性，在實際環境中當某個節點宕機或者不可達的情況下繼續處理命令。
集群的優勢:
- 自動分割數據到不同的節點上。
- 集群的部分節點失敗或者不可達的時候能夠繼續處理命令。
集群的數據分片
Redis集群沒有使用一致性hash，而是使用16384個哈希槽。每個key通過CRC16校驗后對16384取模來決定放到哪個槽。集群的每個節點負責一部分hash槽。
這種結構很容易添加或者刪除節點。從一個節點將哈希槽移動到另一個節點并不會停止服務，所以改變某個節點的哈希槽的數量不會造成集群不可用。
集群的主從復制模型
為了在部分節點失敗或者大部分節點無法通信的情況下，集群仍然可用。集群使用了主從復制模型，每個節點會有多個復制品。
一致性保證
Redis集群不能保證數據的強一致性。在特定條件下可能會丟失寫操作。
- 第一個原因是，集群是異步復制。
例如寫操作過程:
客戶端向主節點B寫入一條命令。
主節點B向客戶端回復命令狀態。
主節點將寫操作復制給從節點 B1, B2 和 B3。
主節點對命令的復制工作發生在返回命令回復之后，因為如果每次處理命令請求都需要等待復制操作完成的話，那么主節點處理命令請求的速度將極大地降低 —— 必須在性能和一致性之間做出權衡。 注意：Redis 集群可能會在將來提供同步寫的方法。
- 另一個原因是，集群出現網絡分區導致丟失命令， 并且一個客戶端與至少包括一個主節點在內的少數實例被孤立。
舉個例子：假設集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六個節點，還有一個客戶端 Z1 。假設集群中發生網絡分區，那么集群可能會分為兩方，大部分的一方包含節點 A 、C 、A1 、B1 和 C1 ，小部分的一方則包含節點 B 和客戶端 Z1。
Z1仍然能夠向主節點B中寫入, 如果網絡分區發生時間較短,那么集群將會繼續正常運作,如果分區的時間足夠讓大部分的一方將B1選舉為新的master，那么Z1寫入B中得數據便丟失了。
注意，在網絡分區出現期間， 客戶端 Z1 可以向主節點 B 發送寫命令的最大時間是有限制的，這一時間限制稱為節點超時時間（node timeout）。
