建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是小，一個漂泊江湖多年的 985 非科班程序員，曾混跡于國企、互聯(lián)網(wǎng)大廠和創(chuàng)業(yè)公司的后臺開發(fā)攻城獅。
1. 引言
前面我們已經(jīng)聊過 Redis 的主從同步（復制）和哨兵機制，這期我們來聊 Redis 的集群模式。
但是在超大規(guī)模的互聯(lián)網(wǎng)應用中，業(yè)務規(guī)模不斷擴展，用戶量持續(xù)增多時，原有的主從+哨兵機制已經(jīng)不滿足我們的需求了。如：性能問題，數(shù)據(jù)量過多、并發(fā)量過高導致 Redis 服務器響應太慢。
1.1 自古功夫出少林
如果把 Redis 比作江湖里的門派，少林寺作為武林中最有威望的名門正派，提供了武功秘籍（緩存數(shù)據(jù)）的存儲服務。
由于少林存儲的可用性做的很好，武功秘籍幾乎不會丟失。而且，每次去獲取武林同道的秘籍時，響應也很快，所以少林威望不斷提升，后得千古美譽：“自古功夫出少林”。
少林的武功秘籍存儲方案為什么這么穩(wěn)定呢？
這得從頭說起。
1.2 累壞的掌門人
在武林大會 3.0 之前，已經(jīng)有很多武林同道在少林寺存取武功秘籍了，而少林掌門作為權力的中心，不僅披星戴月和外賓打交道（Client 請求），還得在管理物資之余（數(shù)據(jù)存儲和輸出）給副掌門做業(yè)務培訓（數(shù)據(jù)備份）。
雖然在武林大會 2.8 時，少林和武當一樣，已經(jīng)新增了哨兵部門，從此不用擔心掌門嗝屁的問題。
詳見上一篇文章：深入淺出Redis高可用：哨兵機制
但掌門人日理萬機，應接不暇，還是把頭發(fā)都愁掉了！
為了掩飾尷尬，從此少林弟子不準留頭發(fā)
這時可能有小伙伴產(chǎn)生疑問了，性能不好，那就加 CPU、加內(nèi)存或者網(wǎng)絡帶寬唄？！
只能說太天真！當數(shù)據(jù)量增大、并發(fā)增高時，一味地增加 Redis 服務器的CPU、內(nèi)存和網(wǎng)絡帶寬，往往不能起到很好的優(yōu)化效果。
畢竟，服務器也和人的體能極限一樣，不是吃得越多，就可以干活越快的。
而縱向擴展不管用，我們就只能考慮橫向擴展了：團結就是力量，一個人忙不過來，那就再來十個。
于是乎，今天的主角——Redis 集群模式應時而生。
2. 集群模式：分權
Redis3.0 之后，加入了 Redis 集群模式，即 Redis Cluster：可以自動在多個節(jié)點上分布數(shù)據(jù)，節(jié)點間的數(shù)據(jù)能共享，也能動態(tài)地調(diào)整數(shù)據(jù)分布。
2.1 集群架構
Redis 集群采用去中心化的思想，沒有中心節(jié)點的說法。
對于客戶端來說，整個集群可以看成是一個整體，可以連接任意的節(jié)點進行數(shù)據(jù)操作，就像操作單實例 Redis 一樣，也不需要任何的代理中間件。
少林掌門：幫手來了，不用一個人掉頭發(fā)了！
最重要的是，Redis 集群具有高可用性，支持多個 master 節(jié)點，每個 master 節(jié)點都可以掛載多個 slave 節(jié)點，當 master 節(jié)點掛掉以后，集群會選出一個新的 master 節(jié)點。
圖片
自武林大會 3.0 以來，少林為了解決事務變多，掌門人疲于應對的問題，引入了多掌門模式：每個掌門平級，共同處理門派事務，也可以發(fā)展自己的副掌門，以作平替。
當有新的外賓訪問時，會首先通過少林寺通信部（Client）來將請求轉發(fā)給各掌門，再分別處理。
相當于一個人的活可以數(shù)以千計個人一起干，不得不說，這很強！
那這個過程是如何建立起來的呢？
2.2 集群組建
首先，少林會選出多個掌門人（根據(jù)武林秘籍的數(shù)量決定），然后找一個掌門人負責集群組建的主持工作。
武林規(guī)定，一個門派不超過 1000 個掌門人：master 節(jié)點個數(shù)盡量在 1000 個以下
假設我們用三個 master 節(jié)點作為集群成員，它們的建連過程如下圖所示：
圖片
為了提升工作效率，掌門人之間需要加群方便溝通，在 Redis 中，master1 可以向 master2 節(jié)點發(fā)送以下命令建連：
CLUSTER MEET 127.0.0.2 6379
當 master2 節(jié)點回復響應時，一個 Redis Cluster 便組建成功了。
群聊組建成功后，掌門人們便開始各自管理事務。但少林存放的武林秘籍這么多，每個掌門該如何分配管理呢？
2.3 集群數(shù)據(jù)分片
在少林里，有專門的算法機制以及秘籍庫來管理武林秘籍。
首先：將每本武功秘籍都賦予一個唯一標識，并將唯一標識分類后放到不同的秘籍庫，然后交由不同的掌門人進行管理。
其中：算法機制用的是 CRC16，秘籍庫有 16384 個
結合集群中各 master 節(jié)點的交互包大小、節(jié)點數(shù)量的最大值來考量：Redis 官方將集群中所有的數(shù)據(jù)劃分到 16384（2 的 14 次方）個哈希槽（slots）里面，每個 master 節(jié)點管理一部分 slot。
圖片
當 master 節(jié)點數(shù)為 N 時，每個節(jié)點的哈希槽（slot）個數(shù)為 16384/N 個，基本保證均勻分布。
當然，這是可以人為控制的，如果某個節(jié)點的性能較好，就可以多分配一些 slot。命令如下：
redis-cli -h 127.0.0.1 -p 6379 cluster addslots 0, 5460
能者多勞，這在掌門人之間也達成了共識。
2.4 數(shù)據(jù)存取流程
我們知道，江湖中每天都會新增不可計數(shù)的武林秘籍，而少林要求這些武林秘籍都有一個唯一標識 key，真實的秘籍信息存放在 value 里面。
少林會根據(jù) key 的不同，將它們歸為不同的秘籍庫，然后再根據(jù)秘籍庫的編號，讓不同的掌門人分屬管理。
當對秘籍進行存取時，少林通信部會使用 CRC16 算法對秘籍 key 進行計算并對 16384 取模，得到的結果就是這個武功秘籍存放的秘籍庫 slot：
slot = CRC16（key）% 16384
然后，通信部會根據(jù)掌門人群組返回的 {slot，Redis實例IP} 映射表，通過秘籍庫 ID 去找到對應的掌門人住址，最后向此掌門人存儲或索要 key 對應的武功秘籍 value。
3. 集群的擴容與訪問
這時，有聰明的武林同道發(fā)現(xiàn)了問題：既然秘籍庫的數(shù)量是固定的 16384，當少林寺新增掌門人時，豈不是沒有秘籍庫可以管理了？
這個問題很好，當哈希 slot 已經(jīng)被分配完畢，并已經(jīng)存儲數(shù)據(jù)時，如果后續(xù)在線上需要新增 master 節(jié)點，那新增的哈希 slot 從哪里來呢？
既然蛋糕不會變大，那只能把現(xiàn)有的蛋糕分出來了。
怎么分？那當然是一人分一點出來！大家都不愿意吃虧，所以分出來的地盤盡可能相同。
3.1 數(shù)據(jù)遷移：一人分一點
當少林寺宣布要新增一個四掌門時，大家紛紛開始工作。
首先，三個掌門首先會劃出一部分秘籍庫出來，準備移交到四掌門管轄。
圖片
確定好遷移的秘籍庫后，通信部會做以下幾件事：
- 對目標節(jié)點（即四掌門：127.0.0.4: 6385）發(fā)送 cluster setslot {slot} importing 127.0.0.4 命令，讓目標節(jié)點準備導入槽數(shù)據(jù)；
- 對源節(jié)點（大掌門、二掌門、三掌門 3 個節(jié)點）發(fā)送 cluster setslot {slot} migrating 127.0.0.4 命令，讓源節(jié)點準備遷出槽數(shù)據(jù)；
- 源節(jié)點上循環(huán)執(zhí)行 cluster getkeysinslot {slot} {count} 命令，獲取 count 個數(shù)據(jù)槽 {slot} 的 key；
- 在源節(jié)點上執(zhí)行 migrate 127.0.0.1 6379 key 0 {timeout} 命令將指定的 key 進行遷移。
重復 3,4 步驟直到槽下所有的鍵值數(shù)據(jù)遷移到目標節(jié)點。
當遷移結束后，向集群中所有的主節(jié)點發(fā)送通知，slot 集合已經(jīng)分配給了目標節(jié)點。
3.2 數(shù)據(jù)訪問：秘籍怎么取
上面我們已經(jīng)說過了，在少林寺存儲的武林秘籍由各掌門共同處理。那么，當外賓想要獲取存儲的秘籍時，該如何獲取呢？
圖片
如上圖所示，當 Client 首次訪問 Redis 時，會經(jīng)過三個步驟：
- 客戶端（Client）連接某個實例，獲取到 slots 和實例節(jié)點的映射關系，并將這個映射關系存儲在本地緩存；
- 將需要存取的 key 經(jīng)過 CRC16 計算后，再用 16384 對其取模，獲取 slot 的值；
- 根據(jù)映射表得到 slot 對應的實例，將 key 存取的請求發(fā)送到這個實例上進行操作。
正常訪問是這個流程，但如果新增節(jié)點后，key 對應的 slot 被遷移了怎么辦呢？
3.3 slot已遷移，秘籍找誰要
當通信部第一次訪問秘籍 key1 時，計算得出 slot(key1) = 5000，然后被掌門人群組告知：這個 slot 5000 對應的武功秘籍存放在大掌門那里，于是通信部將 {slot=5000, 大掌門} 這個映射信息存了下來。
但是，當客戶端第二次訪問 key1 時，slot 5000 已經(jīng)被大掌門分給了四掌門，由于秘籍遷移的過程需要一定的時間，所以分兩種情況討論：
- 如果 slot 遷移已經(jīng)結束，就會出現(xiàn) MOVED 重定向，代表數(shù)據(jù)已經(jīng)轉移了；
- 如果 slot 正在遷移，就會出現(xiàn) ASK 重定向，代表不確定該 key 是否遷移完成，需要通信部去四掌門那里問一下。
當請求的 slot 發(fā)生遷移時，redis-cluster 交互時序圖如下：
首先，通信部成員根據(jù) slot 5000 和武功秘籍的唯一標識 key1 屁顛屁顛去找大掌門索要武功秘籍，但是大掌門說：這個 key1 對應的武功秘籍找不到，我這會在做秘籍遷移呢，我先看下 slot 5000 秘籍庫的鑰匙有沒有在我這里吧：
- 鑰匙還在，說明遷移正在進行，則 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 有什么實質性區(qū)別嗎？
其實，和 HTTP 請求里的重定向 301、302 類似，MOVED 和 ASK 就是永久重定向和臨時重定向的區(qū)別，分別代表 key 已遷移和不確定 key 已遷移的異常狀態(tài)。
4. 小結
當業(yè)務規(guī)模不斷擴展，用戶量和并發(fā)量都很大時，用主從復制+哨兵機制來支撐 Redis 的高可用還是不能解決單機主實例的性能問題：比如數(shù)據(jù)響應太慢。
同時，在面對千萬級甚至億萬級的數(shù)據(jù)流量時，利用分治法來進行實例擴展尤為重要。
而 Redis 集群，不僅原生支持了主從復制，每個主節(jié)點都用備用節(jié)點，而且還支持哨兵機制，當某個主節(jié)點宕機時，Cluster 會自動將對應的 Slave 節(jié)點選為 Master，以實現(xiàn)故障轉移。
網(wǎng)站欄目：Redis高可用：武林秘籍存在集群里，那穩(wěn)了~
文章地址：http://www.5511xx.com/article/dhpgdhh.html
