老司機帶你玩轉面試（5）：Redis 叢集模式 Redis Cluster

極客挖掘機發表於2020-07-18

面試Redis模式

前文回顧

建議前面文章沒看過的同學先看下前面的文章：

「老司機帶你玩轉面試（1）：快取中介軟體 Redis 基礎知識以及資料持久化」

「老司機帶你玩轉面試（2）：Redis 過期策略以及快取雪崩、擊穿、穿透」

「老司機帶你玩轉面試（3）：Redis 高可用之主從模式」

「老司機帶你玩轉面試（4）：Redis 高可用之哨兵模式」

簡介

之前介紹的 Redis 的高可用方案：主從模式或者說哨兵模式，都只是在解決高可用的問題，比如說主從模式解決了讀高可用，哨兵模式解決了寫高可用。

如果我們需要快取的資料量比較少，幾個 G 足夠用了，那麼這兩種方案的高可用模式完全可以滿足需求，一個 master 對多個 salve ，需要幾個 salve 跟讀的吞吐量相關，然後再搞一個 sentinel 叢集去保證 Redis 主從模式的高可用。

但是如果我們有大量的資料需要進快取，單機的儲存容量無法滿足的時候，怎麼辦？

這時，需要用到分散式快取，就在幾年前，想用分散式快取還得藉助中介軟體來實現，比如當時風靡一時的 codis ，或者說還有 twemproxy 。在使用上，我們對 Redis 中介軟體進行讀寫操作， Redis 中介軟體負責將我們的資料分散式的儲存在多臺機器上的 Redis 例項中。

而 Redis 也是不斷在發展的，終於在 3.0 的版本中（其實對現在來講也是比較早的版本了，現在的版本都 6.0 了），原生支援了叢集模式。

可以做到在多臺機器上，部署多個 Redis 例項，每個例項儲存一部分的資料，同時每個 Redis 主例項可以掛載 Redis 從例項，實現了 Redis 主例項掛了，會自動切換到 Redis 從例項上來。

除了實現了分散式儲存以外，還順便實現了高可用。

分散式定址演算法

Redis Cluster 的資料是分散式儲存的，這就必然會引發一個問題，假如我有 3 個節點，我如何知道一個 key 是存在這 3 個節點的哪一個節點上，取數的時候如何準確的找到對應的節點將資料取出來？這就要用到分散式定址演算法了。

常見的分散式定址演算法有兩種：

hash 演算法
一致性 hash 演算法

hash 演算法

hash 演算法是對 key 進行 hash 運算後取值，然後對節點的數量取模。

接著將 key 存入對應的節點，但是，一旦其中某個節點當機，所有的請求過來，都會基於最新的存活的節點數量進行取模運算，這就會導致大多數的請求無法拿到快取資料。

舉個例子，一開始我有 3 個節點，這時大家正常的取模運算將資料基本均勻的存在了 3 個節點上，突然當機了一臺，現在只剩下 2 個有效的節點了，這時所有的運算都會基於最新的 2 個節點進行取模運算，原來的 key 對 2 進行取模運算後，顯然和對 3 進行取模運算得到的結果是不一樣的。

結果是大量的資料請求會直接打在 DB 上，這是不可容忍的。

一致性 hash 演算法

一致性 hash 演算法將整個 hash 值空間組織成一個虛擬的圓環，整個空間按順時針方向組織，下一步將各個 master 節點（使用伺服器的 ip 或主機名）進行 hash。這樣就能確定每個節點在其雜湊環上的位置。

來看一個經典的一致性 hash 演算法的環狀示意圖：

來了一個 key，首先計算 hash 值，並確定此資料在環上的位置，從此位置沿環順時針「行走」，遇到的第一個 master 節點就是 key 所在位置。

在一致性雜湊演算法中，如果一個節點掛了，受影響的資料僅僅是此節點到環空間前一個節點（沿著逆時針方向行走遇到的第一個節點）之間的資料，其它不受影響。增加一個節點也同理。

