概述
在上一篇文中分析下Redis四種模式，分析這四種模式工作特點以及侷限性，那麼在Redis集羣中是如何實現分片以及選舉呢？下面就來揭開這層面紗。
Redis集羣定義
redis集羣是一個由多個主從節點羣組成的分佈式服務器羣，它具有複製、高可用和分片特性。如圖所示 
集羣分片模式意義與價值
假設Redis只用複製功能做主從，那麼當數據量巨大的情況下，單機情況下可能已經承受不下一份數據，更不用說是主從都要各自保存一份完整的數據。在這種情況下，數據分片是一個非常好的解決辦法。
Redis的Cluster正是用於解決該問題。它主要提供兩個功能：
- 自動對數據分片，落到各個節點上
- 即使集羣部分節點失效或者連接不上，依然可以繼續處理命令
對於第二點，它的功能有點類似於Sentienl的故障轉移，在這裏不細說。下面詳細瞭解下Redis的槽位分片原理，在此之前，先了解下分佈式簡單哈希算法和一致性哈希算法，以幫助理解槽位的作用。
簡單哈希算法
假設我們現在有三臺機，數據落在哪臺機的算法爲:
c= Hash(key) % 3
假設key A的hash值爲4，則 4%3 =1， 則數據散落在第二臺機上，key B的hash值爲11，則 11%3=2，則數據散落在第三臺機上,利用此法以此類推，利用這樣的算法，假設現在數據量太大了，需要增加一臺機器。A原本落在第二臺上，現在根據算法4%4=0，落到了第一臺機器上了，但是第一臺機器上根本沒有A的值。這樣的算法會導致增加機器或減少機器的時候，引起大量的緩存擊穿，造成雪崩。
緩存擊穿、雪崩及穿透
緩存擊穿：查詢的數據在數據庫中是存在，但是緩存中熱點數據key恰巧失效，所有請求直接懟到數據庫導致數據庫連接等待甚至宕機。
加鎖，雙緩存[A,B]{A 緩存的key需要設置過期時間，而B緩存的key永不失效}】JUC （讀寫鎖）
保證一致性： 在更新數據到數據庫之後刪除緩存在重新寫入緩存。
緩存雪崩：查詢的時候大面積的key集體失效導致請求直接到了數據庫。（隨機範圍設置過期時間）
緩存穿透：查詢的數據在數據庫中不存在，也就意味沒有命中緩存中key，導致請求全部到數據操作。（布隆過濾器，緩存空數據）
一致性哈希算法
在一致性哈希算法中，整個哈希空間是一個虛擬圓環，如圖所示 
假設我們有四個節點Node A、B 、C 、D，經過IP地址的哈希運算，它們位置如下分佈：
有4個存儲對象Object A、B、C、D，經過對Key的哈希計算後，它們的位置如下
對於各個Object，它所真正的存儲位置是按順時針找到的第一個存儲節點。例如Object A順時針找到的第一個節點是Node A，所以Node A負責存儲Object A，Object B存儲在Node B，以此類推，一致性哈希算法大概如此。
容錯性以及擴展性
假設Node C節點掛掉了，Object C的存儲丟失，那麼它順時針找到的最新節點是Node D。也就是說Node C掛掉了，受影響僅僅包括Node B到Node C區間的數據，並且這些數據會轉移到Node D進行存儲。如圖所示 
同理，假設現在數據量大了，需要增加一臺節點Node X。Node X的位置在Node B到Node C直接，那麼受到影響的僅僅是Node B到Node X間的數據，它們要重新落到Node X上。所以一致性哈希算法對於容錯性和擴展性有非常好的支持。
數據傾斜
一致性哈希算法也有一個嚴重的問題，就是數據傾斜。即如果在分片的集羣中，節點太少，並且分佈不均，一致性哈希算法就會出現部分節點數據太多，部分節點數據太少。也就是說無法控制節點存儲數據的分配。如下圖，大部分數據都在A上了，B的數據比較少。 
哈希槽
Redis集羣（Cluster）並沒有選用上面一致性哈希，而是採用了哈希槽（SLOT）的這種概念。主要的原因就是上面所說的，一致性哈希算法對於數據分佈、節點位置的控制並不是很友好。
哈希槽概念
-
哈希算法
Redis Cluster的hash算法不是簡單的hash()，而是crc16算法，一種校驗算法。
-
槽位
空間分配的規則。其實哈希槽的本質和一致性哈希算法非常相似，不同點就是對於哈希空間的定義。一致性哈希的空間是一個圓環，節點分佈是基於圓環的，無法很好的控制數據分佈。而Redis Cluster的槽位空間是自定義分配的，類似於Windows盤分區的概念。這種分區是可以自定義大小，自定義位置的。
Redis Cluster包含了16384個哈希槽，每個Key通過計算後都會落在具體一個槽位上，而這個槽位是屬於哪個存儲節點的，則由用戶自己定義分配。例如機器硬盤小的，可以分配少一點槽位，硬盤大的可以分配多一點。如果節點硬盤都差不多則可以平均分配。所以哈希槽這種概念很好地解決了一致性哈希的弊端。
另外在容錯性和擴展性上，表象與一致性哈希一樣，都是對受影響的數據進行轉移。而哈希槽本質上是對槽位的轉移，把故障節點負責的槽位轉移到其他正常的節點上。擴展節點也是一樣，把其他節點上的槽位轉移到新的節點上。
對於槽位的轉移和分派，Redis集羣是不會自動進行的，而是需要人工配置的。所以Redis集羣的高可用是依賴於節點的主從複製與主從間的自動故障轉移。
跳轉重定位
當客戶端向一個錯誤的節點發出了指令，該節點會發現指令的 key 所在的槽位並不歸自己管理，這時它會向客戶端發送一個特殊的跳轉指令攜帶目標操作的節點地址，告訴客戶端去連這個節點去獲取數據。客戶端收到指令後除了跳轉到正確的節點上去操作，還會同步更新糾正本地的槽位映射表緩存，後續所有 key 將使用新的槽位映射表。
Redis集羣選舉原理
瞭解redis集羣選舉原理之前,那就是Redis集羣各節點之前的通訊協議：Gossip協議。
Gossip協議
gossip協議簡單來說各節點之間都會保持通訊，當某一個節點掛掉或者新增的時候，與它相鄰的節點就會感知到，這時候此節點就是失去鏈接或者創建鏈接。
- ping：每個節點都會頻繁給其他節點發送ping，其中包含自己的狀態還有自己維護的集羣元數據，互相通過ping交換元數據；
- pong: 返回ping和meet，包含自己的狀態和其他信息，也可以用於信息廣播和更新；
- fail: 某個節點判斷另一個節點fail之後，就發送fail給其他節點，通知其他節點，指定的節點宕機了;
- meet：某個節點發送meet給新加入的節點，讓新節點加入集羣中，然後新節點就會開始與其他節點進行通信，不需要發送形成網絡的所需的所有CLUSTER MEET命令;
集羣選舉原理分析
當slave發現自己的master變爲FAIL狀態時，便嘗試進行Failover，以期成爲新的master。由於掛掉的master可能會有多個slave，從而存在多個slave競爭成爲master節點的過程， 其過程如下：
- slave發現自己的master變爲FAIL;
- 將自己記錄的集羣currentEpoch加1，並廣播FAILOVER_AUTH_REQUEST信息;
- 其他節點收到該信息，只有master響應，判斷請求者的合法性，併發送FAILOVER_AUTH_ACK，對每一個epoch只發送一次ack.
- 嘗試failover的slave收集FAILOVER_AUTH_ACK;
- 超過半數後變成新Master;
- 廣播Pong通知其他集羣節點。
從節點並不是在主節點一進入 FAIL 狀態就馬上嘗試發起選舉，而是有一定延遲，一定的延遲確保我們等待FAIL狀態在集羣中傳播，slave如果立即嘗試選舉，其它masters或許尚未意識到FAIL狀態，可能會拒絕投票。
- 延遲計算公式：DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
- SLAVE_RANK表示此slave已經從master複製數據的總量的rank。Rank越小代表已複製的數據越新。這種方式下，持有最新數據的slave將會首先發起選舉（理論上）
上述原理過程，可以使用如下流程圖表示 
集羣選舉原理知識延伸
Redis集羣爲什麼至少需要三個master節點
因爲新master的選舉需要大於半數的集羣master節點同意才能選舉成功，如果只有兩個master節點，當其中一個掛了，是達不到選舉新master的條件的。
Redis集羣爲什麼至少推薦節點數爲奇數
奇數個master節點可以在滿足選舉該條件的基礎上節省一個節點，比如三個master節點和四個master節點的集羣相比，大家如果都掛了一個master節點都能選舉新master節點，如果都掛了兩個master節點都沒法選舉新master節點了，所以奇數的master節點更多的是從節省機器資源角度出發說的。
網絡不穩定是否會是否引起選舉
真實世界的機房網絡往往並不是風平浪靜的，它們經常會發生各種各樣的小問題。比如網絡抖動就是非常常見的一種現象，突然之間部分連接變得不可訪問，然後很快又恢復正常。
爲解決這種問題，Redis Cluster 提供了一種選項cluster-node-timeout，表示當某個節點持續 timeout 的時間失聯時，纔可以認定該節點出現故障，需要進行主從切換。如果沒有這個選項，網絡抖動會導致主從頻繁切換 (數據的重新複製)。