大家好，我是小?，一個(gè)漂泊江湖多年的 985 非科班程序員，曾混跡于國企、互聯(lián)網(wǎng)大廠和創(chuàng)業(yè)公司的后臺(tái)開發(fā)攻城獅。

1. 引言

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

但是在超大規(guī)模的互聯(lián)網(wǎng)應(yīng)用中，業(yè)務(wù)規(guī)模不斷擴(kuò)展，用戶量持續(xù)增多時(shí)，原有的主從+哨兵機(jī)制已經(jīng)不滿足我們的需求了。如：性能問題，數(shù)據(jù)量過多、并發(fā)量過高導(dǎo)致 Redis 服務(wù)器響應(yīng)太慢。

1.1 自古功夫出少林

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

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

少林的武功秘籍存儲(chǔ)方案為什么這么穩(wěn)定呢？

這得從頭說起。

1.2 累壞的掌門人

在武林大會(huì) 3.0 之前，已經(jīng)有很多武林同道在少林寺存取武功秘籍了，而少林掌門作為權(quán)力的中心，不僅披星戴月和外賓打交道（Client 請(qǐng)求），還得在管理物資之余（數(shù)據(jù)存儲(chǔ)和輸出）給副掌門做業(yè)務(wù)培訓(xùn)（數(shù)據(jù)備份）。

雖然在武林大會(huì) 2.8 時(shí)，少林和武當(dāng)一樣，已經(jīng)新增了哨兵部門，從此不用擔(dān)心掌門嗝屁的問題。

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

但掌門人日理萬機(jī)，應(yīng)接不暇，還是把頭發(fā)都愁掉了！

為了掩飾尷尬，從此少林弟子不準(zhǔn)留頭發(fā) ??

這時(shí)可能有小伙伴產(chǎn)生疑問了，性能不好，那就加 CPU、加內(nèi)存或者網(wǎng)絡(luò)帶寬唄？！

只能說太天真！當(dāng)數(shù)據(jù)量增大、并發(fā)增高時(shí)，一味地增加 Redis 服務(wù)器的CPU、內(nèi)存和網(wǎng)絡(luò)帶寬，往往不能起到很好的優(yōu)化效果。

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

而縱向擴(kuò)展不管用，我們就只能考慮橫向擴(kuò)展了：團(tuán)結(jié)就是力量，一個(gè)人忙不過來，那就再來十個(gè)。

于是乎，今天的主角——Redis 集群模式應(yīng)時(shí)而生。

2. 集群模式：分權(quán)

Redis3.0 之后，加入了 Redis 集群模式，即 Redis Cluster：可以自動(dòng)在多個(gè)節(jié)點(diǎn)上分布數(shù)據(jù)，節(jié)點(diǎn)間的數(shù)據(jù)能共享，也能動(dòng)態(tài)地調(diào)整數(shù)據(jù)分布。

2.1 集群架構(gòu)

Redis 集群采用去中心化的思想，沒有中心節(jié)點(diǎn)的說法。

對(duì)于客戶端來說，整個(gè)集群可以看成是一個(gè)整體，可以連接任意的節(jié)點(diǎn)進(jìn)行數(shù)據(jù)操作，就像操作單實(shí)例 Redis 一樣，也不需要任何的代理中間件。

少林掌門：幫手來了，不用一個(gè)人掉頭發(fā)了！

最重要的是，Redis 集群具有高可用性，支持多個(gè) master 節(jié)點(diǎn)，每個(gè) master 節(jié)點(diǎn)都可以掛載多個(gè) slave 節(jié)點(diǎn)，當(dāng) master 節(jié)點(diǎn)掛掉以后，集群會(huì)選出一個(gè)新的 master 節(jié)點(diǎn)。

圖片

自武林大會(huì) 3.0 以來，少林為了解決事務(wù)變多，掌門人疲于應(yīng)對(duì)的問題，引入了多掌門模式：每個(gè)掌門平級(jí)，共同處理門派事務(wù)，也可以發(fā)展自己的副掌門，以作平替。

當(dāng)有新的外賓訪問時(shí)，會(huì)首先通過少林寺通信部（Client）來將請(qǐng)求轉(zhuǎn)發(fā)給各掌門，再分別處理。

相當(dāng)于一個(gè)人的活可以數(shù)以千計(jì)個(gè)人一起干，不得不說，這很強(qiáng)！

那這個(gè)過程是如何建立起來的呢？

2.2 集群組建

首先，少林會(huì)選出多個(gè)掌門人（根據(jù)武林秘籍的數(shù)量決定），然后找一個(gè)掌門人負(fù)責(zé)集群組建的主持工作。

