Redis Cluster之故障轉移

1. Redis Cluster 簡介

Redis Cluster 是 Redis 官方提供的 Redis 集群功能。

為什么要實現(xiàn) Redis Cluster？

Redis 是單線程的（從網(wǎng)絡 I/O 處理到實際的讀寫命令處理），無論單核CPU 下內存多大，如果需要大量計算能力，還是需要采用分布式以增加 CPU 資源。

隨著公司發(fā)展，用戶數(shù)量增多，并發(fā)越來越多，業(yè)務需要更高的 QPS，而主從復制中單機的 QPS（10W）可能無法滿足業(yè)務需求。

數(shù)據(jù)量的考慮：現(xiàn)有服務器內存不能滿足業(yè)務數(shù)據(jù)的需要時，單純向服務器添加內存不能達到要求，此時需要考慮分布式需求，把數(shù)據(jù)分布到不同服務器上。

網(wǎng)絡流量需求：業(yè)務的流量已經(jīng)超過服務器的網(wǎng)卡的上限值，可以考慮使用分布式來進行分流。

離線計算，需要中間環(huán)節(jié)緩沖等別的需求。

Redis Cluster 缺點

當節(jié)點數(shù)量很多時，性能不會很高。

解決方案：使用smart智能客戶端操作集群達到通信效率最大化?？蛻舳藘炔控撠熡嬎憔S護鍵，槽以及節(jié)點的映射，用于快速定位到目標節(jié)點。智能客戶端知道由哪個節(jié)點負責管理哪個槽，而且當節(jié)點與槽的映射關系發(fā)生改變時，客戶端也會知道這個改變，這是一種非常高效的方式。

集群的限制

key 批量操作支持有限：例如 mget、mset 必須在一個 slot。

key 事務和 Lua 支持有限：操作的 key 必須在一個節(jié)點。

key 是數(shù)據(jù)分區(qū)的最小粒度：不支持 bigkey 分區(qū)。

不支持多個數(shù)據(jù)庫：集群模式下只有一個 db0。

復制只支持一層：不支持樹形復制結構。

Redis Cluster 滿足容量和性能的擴展性，很多業(yè)務“不需要”。

大多數(shù)時客戶端性能會“降低”。 命令無法跨節(jié)點使用：mget、keys、scan、flush、sinter 等。 Lua 和事務無法跨節(jié)點使用。

客戶端維護更復雜：SDK 和應用本身消耗（例如更多的連接池）。

數(shù)據(jù)分布

為什么要做數(shù)據(jù)分布？

全量數(shù)據(jù)，單機 Redis 節(jié)點無法滿足要求，按照分區(qū)規(guī)則把數(shù)據(jù)分到若干個子集當中。

常用數(shù)據(jù)分布之順序分布

順序分區(qū)常用在關系型數(shù)據(jù)庫的設計。

常用數(shù)據(jù)分布之哈希分布

虛擬槽分區(qū)

虛擬槽分區(qū)是 Redis Cluster 采用的分區(qū)方式。

預設虛擬槽，每個槽就相當于一個數(shù)字，有一定范圍。每個槽映射一個數(shù)據(jù)子集，一般比節(jié)點數(shù)大。

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

每個key 通過 CRC16 校驗后對 16384 取模來決定這個 key 存放在哪個槽（slot）。

步驟：

把 16384 個槽按照節(jié)點數(shù)量進行平均分配，由節(jié)點進行管理。

對每個 key 按照 CRC16 規(guī)則進行 hash 運算。

把 hash 結果對 16383 進行取余。

把余數(shù)發(fā)送給 Redis 節(jié)點。

節(jié)點接收到數(shù)據(jù)，驗證是否在自己管理的槽編號的范圍。

如果在自己管理的槽編號范圍內，則把數(shù)據(jù)保存到數(shù)據(jù)槽中，然后返回執(zhí)行結果。

如果在自己管理的槽編號范圍外，則會把數(shù)據(jù)發(fā)送給正確的節(jié)點，由正確的節(jié)點來把數(shù)據(jù)保存在對應的槽中。

