前言
上文我們聊了基于Sentinel的Redis高可用架構，了解了Redis基于讀寫分離的主從架構，同時也知道當Redis的master發生故障之后，Sentinel集群是如何執行failover的，以及其執行failover的原理是什么。

這里大概再提一下，Sentinel集群會對Redis的主從架構中的Redis實例進行監控，一旦發現了master節點宕機了，就會選舉出一個Sentinel節點來執行故障轉移，從原來的slave節點中選舉出一個，將其提升為master節點，然后讓其他的節點去復制新選舉出來的master節點。

你可能會覺得這樣沒有問題啊，甚至能夠滿足我們生產環境的使用需求了，那我們為什么還需要Redis Cluster呢？

為什么需要Redis Cluster
的確，在數據上，有replication副本做保證；可用性上，master宕機會自動的執行failover。

那問題在哪兒呢？

首先Redis Sentinel說白了也是基于主從復制，在主從復制中slave的數據是完全來自于master。

假設master節點的內存只有4G，那slave節點所能存儲的數據上限也只能是4G。而且在之前的跟隨杠精的視角一起來了解Redis的主從復制文章中也說過，主從復制架構中是讀寫分離的，我們可以通過增加slave節點來擴展主從的讀并發能力，但是寫能力和存儲能力是無法進行擴展的，就只能是master節點能夠承載的上限。

所以，當你只需要存儲4G的數據時候的，基于主從復制和基于Sentinel的高可用架構是完全夠用的。

但是如果當你面臨的是海量的數據的時候呢？16G、64G、256G甚至1T呢？現在互聯網的業務里面，如果你的體量足夠大，我覺得是肯定會面臨緩存海量緩存數據的場景的。

這就是為什么我們需要引入Redis Cluster。

Redis Cluster是什么
知道了為什么需要Redis Cluster之后，我們就可以來對其一探究竟了。

那什么是Redis Cluster呢？

很簡單，你就可以理解為n個主從架構組合在一起對外服務。Redis Cluster要求至少需要3個master才能組成一個集群，同時每個master至少需要有一個slave節點。

這樣一來，如果一個主從能夠存儲32G的數據，如果這個集群包含了兩個主從，則整個集群就能夠存儲64G的數據。

我們知道，主從架構中，可以通過增加slave節點的方式來擴展讀請求的并發量，那Redis Cluster中是如何做的呢？雖然每個master下都掛載了一個slave節點，但是在Redis Cluster中的讀、寫請求其實都是在master上完成的。

slave節點只是充當了一個數據備份的角色，當master發生了宕機，就會將對應的slave節點提拔為master，來重新對外提供服務。

節點負載均衡
知道了什么是Redis Cluster，我們就可以繼續下面的討論了。

不知道你思考過一個問題沒，這么多的master節點。我存儲的時候，到底該選擇哪個節點呢？一般這種負載均衡算法，會選擇哈希算法。哈希算法是怎么做的呢？

首先就是對key計算出一個hash值，然后用哈希值對master數量進行取模。由此就可以將key負載均衡到每一個Redis節點上去。這就是簡單的哈希算法的實現。

那Redis Cluster是采取的上面的哈希算法嗎？答案是沒有。

Redis Cluster其實采取的是類似于一致性哈希的算法來實現節點選擇的。那為什么不用哈希算法來進行實例選擇呢？以及為什么說是類似的呢？我們繼續討論。

因為如果此時某一臺master發生了宕機，那么此時會導致Redis中所有的緩存失效。為什么是所有的？假設之前有3個master，那么之前的算法應該是 hash % 3，但是如果其中一臺master宕機了，則算法就會變成 hash % 2，會影響到之前存儲的所有的key。而這對緩存后面保護的DB來說，是致命的打擊。

什么是一致性哈希
知道了通過傳統哈希算法來實現對節點的負載均衡的弊端，我們就需要進一步了解什么是一致性哈希。

我們上面提過哈希算法是對master實例數量來取模，而一致性哈希則是對2^32取模，也就是值的范圍在[0, 2^32 -1]。一致性哈希將其范圍抽象成了一個圓環，使用CRC16算法計算出來的哈希值會落到圓環上的某個地方。

然后我們的Redis實例也分布在圓環上，我們在圓環上按照順時針的順序找到第一個Redis實例，這樣就完成了對key的節點分配。我們舉個例子。

假設我們有A、B、C三個Redis實例按照如圖所示的位置分布在圓環上，此時計算出來的hash值，取模之后位置落在了位置D，那么我們按照順時針的順序，就能夠找到我們這個key應該分配的Redis實例B。同理如果我們計算出來位置在E，那么對應選擇的Redis的實例就是A。