一致性雜湊演算法在節點太少時，容易因為節點分佈不均勻而造成快取熱點的問題。為了解決這種熱點問題，一致性 hash 演算法引入了虛擬節點機制，即對每一個節點計算多個 hash，每個計算結果位置都放置一個虛擬節點。這樣就實現了資料的均勻分佈，負載均衡。

Redis Cluster 的 hash slot 演算法

Redis Cluster 的實現方案十分的聰明，它的分割槽方式採用了虛擬槽分割槽。

Redis Cluster 首先會預設虛擬槽，每個槽就相當於一個數字，有一定範圍，每個槽對映一個資料子集。

Redis Cluster中預設虛擬槽的範圍為 0 到 16383

Redis Cluster 會把 16384 個槽按照節點數量進行平均分配，由節點進行管理。
當一個 key 過來的時候，會對這個 key 按照 CRC16 規則進行 hash 運算。
把 hash 結果對 16383 進行取餘。
把餘數傳送給 Redis 節點。
節點接收到資料，驗證是否在自己管理的槽編號的範圍：
1. 如果在自己管理的槽編號範圍內，則把資料儲存到資料槽中，然後返回執行結果。
2. 如果在自己管理的槽編號範圍外，則會把資料傳送給正確的節點，由正確的節點來把資料儲存在對應的槽中。

注意：Redis Cluster 的節點之間會共享訊息，每個節點都會知道是哪個節點負責哪個範圍內的資料槽

虛擬槽分佈方式中，由於每個節點管理一部分資料槽，資料儲存到資料槽中。當節點擴容或者縮容時，對資料槽進行重新分配遷移即可，資料不會丟失。

節點內部通訊機制

在分散式的儲存方式中，還有另外一個點需要我們關注，那就是叢集之間的內部通訊方式，畢竟整個叢集是需要知道當前叢集中有多少有效的節點，這些節點分配的 ip 以及一些其他的資料，這些資料我們可以稱之為後設資料。

叢集後設資料的維護有兩種方式：集中式、 Gossip 協議。而 Redis Cluster 節點間採用 Gossip 協議進行通訊。

集中式是將叢集後設資料（節點資訊、故障等等）幾種儲存在某個節點上。集中式後設資料集中儲存的一個典型代表，就是大資料領域的 storm 。它是分散式的大資料實時計算引擎，是集中式的後設資料儲存的結構，底層基於 zookeeper （分散式協調的中介軟體）對所有後設資料進行儲存維護。

Redis 維護叢集後設資料採用另一個方式， Gossip 協議，所有節點都持有一份後設資料，不同的節點如果出現了後設資料的變更，就不斷將後設資料傳送給其它的節點，讓其它節點也進行後設資料的變更。

Gossip 協議

Gossip 協議是一種非常有意思的協議，它的過程是由一個種子節點發起，它會隨機的選擇周圍幾個節點散播訊息，收到訊息的節點也會重複該過程，直至最終網路中所有的節點都收到了訊息。

這個過程可能需要一定的時間，由於不能保證某個時刻所有節點都收到訊息，但是理論上最終所有節點都會收到訊息，因此它是一個最終一致性協議。

Gossip 協議的一些特性：

