redis cluster 總體架構：
1、在這個圖中，每一個redis服務器節點，它們任何兩個節點之間都是相互連通的。客戶端可以與任何一個節點相連接，然後就可以訪問集羣中的任何一個節點，對其進行存取和其他操作。
2、集羣節點屬性
集羣中每個Master node負責存儲數據、集羣狀態，包括slots與nodes對應關係。Master nodes能夠自動發現其他nodes，檢測failure節點，當某個Master節點失效時，集羣能將覈實的Slave提升爲Master。下圖是節點的關聯信息，節點定時會將這些信息發送給其他節點：
從左至右分別是：
節點ID、IP地址和端口、節點角色標誌、最後發送ping時間、最後接收到pong時間、連接狀態、節點負責處理的hash slot。
3、各節點通過Gossip進行通訊
cluster 服務端節點直接使用 gossip 協議進行節點間通信，可以自動識別出ip/port的變化，並通過Gossip（最終一致性，分佈式服務數據同步算法）協議廣播給其他節點知道。Gossip也稱“病毒感染算法”、“謠言傳播算法”。
（1）主要使用 cluster meet ,ping ,pong 三個命令來完成。
（2）通信由 meet 或 ping 命令發起。
（3）meet 命令主要用於節點間的初次通信(?待確認)。
（4）節點間的握手，類似於 tcp 的三次握手，都會確保對方知道自己已經收到消息。
（5）定時任務 clusterCron 會向隨機節點發其 ping 通信（標記下線，疑似下線，即獲知其他節點的存活情況）。
（6）在定時心跳通信時，會附帶上隨機兩個節點的信息，包括 ip,端口，以及節點所包含的槽位信息
（7）收到心跳信息的節點，會判斷附加的節點信息是否在本地記錄中，
本地無記錄，會發其 meet 通信(握手)；
本地有記錄，會進行更新(判斷 epoch)。
（8）數據結構
使用 bitmap 來表示一個節點持有的槽位信息；
集羣消息處理函數 clusterProcessPacket。
4、 Redis 集羣的數據分片
Redis 集羣沒有使用一致性hash, 而是引入了 哈希槽的概念.
Redis 集羣有16384個哈希槽,每個key通過CRC16校驗後對16384取模來決定放置哪個槽.集羣的每個節點負責一部分hash槽,舉個例子,比如當前集羣有3個節點,那麼:
- 節點 A 包含 0 到 5500號哈希槽.
- 節點 B 包含5501 到 11000 號哈希槽.
- 節點 C 包含11001 到 16384號哈希槽.
這種結構很容易添加或者刪除節點. 比如如果我想新添加個節點D, 我需要從節點 A, B, C中得部分槽到D上. 如果我想移除節點A,需要將A中的槽移到B和C節點上,然後將沒有任何槽的A節點從集羣中移除即可. 由於從一個節點將哈希槽移動到另一個節點並不會停止服務,所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集羣不可用的狀態。
下面對redis cluster原理進行深入講解。