1. Redis Cluster 簡介

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

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

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

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

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

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

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

Redis Cluster 缺點

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

解決方案：使用smart智能客戶端操作集群達(dá)到通信效率最大化?？蛻舳藘?nèi)部負(fù)責(zé)計算維護(hù)鍵，槽以及節(jié)點的映射，用于快速定位到目標(biāo)節(jié)點。智能客戶端知道由哪個節(jié)點負(fù)責(zé)管理哪個槽，而且當(dāng)節(jié)點與槽的映射關(guān)系發(fā)生改變時，客戶端也會知道這個改變，這是一種非常高效的方式。

集群的限制

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

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

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

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

復(fù)制只支持一層：不支持樹形復(fù)制結(jié)構(gòu)。

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

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

客戶端維護(hù)更復(fù)雜：SDK 和應(yīng)用本身消耗（例如更多的連接池）。

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

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

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

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

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

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

虛擬槽分區(qū)

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

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

Redis Cluster 中預(yù)設(shè)虛擬槽的范圍為 0 到 16383

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

步驟：

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

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

把 hash 結(jié)果對 16383 進(jìn)行取余。

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

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

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

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

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

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

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

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

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

2. Redis Cluster 架構(gòu)

1）節(jié)點

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

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

2）meet 操作

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

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

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

3）分配槽

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

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

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

4）復(fù)制

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

3. 故障轉(zhuǎn)移

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

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

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

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

ping/pong 模式

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

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

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

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

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

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

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

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