1. Redis Cluster 簡(jiǎn)介

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

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

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

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

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

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

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

Redis Cluster 缺點(diǎn)

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

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

集群的限制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

虛擬槽分區(qū)

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

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

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

每個(gè)key 通過 CRC16 校驗(yàn)后對(duì) 16384 取模來決定這個(gè) key 存放在哪個(gè)槽（slot）。

步驟：

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

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

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

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

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

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

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

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

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

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

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

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

2. Redis Cluster 架構(gòu)

1）節(jié)點(diǎn)

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

每個(gè)節(jié)點(diǎn)之間會(huì)進(jìn)行通信。

2）meet 操作

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

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

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

3）分配槽

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

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

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

4）復(fù)制

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

3. 故障轉(zhuǎn)移

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

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

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

節(jié)點(diǎn)失效機(jī)制：選舉

ping/pong 模式

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

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

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

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

什么時(shí)候整個(gè)集群不可用（cluster_state：fail）？

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

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

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