是壹種去中心化的集群架構
Redis Cluster 的性能與單節點部署是同級別的。
多主節點、負載均衡、讀寫分離
Redis Cluster 支持標準的 主從復制配置來保障高可用和高可靠。
failover （故障轉移）
Redis Cluster 也實現了壹個類似 Raft 的***識方式，來保障整個集群的可用性。
向 Redis Cluster 中添加新節點，或者移除節點，都是透明的，不需要停機。
水平、垂直方向都非常容易擴展。
數據分區，海量數據存儲
部署 Redis Cluster 不需要其他的代理或者工具，而且 Redis Cluster 和單機 Redis 幾乎完全兼
容。
角色： master、slave
Redis Cluster 由多個Redis節點組構成，是壹個P2P（point to point）無中心節點的集群架構，依靠Gossip協議傳播集群
Gossip協議是壹個通信協議，壹種傳播消息的方式。
思想啟發於：病毒傳播
這些收到信息的節點接下來會做同樣的事情，即把這些信息傳遞給其他壹些隨機選擇的節點。
信息會周期性的傳遞給N個目標節點。這個N被稱為fanout（扇出）
gossip協議包含多種消息，包括meet、ping、pong、fail、publish等等
通過gossip協議，cluster可以提供 集群間狀態同步更新 、 選舉自助failover 等重要的集群功能。
分布式架構設計中，核心問題即為如何分片數據。在技術的更替中出現過以下分布式hash算法：
redis-cluster把所有的物理節點映射到[0-16383]個slot上,基本上采用平均分配和連續分配的方式。
slot槽必須在節點上連續分配，如果出現不連續的情況，則RedisCluster不能工作。
采用 raft 協議（參照Paxos算法 /p/40c658c9dcc2 ）
當slave 收到過半的master 同意時，會成為新的master。此時會以最新的Epoch 通過PONG 消息廣播自己成為master，讓Cluster 的其他節點盡快的更新拓撲結構(node.conf)。
就是上面講的從節點選舉
人工故障切換是預期的操作，而非發生了真正的故障，目的是以壹種安全的方式(數據無丟失)將當前master節點和其中壹個slave節點(執行cluster-failover的節點)交換角色
1、向從節點發送cluster failover 命令（slaveof no one）
2、從節點告知其主節點要進行手動切換（CLUSTERMSG_TYPE_MFSTART）
3、主節點會阻塞所有客戶端命令的執行（10s）
4、從節點從主節點的ping包中獲得主節點的復制偏移量
5、從節點復制達到偏移量，發起選舉、統計選票、贏得選舉、升級為主節點並更新配置
6、切換完成後，原主節點向所有客戶端發送moved指令重定向到新的主節點
以上是在主節點在線情況下。
如果主節點下線了，則采用cluster failover force或cluster failover takeover 進行強制切換。
擴容
擴容節點數據必須為空
縮容
只能刪除數據為空的節點
我們知道在壹主壹從的情況下，如果主從同時掛了，那整個集群就掛了。
為了避免這種情況我們可以做壹主多從，但這樣成本就增加了。
Redis提供了壹種方法叫副本漂移，這種方法既能提高集群的可靠性又不用增加太多的從機。
Master1宕機，則Slaver11提升為新的Master1
集群檢測到新的Master1是單點的（無從機）
集群從擁有最多的從機的節點組（Master3）中，選擇節點名稱字母順序最小的從機（Slaver31）漂移
到單點的主從節點組(Master1)。
具體流程如下（以上圖為例）：
1、將Slaver31的從機記錄從Master3中刪除
2、將Slaver31的的主機改為Master1
3、在Master1中添加Slaver31為從節點
4、將Slaver31的復制源改為Master1
5、通過ping包將信息同步到集群的其他節點