即使這個時候Redis實例B掛了，也不會影響到實例A和C的緩存。

例如此時節點B掛了，那之前計算出來在位置D的key，此時會按照順時針的順序，找到節點C。相當于自動的把原來節點B的流量給轉移到了節點C上去。而其他原本就在節點A和節點C的數據則完全不受影響。

這就是一致性哈希，能夠在我們后續需要新增節點或者刪除節點的時候，不影響其他節點的正常運行。

虛擬節點機制
但是一致性哈希也存在自身的小問題，例如當我們的Redis節點分布如下時，就有問題了。

此時數據落在節點A上的概率明顯是大于其他兩個節點的，其次落在節點C上的概率最小。這樣一來會導致整個集群的數據存儲不平衡，AB節點壓力較大，而C節點資源利用不充分。為了解決這個問題，一致性哈希算法引入了虛擬節點機制。

在圓環中，增加了對應節點的虛擬節點，然后完成了虛擬節點到真實節點的映射。假設現在計算得出了位置D，那么按照順時針的順序，我們找到的第一個節點就是C #1，最終數據實際還是會落在節點C上。

通過增加虛擬節點的方式，使ABC三個節點在圓環上的位置更加均勻，平均了落在每一個節點上的概率。這樣一來就解決了上文提到的數據存儲存在不均勻的問題了，這就是一致性哈希的虛擬節點機制。

Redis Cluster采用的什么算法
上面提到過，Redis Cluster采用的是類一致性哈希算法，之所以是類一致性哈希算法是因為它們實現的方式還略微有差別。

例如一致性哈希是對2^32取模，而Redis Cluster則是對2^14（也就是16384）取模。Redis Cluster將自己分成了16384個Slot（槽位）。通過CRC16算法計算出來的哈希值會跟16384取模，取模之后得到的值就是對應的槽位，然后每個Redis節點都會負責處理一部分的槽位，就像下表這樣。

節點?? ?處理槽位
A?? ?0 - 5000
B?? ?5001 - 10000
C?? ?10001 - 16383
每個Redis實例會自己維護一份slot - Redis節點的映射關系，假設你在節點A上設置了某個key，但是這個key通過CRC16計算出來的槽位是由節點B維護的，那么就會提示你需要去節點B上進行操作。

Redis Cluster如何做到高可用
不知道你思考過一個問題沒，如果Redis Cluster中的某個master節點掛了，它是如何保證集群自身的高可用的？如果這個時候我們集群需要擴容節點，它該負責哪些槽位呢？我們一個一個問題的來看一下。

集群如何進行擴容
我們開篇聊過，Redis Cluster可以很方便的進行橫向擴容，那當新的節點加入進來的時候，它是如何獲取對應的slot的呢？

答案是通過reshard（重新分片）來實現。reshard可以將已經分配給某個節點的任意數量的slot遷移給另一個節點，在Redis內部是由redis-trib負責執行的。你可以理解為Redis其實已經封裝好了所有的命令，而redis-trib則負責向獲取slot的節點和被轉移slot的節點發送命令來最終實現reshard。

假設我們需要向集群中加入一個D節點，而此時集群內已經有A、B、C三個節點了。

此時redis-trib會向A、B、C三個節點發送遷移出槽位的請求，同時向D節點發送準備導入槽位的請求，做好準備之后A、B、C這三個源節點就開始執行遷移，將對應的slot所對應的鍵值對遷移至目標節點D。最后redis-trib會向集群中所有主節點發送槽位的變更信息。

高可用及故障轉移
Redis Cluster中保證集群高可用的思路和實現和Redis Sentinel如出一轍，感興趣的可以去看我之前寫的關于Sentinel的文章Redis Sentinel-深入淺出原理和實戰。

簡單來說，針對A節點，某一個節點認為A宕機了，那么此時是主觀宕機。而如果集群內超過半數的節點認為A掛了， 那么此時A就會被標記為客觀宕機。

一旦節點A被標記為了客觀宕機，集群就會開始執行故障轉移。其余正常運行的master節點會進行投票選舉，從A節點的slave節點中選舉出一個，將其切換成新的master對外提供服務。當某個slave獲得了超過半數的master節點投票，就成功當選。

當選成功之后，新的master會執行slaveof no one來讓自己停止復制A節點，使自己成為master。然后將A節點所負責處理的slot，全部轉移給自己，然后就會向集群發PONG消息來廣播自己的最新狀態。

按照一致性哈希的思想，如果某個節點掛了，那么就會沿著那個圓環，按照順時針的順序找到遇到的第一個Redis實例。