需要注意的是：Redis Cluster 的節(jié)點之間會共享消息，每個節(jié)點都會知道是哪個節(jié)點負責哪個范圍內的數(shù)據(jù)槽。

虛擬槽分布方式中，由于每個節(jié)點管理一部分數(shù)據(jù)槽，數(shù)據(jù)保存到數(shù)據(jù)槽中。當節(jié)點擴容或者縮容時，對數(shù)據(jù)槽進行重新分配遷移即可，數(shù)據(jù)不會丟失。

虛擬槽分區(qū)特點：

使用服務端管理節(jié)點、槽、數(shù)據(jù)。例如 Redis Cluster。

可以對數(shù)據(jù)打散，又可以保證數(shù)據(jù)分布均勻

2. Redis Cluster 架構

1）節(jié)點

Redis Cluster 是分布式架構的：即 Redis Cluster 中有多個節(jié)點，每個節(jié)點都負責進行數(shù)據(jù)讀寫操作。

每個節(jié)點之間會進行通信。

2）meet 操作

meet 操作是節(jié)點之間完成相互通信的基礎，meet 操作有一定的頻率和規(guī)則。

所有的 Redis 節(jié)點彼此互連，內部使用二進制協(xié)議優(yōu)化傳輸速度和帶寬。

客戶端與 Redis 節(jié)點直連，不需要中間 proxy 層?？蛻舳瞬恍枰B接集群所有節(jié)點，連接集群中任何一個可用節(jié)點即可。

3）分配槽

把 16384 個槽平均分配給節(jié)點進行管理，每個節(jié)點只能對自己負責的槽進行讀寫操作。

由于每個節(jié)點之間都彼此通信，每個節(jié)點都知道其他節(jié)點負責管理的槽范圍。

客戶端訪問任意節(jié)點時，對數(shù)據(jù) key 按照 CRC16 規(guī)則進行 hash 運算，然后將運算結果對 16383 進行取余，如果余數(shù)在當前訪問的節(jié)點管理的槽范圍內，則直接返回對應的數(shù)據(jù)
如果不在當前節(jié)點負責管理的槽范圍內，則會告訴客戶端去哪個節(jié)點獲取數(shù)據(jù)，由客戶端去正確的節(jié)點獲取數(shù)據(jù)。

4）復制

Cluster 自動做 master+slave 的主從復制和讀寫分離、master+slave 高可用和主備切換、支持多個 master 的 hash slot 即數(shù)據(jù)分布式存儲。

3. 故障轉移

集群自動故障轉移過程分為故障發(fā)現(xiàn)和節(jié)點恢復。節(jié)點下線分為主觀下線和客觀下線：

當超過半數(shù)的主節(jié)點（master）認為故障節(jié)點為主觀下線時，則標記這個節(jié)點為客觀下線狀態(tài)。

從節(jié)點（slave）負責對客觀下線的主節(jié)點（master）觸發(fā)故障恢復流程，保證集群的可用性。

節(jié)點失效機制：選舉

ping/pong 模式

Redis Cluster 通過 ping/pong 消息實現(xiàn)故障發(fā)現(xiàn)。

ping/pong 不僅能傳遞節(jié)點與槽的對應消息，也能傳遞其他狀態(tài)，比如：節(jié)點主從狀態(tài)，節(jié)點故障等。

故障發(fā)現(xiàn)就是通過這種模式來實現(xiàn)，分為主觀下線和客觀下線。

集群中所有 master 參與投票，如果半數(shù)以上 master 節(jié)點與其中一個 master 節(jié)點通信超時（cluster-node-timeout），則認為該 master 節(jié)點掛掉。

什么時候整個集群不可用（cluster_state：fail）？

如果集群任意 master 掛掉，且當前 master 沒有 slave，則集群進入 fail 狀態(tài)。也可以理解成集群的 [0-16383] slot 映射不完全時進入 fail 狀態(tài)。

如果集群超過半數(shù)以上 master 掛掉，無論是否有 slave，集群進入 fail 狀態(tài)。

鏈接：https://www.cnblogs.com/juno3550/p/14840433.html