武林規(guī)定，一個(gè)門派不超過 1000 個(gè)掌門人：master 節(jié)點(diǎn)個(gè)數(shù)盡量在 1000 個(gè)以下

假設(shè)我們用三個(gè) master 節(jié)點(diǎn)作為集群成員，它們的建連過程如下圖所示：

圖片

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

CLUSTER MEET 127.0.0.2 6379

當(dāng) master2 節(jié)點(diǎn)回復(fù)響應(yīng)時(shí)，一個(gè) Redis Cluster 便組建成功了。

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

2.3 集群數(shù)據(jù)分片

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

首先：將每本武功秘籍都賦予一個(gè)唯一標(biāo)識(shí)，并將唯一標(biāo)識(shí)分類后放到不同的秘籍庫，然后交由不同的掌門人進(jìn)行管理。

其中：算法機(jī)制用的是 CRC16，秘籍庫有 16384 個(gè)

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

圖片

當(dāng) master 節(jié)點(diǎn)數(shù)為 N 時(shí)，每個(gè)節(jié)點(diǎn)的哈希槽（slot）個(gè)數(shù)為 16384/N 個(gè)，基本保證均勻分布。

當(dāng)然，這是可以人為控制的，如果某個(gè)節(jié)點(diǎn)的性能較好，就可以多分配一些 slot。命令如下：

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

能者多勞，這在掌門人之間也達(dá)成了共識(shí)。

2.4 數(shù)據(jù)存取流程

我們知道，江湖中每天都會(huì)新增不可計(jì)數(shù)的武林秘籍，而少林要求這些武林秘籍都有一個(gè)唯一標(biāo)識(shí) key，真實(shí)的秘籍信息存放在 value 里面。

少林會(huì)根據(jù) key 的不同，將它們歸為不同的秘籍庫，然后再根據(jù)秘籍庫的編號(hào)，讓不同的掌門人分屬管理。

當(dāng)對(duì)秘籍進(jìn)行存取時(shí)，少林通信部會(huì)使用 CRC16 算法對(duì)秘籍 key 進(jìn)行計(jì)算并對(duì) 16384 取模，得到的結(jié)果就是這個(gè)武功秘籍存放的秘籍庫 slot：

slot = CRC16（key）% 16384

然后，通信部會(huì)根據(jù)掌門人群組返回的 {slot，Redis實(shí)例IP} 映射表，通過秘籍庫 ID 去找到對(duì)應(yīng)的掌門人住址，最后向此掌門人存儲(chǔ)或索要 key 對(duì)應(yīng)的武功秘籍 value。

3. 集群的擴(kuò)容與訪問

這時(shí)，有聰明的武林同道發(fā)現(xiàn)了問題：既然秘籍庫的數(shù)量是固定的 16384，當(dāng)少林寺新增掌門人時(shí)，豈不是沒有秘籍庫可以管理了？

這個(gè)問題很好，當(dāng)哈希 slot 已經(jīng)被分配完畢，并已經(jīng)存儲(chǔ)數(shù)據(jù)時(shí)，如果后續(xù)在線上需要新增 master 節(jié)點(diǎn)，那新增的哈希 slot 從哪里來呢？

既然蛋糕不會(huì)變大，那只能把現(xiàn)有的蛋糕分出來了。

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

3.1 數(shù)據(jù)遷移：一人分一點(diǎn)

當(dāng)少林寺宣布要新增一個(gè)四掌門時(shí)，大家紛紛開始工作。

首先，三個(gè)掌門首先會(huì)劃出一部分秘籍庫出來，準(zhǔn)備移交到四掌門管轄。

圖片

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

1. 對(duì)目標(biāo)節(jié)點(diǎn)（即四掌門：127.0.0.4: 6385）發(fā)送 cluster setslot {slot} importing 127.0.0.4 命令，讓目標(biāo)節(jié)點(diǎn)準(zhǔn)備導(dǎo)入槽數(shù)據(jù)；
2. 對(duì)源節(jié)點(diǎn)（大掌門、二掌門、三掌門 3 個(gè)節(jié)點(diǎn)）發(fā)送 cluster setslot {slot} migrating 127.0.0.4 命令，讓源節(jié)點(diǎn)準(zhǔn)備遷出槽數(shù)據(jù)；
3. 源節(jié)點(diǎn)上循環(huán)執(zhí)行 cluster getkeysinslot {slot} {count} 命令，獲取 count 個(gè)數(shù)據(jù)槽 {slot} 的 key；
4. 在源節(jié)點(diǎn)上執(zhí)行 migrate 127.0.0.1 6379 key 0 {timeout} 命令將指定的 key 進(jìn)行遷移。

