一、前言

Sentinel集群會對Redis的主從架構中的Redis實例進行監(jiān)控，一旦發(fā)現(xiàn)了master節(jié)點宕機了，就會選舉出一個Sentinel節(jié)點來執(zhí)行故障轉移，從原來的slave節(jié)點中選舉出一個，將其提升為master節(jié)點，然后讓其他的節(jié)點去復制新選舉出來的master節(jié)點。

你可能會覺得這樣沒有問題啊，甚至能夠滿足我們生產環(huán)境的使用需求了，那我們?yōu)槭裁催€需要Redis Cluster呢？

二、為什么需要Redis Cluster

的確，在數據上，有replication副本做保證；可用性上，master宕機會自動的執(zhí)行failover。

那問題在哪兒呢？

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

假設master節(jié)點的內存只有4G，那slave節(jié)點所能存儲的數據上限也只能是4G。主從復制架構中是讀寫分離的，我們可以通過增加slave節(jié)點來擴展主從的讀并發(fā)能力，但是寫能力和存儲能力是無法進行擴展的，就只能是master節(jié)點能夠承載的上限。

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

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

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

三、Redis Cluster是什么

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

那什么是Redis Cluster呢？

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

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

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

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

四、節(jié)點負載均衡

知道了什么是Redis Cluster，我們就可以繼續(xù)下面的討論了。

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

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

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

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

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

五、什么是一致性哈希

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

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

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

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

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

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

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

六、虛擬節(jié)點機制

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

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

virtual-dom

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

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

七、Redis Cluster采用的什么算法

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

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

十一、使用gossip的優(yōu)劣

既然Redis Cluster選擇了gossip，那肯定存在一些gossip的優(yōu)點，我們接下來簡單梳理一下。

gossip可以在O(logN) 輪就可以將信息傳播到所有的節(jié)點，為什么是O(logN)呢？因為每次ping，當前節(jié)點會帶上自己的信息外加整個Cluster的1/10數量的節(jié)點信息，一起發(fā)送出去。你可以簡單的把這個模型抽象為：

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

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

十二、總結

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

以上就是解析Redis Cluster原理的詳細內容，更多關于Redis Cluster的資料請關注腳本之家其它相關文章！