大家好，我是小?，一個漂泊江湖多年的 985 非科班程序員，曾混跡于國企、互聯網大廠和創業公司的后臺開發攻城獅。

1. 引言

前面我們已經聊過 Redis 的主從同步（復制）和哨兵機制，這期我們來聊 Redis 的集群模式。

但是在超大規模的互聯網應用中，業務規模不斷擴展，用戶量持續增多時，原有的主從+哨兵機制已經不滿足我們的需求了。如：性能問題，數據量過多、并發量過高導致 Redis 服務器響應太慢。

1.1 自古功夫出少林

如果把 Redis 比作江湖里的門派，少林寺作為武林中最有威望的名門正派，提供了武功秘籍（緩存數據）的存儲服務。

由于少林存儲的可用性做的很好，武功秘籍幾乎不會丟失。而且，每次去獲取武林同道的秘籍時，響應也很快，所以少林威望不斷提升，后得千古美譽：“自古功夫出少林”。

少林的武功秘籍存儲方案為什么這么穩定呢？

這得從頭說起。

1.2 累壞的掌門人

在武林大會 3.0 之前，已經有很多武林同道在少林寺存取武功秘籍了，而少林掌門作為權力的中心，不僅披星戴月和外賓打交道（Client 請求），還得在管理物資之余（數據存儲和輸出）給副掌門做業務培訓（數據備份）。

雖然在武林大會 2.8 時，少林和武當一樣，已經新增了哨兵部門，從此不用擔心掌門嗝屁的問題。

詳見上一篇文章：深入淺出Redis高可用：哨兵機制

但掌門人日理萬機，應接不暇，還是把頭發都愁掉了！

為了掩飾尷尬，從此少林弟子不準留頭發 ??

這時可能有小伙伴產生疑問了，性能不好，那就加 CPU、加內存或者網絡帶寬唄？！

只能說太天真！當數據量增大、并發增高時，一味地增加 Redis 服務器的CPU、內存和網絡帶寬，往往不能起到很好的優化效果。

畢竟，服務器也和人的體能極限一樣，不是吃得越多，就可以干活越快的。

而縱向擴展不管用，我們就只能考慮橫向擴展了：團結就是力量，一個人忙不過來，那就再來十個。

于是乎，今天的主角——Redis 集群模式應時而生。

2. 集群模式：分權

Redis3.0 之后，加入了 Redis 集群模式，即 Redis Cluster：可以自動在多個節點上分布數據，節點間的數據能共享，也能動態地調整數據分布。

2.1 集群架構

Redis 集群采用去中心化的思想，沒有中心節點的說法。

對于客戶端來說，整個集群可以看成是一個整體，可以連接任意的節點進行數據操作，就像操作單實例 Redis 一樣，也不需要任何的代理中間件。

少林掌門：幫手來了，不用一個人掉頭發了！

最重要的是，Redis 集群具有高可用性，支持多個 master 節點，每個 master 節點都可以掛載多個 slave 節點，當 master 節點掛掉以后，集群會選出一個新的 master 節點。

圖片

自武林大會 3.0 以來，少林為了解決事務變多，掌門人疲于應對的問題，引入了多掌門模式：每個掌門平級，共同處理門派事務，也可以發展自己的副掌門，以作平替。

當有新的外賓訪問時，會首先通過少林寺通信部（Client）來將請求轉發給各掌門，再分別處理。

相當于一個人的活可以數以千計個人一起干，不得不說，這很強！

那這個過程是如何建立起來的呢？

2.2 集群組建

首先，少林會選出多個掌門人（根據武林秘籍的數量決定），然后找一個掌門人負責集群組建的主持工作。

武林規定，一個門派不超過 1000 個掌門人：master 節點個數盡量在 1000 個以下

假設我們用三個 master 節點作為集群成員，它們的建連過程如下圖所示：

圖片

為了提升工作效率，掌門人之間需要加群方便溝通，在 Redis 中，master1 可以向 master2 節點發送以下命令建連：

CLUSTER MEET 127.0.0.2 6379

當 master2 節點回復響應時，一個 Redis Cluster 便組建成功了。

群聊組建成功后，掌門人們便開始各自管理事務。但少林存放的武林秘籍這么多，每個掌門該如何分配管理呢？

2.3 集群數據分片

在少林里，有專門的算法機制以及秘籍庫來管理武林秘籍。

首先：將每本武功秘籍都賦予一個唯一標識，并將唯一標識分類后放到不同的秘籍庫，然后交由不同的掌門人進行管理。

其中：算法機制用的是 CRC16，秘籍庫有 16384 個

結合集群中各 master 節點的交互包大小、節點數量的最大值來考量：Redis 官方將集群中所有的數據劃分到 16384（2 的 14 次方）個哈希槽（slots）里面，每個 master 節點管理一部分 slot。

圖片

當 master 節點數為 N 時，每個節點的哈希槽（slot）個數為 16384/N 個，基本保證均勻分布。

當然，這是可以人為控制的，如果某個節點的性能較好，就可以多分配一些 slot。命令如下：

redis-cli -h 127.0.0.1 -p 6379 cluster addslots 0, 5460

能者多勞，這在掌門人之間也達成了共識。

2.4 數據存取流程

我們知道，江湖中每天都會新增不可計數的武林秘籍，而少林要求這些武林秘籍都有一個唯一標識 key，真實的秘籍信息存放在 value 里面。

少林會根據 key 的不同，將它們歸為不同的秘籍庫，然后再根據秘籍庫的編號，讓不同的掌門人分屬管理。