而對于Redis Cluster，某個key它其實并不關心它最終要去到哪個節點，他只關心他最終落到哪個slot上，無論你節點怎么去遷移，最終還是只需要找到對應的slot，然后再找到slot關聯的節點，最終就能夠找到最終的Redis實例了。

那這個PONG消息又是什么東西呢？別急，下面就會聊到。

簡單了解gossip協議
這就是Redis Cluster各個節點之間交換數據、通信所采用的一種協議，叫做gossip。

gossip: 流言、八卦、小道消息
1
gossip是在1989年的論文上提出的，我看了一堆資料都說的是1987年發表的，但是文章里的時間明確是1989年1月份發表。

感興趣的可以去看看Epidemic Algorithms for Replicated . Database Maintenance，在當時提出gossip主要是為了解決在分布式數據庫中，各個副本節點的數據同步問題。但隨著技術的發展，gossip后續也被廣泛運用于信息擴散、故障探測等等。

Redis Cluster就是利用了gossip來實現自身的信息擴散的。那使用gossip具體是如何通信的呢？

很簡單，就像圖里這樣。每個Redis節點每秒鐘都會向其他的節點發送PING，然后被PING的節點會回一個PONG。

gossip協議消息類型
Redis Cluster中，節點之間的消息類型有5種，分別是MEET、PING、PONG、FAIL和PUBLISH。這些消息分別傳遞了什么內容呢？我簡單總結了一下。

消息類型?? ?消息內容
MEET?? ?給某個節點發送MEET消息，請求接收消息的節點加入到集群中
PING?? ?每隔一秒鐘，選擇5個最久沒有通信的節點，發送PING消息，檢測對應的節點是否在線；同時還有一種策略是，如果某個節點的通信延遲大于了cluster-node-time的值的一半，就會立即給該節點發送PING消息，避免數據交換延遲過久
PONG?? ?當節點接收到MEET或者PING消息之后，會回一個PONG消息給發送方，代表自己收到了MEET或者PING消息。同時，節點也可以主動的通過PONG消息向集群中廣播自己的信息，讓其他節點獲取到自己最新的屬性，就像完成了故障轉移之后新的master向集群發送PONG消息一樣
FAIL?? ?用于廣播自己的對某個節點的宕機判斷，假設當前節點對A節點判斷為宕機，就會立即向Redis Cluster廣播自己對于A節點的判斷，所有收到消息的節點就會對A節點做標記
PUBLISH?? ?用于向指定的Channel發送消息，某個節點收到PUBLISH消息之后會直接在集群內廣播，這樣一來，客戶端無論連接到任何節點都能夠訂閱這個Channel
使用gossip的優劣
既然Redis Cluster選擇了gossip，那肯定存在一些gossip的優點，我們接下來簡單梳理一下。

優點?? ?描述
擴展性?? ?網絡可以允許節點的任意增加和減少，新增加的節點的狀態最終會與其他節點一致。
容錯性?? ?由于每個節點都持有一份完整元數據，所以任何節點宕機都不會影響gossip的運行
健壯性?? ?與容錯性類似，由于所有節點都持有數據，地位平臺，是一個去中心化的設計，任何節點都不會影響到服務的運行
最終一致性?? ?當有新的信息需要傳遞時，消息可以快速的發送到所有的節點，讓所有的節點都擁有最新的數據
gossip可以在O(logN) 輪就可以將信息傳播到所有的節點，為什么是O(logN)呢？因為每次ping，當前節點會帶上自己的信息外加整個Cluster的1/10數量的節點信息，一起發送出去。你可以簡單的把這個模型抽象為：

你轉發了一個特別有意思的文章到朋友圈，然后你的朋友們都覺得還不錯，于是就一傳十、十傳百這樣的散播出去了，這就是朋友圈的裂變傳播。

當然，gossip仍然存在一些缺點。例如消息可能最終會經過很多輪才能到達目標節點，而這可能會帶來較大的延遲。同時由于節點會隨機選出5個最久沒有通信的節點，這可能會造成某一個節點同時收到n個重復的消息。

總結
總的來說，Redis Cluster相當于是把Redis的主從架構和Sentinel集成到了一起，從Redis Cluster的高可用機制、判斷故障轉移以及執行故障轉移的過程，都和主從、Sentinel相關，這也是為什么我在之前的文章里說，主從是Redis高可用架構的基石。

————————————————
版權聲明：本文為CSDN博主「SH的全棧筆記」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_42667608/article/details/111360617

總結

以上是生活随笔為你收集整理的Redis cluster原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。