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

1. 引言

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

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

1.1 自古功夫出少林

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

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

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

這得從頭說起。

1.2 累壞的掌門人

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

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

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

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

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

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

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

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

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

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

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

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

2.1 集群架構(gòu)

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

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

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

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

圖片

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

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

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

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

2.2 集群組建

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

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

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

圖片

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

CLUSTER MEET 127.0.0.2 6379

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

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

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

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

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

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

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

圖片

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

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

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

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

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

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

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

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

slot = CRC16（key）% 16384

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

3. 集群的擴容與訪問

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

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

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

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

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

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

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

圖片

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

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

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

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

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

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

圖片

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

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

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

3.3 slot已遷移，秘籍找誰要

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

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

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

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

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

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

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

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

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

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

4. 小結(jié)

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

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

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