當對秘籍進行存取時，少林通信部會使用 CRC16 算法對秘籍 key 進行計算并對 16384 取模，得到的結果就是這個武功秘籍存放的秘籍庫 slot：

slot = CRC16（key）% 16384

然后，通信部會根據掌門人群組返回的 {slot，Redis實例IP} 映射表，通過秘籍庫 ID 去找到對應的掌門人住址，最后向此掌門人存儲或索要 key 對應的武功秘籍 value。

3. 集群的擴容與訪問

這時，有聰明的武林同道發現了問題：既然秘籍庫的數量是固定的 16384，當少林寺新增掌門人時，豈不是沒有秘籍庫可以管理了？

這個問題很好，當哈希 slot 已經被分配完畢，并已經存儲數據時，如果后續在線上需要新增 master 節點，那新增的哈希 slot 從哪里來呢？

既然蛋糕不會變大，那只能把現有的蛋糕分出來了。

怎么分？那當然是一人分一點出來！大家都不愿意吃虧，所以分出來的地盤盡可能相同。

3.1 數據遷移：一人分一點

當少林寺宣布要新增一個四掌門時，大家紛紛開始工作。

首先，三個掌門首先會劃出一部分秘籍庫出來，準備移交到四掌門管轄。

圖片

確定好遷移的秘籍庫后，通信部會做以下幾件事：

1. 對目標節點（即四掌門：127.0.0.4: 6385）發送 cluster setslot {slot} importing 127.0.0.4 命令，讓目標節點準備導入槽數據；
2. 對源節點（大掌門、二掌門、三掌門 3 個節點）發送 cluster setslot {slot} migrating 127.0.0.4 命令，讓源節點準備遷出槽數據；
3. 源節點上循環執行 cluster getkeysinslot {slot} {count} 命令，獲取 count 個數據槽 {slot} 的 key；
4. 在源節點上執行 migrate 127.0.0.1 6379 key 0 {timeout} 命令將指定的 key 進行遷移。

重復 3,4 步驟直到槽下所有的鍵值數據遷移到目標節點。

當遷移結束后，向集群中所有的主節點發送通知，slot 集合已經分配給了目標節點。

3.2 數據訪問：秘籍怎么取

上面我們已經說過了，在少林寺存儲的武林秘籍由各掌門共同處理。那么，當外賓想要獲取存儲的秘籍時，該如何獲取呢？

圖片

如上圖所示，當 Client 首次訪問 Redis 時，會經過三個步驟：

• 客戶端（Client）連接某個實例，獲取到 slots 和實例節點的映射關系，并將這個映射關系存儲在本地緩存；
• 將需要存取的 key 經過 CRC16 計算后，再用 16384 對其取模，獲取 slot 的值；
• 根據映射表得到 slot 對應的實例，將 key 存取的請求發送到這個實例上進行操作。

正常訪問是這個流程，但如果新增節點后，key 對應的 slot 被遷移了怎么辦呢？

3.3 slot已遷移，秘籍找誰要

當通信部第一次訪問秘籍 key1 時，計算得出 slot(key1) = 5000，然后被掌門人群組告知：這個 slot 5000 對應的武功秘籍存放在大掌門那里，于是通信部將 {slot=5000, 大掌門} 這個映射信息存了下來。

但是，當客戶端第二次訪問 key1 時，slot 5000 已經被大掌門分給了四掌門，由于秘籍遷移的過程需要一定的時間，所以分兩種情況討論：

• 如果 slot 遷移已經結束，就會出現 MOVED 重定向，代表數據已經轉移了；
• 如果 slot 正在遷移，就會出現 ASK 重定向，代表不確定該 key 是否遷移完成，需要通信部去四掌門那里問一下。

當請求的 slot 發生遷移時，redis-cluster 交互時序圖如下：

首先，通信部成員根據 slot 5000 和武功秘籍的唯一標識 key1 屁顛屁顛去找大掌門索要武功秘籍，但是大掌門說：這個 key1 對應的武功秘籍找不到，我這會在做秘籍遷移呢，我先看下 slot 5000 秘籍庫的鑰匙有沒有在我這里吧：

• 鑰匙還在，說明遷移正在進行，則 key1 可能在四掌門那里，你去他那里問下。然后大掌門甩給了通信部成員一個 ASK 重定向異常。
• 鑰匙已經不在了，秘籍庫在老四那里，你直接找他吧，并甩給通信部成員一個 MOVED 重定向異常。

客戶端收到 Cluster 返回的異常后判斷：

• 如果是 ASK 異常，則發送 ASK 命令到 master4 節點建連，再執行 key 命令：如果存在則執行返回數據，不存在則返回不存在信息；
• 如果是 MOVED 異常，客戶端會直接去 master4 請求 key 數據，并更新本地緩存，后續訪問同一個 key 的數據都去請求 master4 節點 。

這時，有小伙伴要問了：都是重定向，MOVED 和 ASK 有什么實質性區別嗎？

其實，和 HTTP 請求里的重定向 301、302 類似，MOVED 和 ASK 就是永久重定向和臨時重定向的區別，分別代表 key 已遷移和不確定 key 已遷移的異常狀態。

4. 小結

當業務規模不斷擴展，用戶量和并發量都很大時，用主從復制+哨兵機制來支撐 Redis 的高可用還是不能解決單機主實例的性能問題：比如數據響應太慢。

同時，在面對千萬級甚至億萬級的數據流量時，利用分治法來進行實例擴展尤為重要。

而 Redis 集群，不僅原生支持了主從復制，每個主節點都用備用節點，而且還支持哨兵機制，當某個主節點宕機時，Cluster 會自動將對應的 Slave 節點選為 Master，以實現故障轉移。