擴充套件性：網路可以允許節點的任意增加和減少，新增加的節點的狀態最終會與其他節點一致。
容錯：網路中任何節點的當機和重啟都不會影響 Gossip 訊息的傳播，Gossip 協議具有天然的分散式系統容錯特性。
去中心化： Gossip 協議不要求任何中心節點，所有節點都可以是對等的，任何一個節點無需知道整個網路狀況，只要網路是連通的，任意一個節點就可以把訊息散播到全網。
一致性收斂： Gossip 協議中的訊息會以一傳十、十傳百一樣的指數級速度在網路中快速傳播，因此係統狀態的不一致可以在很快的時間內收斂到一致。訊息傳播速度達到了 logN。
訊息的延遲：由於 Gossip 協議中，節點只會隨機向少數幾個節點傳送訊息，訊息最終是通過多個輪次的散播而到達全網的，因此使用 Gossip 協議會造成不可避免的訊息延遲。不適合用在對實時性要求較高的場景下。
訊息冗餘： Gossip 協議規定，節點會定期隨機選擇周圍節點傳送訊息，而收到訊息的節點也會重複該步驟，因此就不可避免的存在訊息重複傳送給同一節點的情況，造成了訊息的冗餘，同時也增加了收到訊息的節點的處理壓力。而且，由於是定期傳送，因此，即使收到了訊息的節點還會反覆收到重複訊息，加重了訊息的冗餘。

Gossip 協議包含多種訊息，包含 ping , pong , meet , fail 等等。

meet：某個節點傳送 meet 給新加入的節點，讓新節點加入叢集中，然後新節點就會開始與其它節點進行通訊。
ping：每個節點都會頻繁給其它節點傳送 ping，其中包含自己的狀態還有自己維護的叢集後設資料，互相通過 ping 交換後設資料。
pong：返回 ping 和 meeet，包含自己的狀態和其它資訊，也用於資訊廣播和更新。
fail：某個節點判斷另一個節點 fail 之後，就傳送 fail 給其它節點，通知其它節點說，某個節點當機啦。

由於 Redis Cluster 節點之間會定期交換 Gossip 訊息，以及做一些心跳檢測，對網路頻寬的壓力還有比較大的，包括官方都直接建議 Redis Cluster 節點數量不要超過 1000 個，當叢集中節點數量過多的時候，會產生不容忽視的頻寬消耗。

高可用和主備切換

一說到叢集就不得不提高可用和主備切換，而Redis cluster 的高可用的原理，幾乎跟哨兵是類似的。

判斷當機

首先第一步當然是判斷當機，這和哨兵模式非常的像，同樣是分成兩種型別，一種是主觀當機 pfail ，另一種的客觀當機 fail 。

主觀當機：一個節點認為另外一個節點當機，這是一種「偏見」，並不代表整個叢集的認知。

節點 1 定期傳送 ping 訊息給節點 2 。
如果傳送成功，代表節點 2 正常執行，節點 2 會響應 PONG 訊息給節點 1 ，節點 1 更新與節點 2 的最後通訊時間
如果傳送失敗，則節點 1 與節點 2 之間的通訊異常判斷連線，在下一個定時任務週期時，仍然會與節點 2 傳送 ping 訊息
如果節點 1 發現與節點 2 最後通訊時間超過 cluster-node-timeout ，則把節點 2 標識為 pfail 狀態。

客觀當機：當半數以上持有槽的主節點都標記某節點主觀下線。

當節點 1 認為節點 2 當機後，那麼會在 Gossip ping 訊息中， ping 給其他節點。
當其他節點會重新嘗試之前節點 1 主觀當機的過程。
如果有超過半數的節點都認為 pfail 了，那麼這個節點 2 就會變成真的 fail 。

注意：叢集模式下，只有主節點( master )才有讀寫許可權和叢集槽的維護許可權，從節點( slave )只有複製的許可權。

從節點選舉

先檢查資格，檢查所有的 salve 與 master 斷開連線的時間，如果超過了 cluster-node-timeout * cluster-slave-validity-factor ，那麼久沒有資格成為 master 。
每個從節點，都根據自己對 master 複製資料的 offset，來設定一個選舉時間，offset 越大（複製資料越多）的從節點，選舉時間越靠前，優先進行選舉。
所有的 master 開始選舉投票，如果大部分 master 節點（N/2 + 1）都投票給了某個從節點，那麼選舉通過，那個從節點可以切換成 master 。
從節點執行主備切換，從節點切換為主節點。