由於redis主從，哨兵都有一些不便之處，redis就提出了叢集的概念，並真正實現了。
在redis3.0以前的版本要實現叢集一般是藉助哨兵sentinel工具來監控master節點的狀態，如果master節點異常，則會做主從切換，將某一臺slave作為master，哨兵的配置略微複雜，並且效能和高可用性等各方面表現一般，特別是在主從切換存在訪問瞬斷的情況（無法對外提供讀寫服務），而且哨兵模式只有一個主節點對外提供服務，沒法支援很高的併發，且單個主節點記憶體也不宜設定得過大，否則會導致持久化檔案過大，影響資料恢復或主從同步的效率。同時哨兵節點要儲存全量的資料，不利於橫向擴容。
叢集模式
redis叢集是一個由多個主從節點群組成的分散式伺服器群，它具有複製、高可用和分片特性。Redis叢集不需要sentinel哨兵∙也能完成節點移除和故障轉移的功能。需要將每個節點設定成叢集模式，這種叢集模式沒有中心節點，可水平擴充套件，據官方文件稱可以線性擴充套件到上萬個節點(官方推薦不超過1000個節點)。redis叢集的效能和高可用性均優於之前版本的哨兵模式，且叢集配置非常簡單。
每個節點可以看作是一個主從複製小型叢集，多個叢集構成了一個大型的叢集。不同master節點儲存的資料是不一樣的，這樣很方便進行橫向擴容。
redis叢集搭建
redis叢集需要至少三個master節點，我們這裡搭建三個master節點，並且給每個master再搭建一個slave節點，總共6個redis節點，這裡用三臺機器部署6個redis例項，每臺機器一主一從，搭建叢集的步驟如下：
第一步：在第一臺機器的/usr/local下建立資料夾redis-cluster，然後在其下面分別建立2個資料夾如下 （1）mkdir -p /usr/local/redis-cluster （2）mkdir 8001 8004 第一步：把之前的redis.conf配置檔案copy到8001下，修改如下內容： （1）daemonize yes （2）port 8001（分別對每個機器的埠號進行設定） （3）pidfile /var/run/redis_8001.pid # 把pid程序號寫入pidfile配置的檔案 （4）dir /usr/local/redis-cluster/8001/（指定資料檔案存放位置，必須要指定不同的目錄位置，不然會丟失資料） （5）cluster-enabled yes（啟動叢集模式） （6）cluster-config-file nodes-8001.conf（叢集節點資訊檔案，這裡800x最好和port對應上） （7）cluster-node-timeout 10000 (8)# bind 127.0.0.1（bind繫結的是自己機器網路卡的ip，如果有多塊網路卡可以配多個ip，代表允許客戶端透過機器的哪些網路卡ip去訪問，內網一般可以不配置bind，註釋掉即可） (9)protected-mode no （關閉保護模式） (10)appendonly yes 如果要設定密碼需要增加如下配置： (11)requirepass 密碼 (設定redis訪問密碼) (12)masterauth 密碼 (設定叢集節點間訪問密碼，跟上面一致) 第三步：把修改後的配置檔案，copy到8004，修改第2、3、4、6項裡的埠號，可以用批次替換： :%s/源字串/目的字串/g 第四步：另外兩臺機器也需要做上面幾步操作，第二臺機器用8002和8005，第三臺機器用8003和8006 第五步：分別啟動6個redis例項，然後檢查是否啟動成功 （1）/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/800*/redis.conf （2）ps -ef | grep redis 檢視是否啟動成功
上面的就是啟動這些例項節點，此時這些節點之間沒有任何的聯絡，也不是叢集，需要進行下面的操作才能構成一個叢集。
第六步：用redis-cli建立整個redis叢集(redis5以前的版本叢集是依靠ruby指令碼redis-trib.rb實現) # 下面命令裡的1代表為每個建立的主伺服器節點建立一個從伺服器節點 # 執行這條命令需要確認三臺機器之間的redis例項要能相互訪問，可以先簡單把所有機器防火牆關掉，如果不關閉防火牆則需要開啟redis服務埠和叢集節點gossip通訊埠16379(預設是在redis埠號上加1W) # 關閉防火牆 # systemctl stop firewalld # 臨時關閉防火牆 # systemctl disable firewalld # 禁止開機啟動 # 注意：下面這條建立叢集的命令大家不要直接複製，裡面的空格編碼可能有問題導致建立叢集不成功 （1）/usr/local/redis-5.0.3/src/redis-cli -a 密碼 --cluster create --cluster-replicas 1 192.168.0.61:8001 192.168.0.62:8002 192.168.0.63:8003 192.168.0.61:8004 192.168.0.62:8005 192.168.0.63:8006
--cluster create 是以叢集的方式啟動這些節點
--cluster-replicas 1 表示主節點有一個從節點。
執行之後還要進行槽位節點的分配，分配完成之後才能對外提供服務。
第七步：驗證叢集： （1）連線任意一個客戶端即可：./redis-cli -c -h -p (-a訪問服務端密碼，-c表示叢集模式，指定ip地址和埠號） 如：/usr/local/redis-5.0.3/src/redis-cli -a zhuge -c -h 192.168.0.61 -p 800* （2）進行驗證： cluster info（檢視叢集資訊）、cluster nodes（檢視節點列表） （3）進行資料操作驗證 （4）關閉叢集則需要逐個進行關閉，使用命令： /usr/local/redis-5.0.3/src/redis-cli -a zhuge -c -h 192.168.0.60 -p 800* shutdown
注意：如果正常關機了這些叢集節點，下次啟動只需要啟動這些主從節點就可以了，無序再次執行下面的命令；否則是會報錯的。下面的就是建立叢集時執行一次就可以了。
/usr/local/redis-5.0.3/src/redis-cli -a 密碼 --cluster create --cluster-replicas 1
Redis叢集原理分
Redis Cluster 將所有資料劃分為 16384 個 slots(槽位)，每個節點負責其中一部分槽位。槽位的資訊儲存於每個節點中。
當 Redis Cluster 的客戶端來連線叢集時，它也會得到一份叢集的槽位配置資訊並將其快取在客戶端本地。這樣當客戶端要查詢某個 key 時，可以直接定位到目標節點。同時因為槽位的資訊可能會存在客戶端與伺服器不一致的情況，還需要糾正機制來實現槽位資訊的校驗調整。
當進行擴容或者縮容的時候，會重新對槽位進行分配。保證資料的完整性。
擴容的時候，每次加入的節點預設都是master，加入的時候需要叢集中存活節點代入才行，否則無法加入到叢集。同時也要進行槽位的分配。
槽位定位演算法
Cluster 預設會對 key 值使用 crc16 演算法進行 hash 得到一個整數值，然後用這個整數值對 16384 進行取模來得到具體槽位。
HASH_SLOT = CRC16(key) mod 16384
跳轉重定位
當客戶端向一個錯誤的節點發出了指令，該節點會發現指令的 key 所在的槽位並不歸自己管理，這時它會向客戶端傳送一個特殊的跳轉指令攜帶目標操作的節點地址，告訴客戶端去連這個節點去獲取資料。客戶端收到指令後除了跳轉到正確的節點上去操作，還會同步更新糾正本地的槽位對映表快取，後續所有 key 將使用新的槽位對映表。因為叢集中資料都是分片儲存的，這樣很容易進行橫向的擴容。空間不夠就加機器，併發量扛不住也加機器。
Redis叢集節點間的通訊機制
redis cluster節點間採取gossip協議進行通訊
- 維護叢集的後設資料(叢集節點資訊，主從角色，節點數量，各節點共享的資料等)有兩種方式：集中式和gossip
集中式：
優點在於後設資料的更新和讀取，時效性非常好，一旦後設資料出現變更立即就會更新到集中式的儲存中，其他節點讀取的時候立即就可以立即感知到；不足在於所有的後設資料的更新壓力全部集中在一個地方，可能導致後設資料的儲存壓力。 很多中介軟體都會藉助zookeeper集中式儲存後設資料。但是這樣可能會引入第三方元件，令系統更加複雜。
gossip：
gossip協議包含多種訊息，包括ping，pong，meet，fail等等。
meet：某個節點傳送meet給新加入的節點，讓新節點加入叢集中，然後新節點就會開始與其他節點進行通訊；
ping：每個節點都會頻繁給其他節點傳送ping，其中包含自己的狀態還有自己維護的叢集後設資料，互相透過ping交換後設資料(類似自己感知到的叢集節點增加和移除，hash slot資訊等)；
pong: 對ping和meet訊息的返回，包含自己的狀態和其他資訊，也可以用於資訊廣播和更新；
fail: 某個節點判斷另一個節點fail之後，就傳送fail給其他節點，通知其他節點，指定的節點當機了。
gossip協議的優點在於後設資料的更新比較分散，不是集中在一個地方，更新請求會陸陸續續，打到所有節點上去更新，有一定的延時，降低了壓力；缺點在於後設資料更新有延時可能導致叢集的一些操作會有一些滯後。
gossip通訊的10000埠
每個節點都有一個專門用於節點間gossip通訊的埠，就是自己提供服務的埠號+10000，比如7001，那麼用於節點間通訊的就是17001埠。 每個節點每隔一段時間都會往另外幾個節點傳送ping訊息，同時其他幾點接收到ping訊息之後返回pong訊息。
Redis叢集選舉原理分析
當slave發現自己的master變為FAIL狀態時，便嘗試進行Failover，以期成為新的master。由於掛掉的master可能會有多個slave，從而存在多個slave競爭成為master節點的過程， 其過程如下：
1.slave發現自己的master變為FAIL
2.將自己記錄的叢集currentEpoch加1，並廣播FAILOVER_AUTH_REQUEST 資訊。向整個叢集進行廣播。
3.其他節點收到該資訊，只有master響應，判斷請求者的合法性，併傳送FAILOVER_AUTH_ACK，對每一個epoch只傳送一次ack。只響應最先接受到的請求。
4.嘗試failover的slave收集master返回的FAILOVER_AUTH_ACK。
5.slave收到超過半數master的ack後變成新Master(這裡解釋了叢集為什麼至少需要三個主節點，如果只有兩個，當其中一個掛了，只剩一個主節點是不能選舉成功的)
6.slave廣播Pong訊息通知其他叢集節點。
從節點並不是在主節點一進入 FAIL 狀態就馬上嘗試發起選舉，而是有一定延遲，一定的延遲確保我們等待FAIL狀態在叢集中傳播。先傳播主節點當機，後再發起選舉。
slave如果立即嘗試選舉，其它masters或許尚未意識到FAIL狀態，可能會拒絕投票。
如果從節點獲取到的票數都是一致的要如何處理呢？可以令不同的slave節點不在同一時間發起選舉，有一個延遲。延遲可以根據主從複製進度做依據，獲得資料越多的從節點越先發起請求。
•延遲計算公式：
DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
•SLAVE_RANK表示此slave已經從master複製資料的總量的rank。Rank越小代表已複製的資料越新。這種方式下，持有最新資料的slave將會首先發起選舉（理論上）。
網路抖動
真實世界的機房網路往往並不是風平浪靜的，它們經常會發生各種各樣的小問題。比如網路抖動就是非常常見的一種現象，突然之間部分連線變得不可訪問，然後很快又恢復正常。
為解決這種問題，Redis Cluster 提供了一種選項cluster-node-timeout，表示當某個節點持續 timeout 的時間失聯時，才可以認定該節點出現故障，需要進行主從切換。如果沒有這個選項，網路抖動會導致主從頻繁切換 (資料的重新複製)。
這個值不能太小，否則會頻繁發生切換，導致效率降低；也不能太大，否則會導致資料丟失。一般可以設定為5000，值為毫秒。
叢集腦裂資料丟失問題
redis叢集沒有過半機制會有腦裂問題，網路分割槽導致腦裂後多個主節點對外提供寫服務，一旦網路分割槽恢復，會將其中一個主節點變為從節點，這時會有大量資料丟失。因為變成從節點，就會將自己的資料重置，然後去master節點請求獲取資料。
規避方法可以在redis配置里加上引數(這種方法不可能百分百避免資料丟失，參考叢集leader選舉機制)：
min-slaves-to-write 1 //寫資料成功最少同步的slave數量，這個數量可以模仿大於半數機制配置，比如叢集總共三個節點可以配置1，
// 加上leader就是2，超過了半數，該引數在redis最新版本里名字已經換成了min-replicas-to-write
之前都是寫入master之後預設就寫入成功；配置這個值之後，就要至少有一個slave也同步到了資料才是寫入成功，可以極大的避免腦裂情況的發生。
注意：這個配置在一定程度上會影響叢集的可用性，比如slave要是少於1個，這個叢集就算leader正常也不能提供服務了，需要具體場景權衡選擇。
主節點當機之後，再重啟就會變成從節點，叢集的配置檔案也會進行同步更新。
叢集是否完整才能對外提供服務
當redis.conf的配置cluster-require-full-coverage為no時，表示當負責一個插槽的主庫下線且沒有相應的從庫進行故障恢復時，叢集仍然可用，如果為yes則叢集不可用。
預設值是yes，因為叢集認為資料已經不完整了。
Redis叢集為什麼至少需要三個master節點，並且推薦節點數為奇數？
因為新master的選舉需要大於半數的叢集master節點同意才能選舉成功，如果只有兩個master節點，當其中一個掛了，是達不到選舉新master的條件的。
奇數個master節點可以在滿足選舉該條件的基礎上節省一個節點，比如三個master節點和四個master節點的叢集相比，大家如果都掛了一個master節點都能選舉新master節點，三個掛了兩個master節點都沒法選舉新master節點了，四個掛了兩個還可以進行選舉，只是次數可能要更多一些。
所以奇數的master節點更多的是從節省機器資源角度出發說的。當然偶數個節點也是可以的。
Redis叢集對批次操作命令的支援
對於類似mset，mget這樣的多個key的原生批次操作命令，redis叢集只支援所有key落在同一slot的情況，如果有多個key一定要用mset命令在redis叢集上操作，則可以在key的前面加上{XX}，這樣引數資料分片hash計算的只會是大括號裡的值，這樣能確保不同的key能落到同一slot裡去，如果不加這個字首，會直接報錯。
示例如下：
mset {user1}:1:name hh {user1}:1:age 18
假設name和age計算的hash slot值不一樣，但是這條命令在叢集下執行，redis只會用大括號裡的 user1 做hash slot計算，所以算出來的slot值肯定相同，最後都能落在同一slot。
檢視redis叢集的命令幫助
cd /usr/local/redis-5.0.3 src/redis-cli --cluster help
1.create：建立一個叢集環境host1:port1 ... hostN:portN
2.call：可以執行redis命令
3.add-node：將一個節點新增到叢集裡，第一個引數為新節點的ip:port，第二個引數為叢集中任意一個已經存在的節點的ip:port
4.del-node：移除一個節點
5.reshard：重新分片
6.check：檢查叢集狀態
新增節點的時候，如果是主從結構，那麼就需要手動的指定主從節點。