重復(fù) 3,4 步驟直到槽下所有的鍵值數(shù)據(jù)遷移到目標(biāo)節(jié)點(diǎn)。

當(dāng)遷移結(jié)束后，向集群中所有的主節(jié)點(diǎn)發(fā)送通知，slot 集合已經(jīng)分配給了目標(biāo)節(jié)點(diǎn)。

3.2 數(shù)據(jù)訪問：秘籍怎么取

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

圖片

如上圖所示，當(dāng) Client 首次訪問 Redis 時(shí)，會(huì)經(jīng)過三個(gè)步驟：

• 客戶端（Client）連接某個(gè)實(shí)例，獲取到 slots 和實(shí)例節(jié)點(diǎn)的映射關(guān)系，并將這個(gè)映射關(guān)系存儲(chǔ)在本地緩存；
• 將需要存取的 key 經(jīng)過 CRC16 計(jì)算后，再用 16384 對(duì)其取模，獲取 slot 的值；
• 根據(jù)映射表得到 slot 對(duì)應(yīng)的實(shí)例，將 key 存取的請(qǐng)求發(fā)送到這個(gè)實(shí)例上進(jìn)行操作。

正常訪問是這個(gè)流程，但如果新增節(jié)點(diǎn)后，key 對(duì)應(yīng)的 slot 被遷移了怎么辦呢？

3.3 slot已遷移，秘籍找誰要

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

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

• 如果 slot 遷移已經(jīng)結(jié)束，就會(huì)出現(xiàn) MOVED 重定向，代表數(shù)據(jù)已經(jīng)轉(zhuǎn)移了；
• 如果 slot 正在遷移，就會(huì)出現(xiàn) ASK 重定向，代表不確定該 key 是否遷移完成，需要通信部去四掌門那里問一下。

當(dāng)請(qǐng)求的 slot 發(fā)生遷移時(shí)，redis-cluster 交互時(shí)序圖如下：

首先，通信部成員根據(jù) slot 5000 和武功秘籍的唯一標(biāo)識(shí) key1 屁顛屁顛去找大掌門索要武功秘籍，但是大掌門說：這個(gè) key1 對(duì)應(yīng)的武功秘籍找不到，我這會(huì)在做秘籍遷移呢，我先看下 slot 5000 秘籍庫的鑰匙有沒有在我這里吧：

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

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

• 如果是 ASK 異常，則發(fā)送 ASK 命令到 master4 節(jié)點(diǎn)建連，再執(zhí)行 key 命令：如果存在則執(zhí)行返回?cái)?shù)據(jù)，不存在則返回不存在信息；
• 如果是 MOVED 異常，客戶端會(huì)直接去 master4 請(qǐng)求 key 數(shù)據(jù)，并更新本地緩存，后續(xù)訪問同一個(gè) key 的數(shù)據(jù)都去請(qǐng)求 master4 節(jié)點(diǎn) 。

這時(shí)，有小伙伴要問了：都是重定向，MOVED 和 ASK 有什么實(shí)質(zhì)性區(qū)別嗎？

其實(shí)，和 HTTP 請(qǐng)求里的重定向 301、302 類似，MOVED 和 ASK 就是永久重定向和臨時(shí)重定向的區(qū)別，分別代表 key 已遷移和不確定 key 已遷移的異常狀態(tài)。

4. 小結(jié)

當(dāng)業(yè)務(wù)規(guī)模不斷擴(kuò)展，用戶量和并發(fā)量都很大時(shí)，用主從復(fù)制+哨兵機(jī)制來支撐 Redis 的高可用還是不能解決單機(jī)主實(shí)例的性能問題：比如數(shù)據(jù)響應(yīng)太慢。

同時(shí)，在面對(duì)千萬級(jí)甚至億萬級(jí)的數(shù)據(jù)流量時(shí)，利用分治法來進(jìn)行實(shí)例擴(kuò)展尤為重要。

而 Redis 集群，不僅原生支持了主從復(fù)制，每個(gè)主節(jié)點(diǎn)都用備用節(jié)點(diǎn)，而且還支持哨兵機(jī)制，當(dāng)某個(gè)主節(jié)點(diǎn)宕機(jī)時(shí)，Cluster 會(huì)自動(dòng)將對(duì)應(yīng)的 Slave 節(jié)點(diǎn)選為 Master，以實(shí)現(xiàn)故障轉(zhuǎn)移。