1.Redis Cluster的基本概念

集群版的Redis聽起來很高大上，確實(shí)相比單實(shí)例一主一從或者一主多從模式來說復(fù)雜了許多，互聯(lián)網(wǎng)的架構(gòu)總是隨著業(yè)務(wù)的發(fā)展不斷演進(jìn)的。

[[284726]]

• 單實(shí)例Redis架構(gòu)

最開始的一主N從加上讀寫分離，Redis作為緩存單實(shí)例貌似也還不錯(cuò)，并且有Sentinel哨兵機(jī)制，可以實(shí)現(xiàn)主從故障遷移。

單實(shí)例一主兩從+讀寫分離結(jié)構(gòu):

注:圖片來自網(wǎng)絡(luò)

單實(shí)例的由于本質(zhì)上只有一臺(tái)Master作為存儲(chǔ)，就算機(jī)器為128GB的內(nèi)存，一般建議使用率也不要超過70%-80%，所以最多使用100GB數(shù)據(jù)就已經(jīng)很多了，實(shí)際中50%就不錯(cuò)了，以為數(shù)據(jù)量太大也會(huì)降低服務(wù)的穩(wěn)定性，因?yàn)閿?shù)據(jù)量太大意味著持久化成本高，可能嚴(yán)重阻塞服務(wù)，甚至最終切主。

如果單實(shí)例只作為緩存使用，那么除了在服務(wù)故障或者阻塞時(shí)會(huì)出現(xiàn)緩存擊穿問題，可能會(huì)有很多請(qǐng)求一起搞死MySQL。

如果單實(shí)例作為主存，那么問題就比較大了，因?yàn)樯婕暗匠志没瘑栴}，無論是bgsave還是aof都會(huì)造成刷盤阻塞，此時(shí)造成服務(wù)請(qǐng)求成功率下降，這個(gè)并不是單實(shí)例可以解決的，因?yàn)橛捎谧鳛橹鞔鎯?chǔ)，持久化是必須的。

所以我們期待一個(gè)多主多從的Redis系統(tǒng)，這樣無論作為主存還是作為緩存，壓力和穩(wěn)定性都會(huì)提升，盡管如此，筆者還是建議：

如果你一意孤行，那么要么坑了自己，要么坑了別人。

• 集群與分片

要支持集群首先要克服的就是分片問題，也就是一致性哈希問題，常見的方案有三種：

客戶端分片：這種情況主要是類似于哈希取模的做法，當(dāng)客戶端對(duì)服務(wù)端的數(shù)量完全掌握和控制時(shí)，可以簡(jiǎn)單使用。

中間層分片：這種情況是在客戶端和服務(wù)器端之間增加中間層，充當(dāng)管理者和調(diào)度者，客戶端的請(qǐng)求打向中間層，由中間層實(shí)現(xiàn)請(qǐng)求的轉(zhuǎn)發(fā)和回收，當(dāng)然中間層最重要的作用是對(duì)多臺(tái)服務(wù)器的動(dòng)態(tài)管理。

服務(wù)端分片：不使用中間層實(shí)現(xiàn)去中心化的管理模式，客戶端直接向服務(wù)器中任意結(jié)點(diǎn)請(qǐng)求，如果被請(qǐng)求的Node沒有所需數(shù)據(jù)，則像客戶端回復(fù)MOVED，并告訴客戶端所需數(shù)據(jù)的存儲(chǔ)位置，這個(gè)過程實(shí)際上是客戶端和服務(wù)端共同配合，進(jìn)行請(qǐng)求重定向來完成的。

• 中間層分片的集群版Redis

前面提到了變?yōu)镹主N從可以有效提高處理能力和穩(wěn)定性，但是這樣就面臨一致性哈希的問題，也就是動(dòng)態(tài)擴(kuò)縮容時(shí)的數(shù)據(jù)問題。

在Redis官方發(fā)布集群版本之前，業(yè)內(nèi)有一些方案迫不及待要用起自研版本的Redis集群，其中包括國內(nèi)豌豆莢的Codis、國外Twiter的twemproxy。

核心思想都是在多個(gè)Redis服務(wù)器和客戶端Client中間增加分片層，由分片層來完成數(shù)據(jù)的一致性哈希和分片問題，每一家的做法有一定的區(qū)別，但是要解決的核心問題都是多臺(tái)Redis場(chǎng)景下的擴(kuò)縮容、故障轉(zhuǎn)移、數(shù)據(jù)完整性、數(shù)據(jù)一致性、請(qǐng)求處理延時(shí)等問題。

業(yè)內(nèi)Codis配合LVS等多種做法實(shí)現(xiàn)Redis集群的方案有很多都應(yīng)用到生成環(huán)境中，表現(xiàn)都還不錯(cuò)，主要是官方集群版本在Redis3.0才出現(xiàn)，對(duì)其穩(wěn)定性如何，很多公司都不愿做小白鼠，不過事實(shí)上經(jīng)過迭代目前已經(jīng)到了Redis5.x版本，官方集群版本還是很不錯(cuò)的，至少筆者這么認(rèn)為。

• 服務(wù)端分片的官方集群版本

官方版本區(qū)別于上面的Codis和Twemproxy，實(shí)現(xiàn)了服務(wù)器層的Sharding分片技術(shù)，換句話說官方?jīng)]有中間層，而是多個(gè)服務(wù)結(jié)點(diǎn)本身實(shí)現(xiàn)了分片，當(dāng)然也可以認(rèn)為實(shí)現(xiàn)sharding的這部分功能被融合到了Redis服務(wù)本身中，并沒有單獨(dú)的Sharding模塊。

之前的文章也提到了官方集群引入slot的概念進(jìn)行數(shù)據(jù)分片，之后將數(shù)據(jù)slot分配到多個(gè)Master結(jié)點(diǎn)，Master結(jié)點(diǎn)再配置N個(gè)從結(jié)點(diǎn)，從而組成了多實(shí)例sharding版本的官方集群架構(gòu)。

Redis Cluster 是一個(gè)可以在多個(gè) Redis 節(jié)點(diǎn)之間進(jìn)行數(shù)據(jù)共享的分布式集群，在服務(wù)端，通過節(jié)點(diǎn)之間的特殊協(xié)議進(jìn)行通訊，這個(gè)特殊協(xié)議就充當(dāng)了中間層的管理部分的通信協(xié)議，這個(gè)協(xié)議稱作Gossip流言協(xié)議。

分布式系統(tǒng)一致性協(xié)議的目的就是為了解決集群中多結(jié)點(diǎn)狀態(tài)通知的問題，是管理集群的基礎(chǔ)。

如圖展示了基于Gossip協(xié)議的官方集群架構(gòu)圖：

注:圖片來自網(wǎng)絡(luò)

2.Redis Cluster的基本運(yùn)行原理

• 結(jié)點(diǎn)狀態(tài)信息結(jié)構(gòu)

Cluster中的每個(gè)節(jié)點(diǎn)都維護(hù)一份在自己看來當(dāng)前整個(gè)集群的狀態(tài)，主要包括：

• 當(dāng)前集群狀態(tài)
• 集群中各節(jié)點(diǎn)所負(fù)責(zé)的slots信息，及其migrate狀態(tài)
• 集群中各節(jié)點(diǎn)的master-slave狀態(tài)
• 集群中各節(jié)點(diǎn)的存活狀態(tài)及不可達(dá)投票

也就是說上面的信息，就是集群中Node相互八卦傳播流言蜚語的內(nèi)容主題，而且比較全面，既有自己的更有別人的，這么一來大家都相互傳，最終信息就全面而且準(zhǔn)確了，區(qū)別于拜占庭帝國問題，信息的可信度很高。

基于Gossip協(xié)議當(dāng)集群狀態(tài)變化時(shí)，如新節(jié)點(diǎn)加入、slot遷移、節(jié)點(diǎn)宕機(jī)、slave提升為新Master，我們希望這些變化盡快的被發(fā)現(xiàn)，傳播到整個(gè)集群的所有節(jié)點(diǎn)并達(dá)成一致。節(jié)點(diǎn)之間相互的心跳(PING，PONG，MEET)及其攜帶的數(shù)據(jù)是集群狀態(tài)傳播最主要的途徑。

• Gossip協(xié)議的概念

gossip 協(xié)議(gossip protocol)又稱 epidemic 協(xié)議(epidemic protocol)，是基于流行病傳播方式的節(jié)點(diǎn)或者進(jìn)程之間信息交換的協(xié)議。

在分布式系統(tǒng)中被廣泛使用，比如我們可以使用 gossip 協(xié)議來確保網(wǎng)絡(luò)中所有節(jié)點(diǎn)的數(shù)據(jù)一樣。

gossip protocol 最初是由施樂公司帕洛阿爾托研究中心(Palo Alto Research Center)的研究員艾倫·德默斯(Alan Demers)于1987年創(chuàng)造的。https://www.iteblog.com/archives/2505.html

Gossip協(xié)議已經(jīng)是P2P網(wǎng)絡(luò)中比較成熟的協(xié)議了。Gossip協(xié)議的最大的好處是，即使集群節(jié)點(diǎn)的數(shù)量增加，每個(gè)節(jié)點(diǎn)的負(fù)載也不會(huì)增加很多，幾乎是恒定的。這就允許Consul管理的集群規(guī)模能橫向擴(kuò)展到數(shù)千個(gè)節(jié)點(diǎn)。

Gossip算法又被稱為反熵(Anti-Entropy)，熵是物理學(xué)上的一個(gè)概念，代表雜亂無章，而反熵就是在雜亂無章中尋求一致，這充分說明了Gossip的特點(diǎn)：在一個(gè)有界網(wǎng)絡(luò)中，每個(gè)節(jié)點(diǎn)都隨機(jī)地與其他節(jié)點(diǎn)通信，經(jīng)過一番雜亂無章的通信，最終所有節(jié)點(diǎn)的狀態(tài)都會(huì)達(dá)成一致。每個(gè)節(jié)點(diǎn)可能知道所有其他節(jié)點(diǎn)，也可能僅知道幾個(gè)鄰居節(jié)點(diǎn)，只要這些節(jié)可以通過網(wǎng)絡(luò)連通，最終他們的狀態(tài)都是一致的，當(dāng)然這也是疫情傳播的特點(diǎn)。https://www.backendcloud.cn/2017/11/12/raft-gossip/

上面的描述都比較學(xué)術(shù)，其實(shí)Gossip協(xié)議對(duì)于我們吃瓜群眾來說一點(diǎn)也不陌生，Gossip協(xié)議也成為流言協(xié)議，說白了就是八卦協(xié)議，這種傳播規(guī)模和傳播速度都是非常快的，你可以體會(huì)一下。所以計(jì)算機(jī)中的很多算法都是源自生活，而又高于生活的。

• Gossip協(xié)議的使用

Redis 集群是去中心化的，彼此之間狀態(tài)同步靠 gossip 協(xié)議通信，集群的消息有以下幾種類型：

1. Meet 通過「cluster meet ip port」命令，已有集群的節(jié)點(diǎn)會(huì)向新的節(jié)點(diǎn)發(fā)送邀請(qǐng)，加入現(xiàn)有集群。
2. Ping 節(jié)點(diǎn)每秒會(huì)向集群中其他節(jié)點(diǎn)發(fā)送 ping 消息，消息中帶有自己已知的兩個(gè)節(jié)點(diǎn)的地址、槽、狀態(tài)信息、最后一次通信時(shí)間等。
3. Pong 節(jié)點(diǎn)收到 ping 消息后會(huì)回復(fù) pong 消息，消息中同樣帶有自己已知的兩個(gè)節(jié)點(diǎn)信息。
4. Fail 節(jié)點(diǎn) ping 不通某節(jié)點(diǎn)后，會(huì)向集群所有節(jié)點(diǎn)廣播該節(jié)點(diǎn)掛掉的消息。其他節(jié)點(diǎn)收到消息后標(biāo)記已下線。

由于去中心化和通信機(jī)制，Redis Cluster 選擇了最終一致性和基本可用。

例如當(dāng)加入新節(jié)點(diǎn)時(shí)(meet)，只有邀請(qǐng)節(jié)點(diǎn)和被邀請(qǐng)節(jié)點(diǎn)知道這件事，其余節(jié)點(diǎn)要等待 ping 消息一層一層擴(kuò)散。除了 Fail 是立即全網(wǎng)通知的，其他諸如新節(jié)點(diǎn)、節(jié)點(diǎn)重上線、從節(jié)點(diǎn)選舉成為主節(jié)點(diǎn)、槽變化等，都需要等待被通知到，也就是Gossip協(xié)議是最終一致性的協(xié)議。

由于 gossip 協(xié)議對(duì)服務(wù)器時(shí)間的要求較高，否則時(shí)間戳不準(zhǔn)確會(huì)影響節(jié)點(diǎn)判斷消息的有效性。另外節(jié)點(diǎn)數(shù)量增多后的網(wǎng)絡(luò)開銷也會(huì)對(duì)服務(wù)器產(chǎn)生壓力，同時(shí)結(jié)點(diǎn)數(shù)太多，意味著達(dá)到最終一致性的時(shí)間也相對(duì)變長(zhǎng)，因此官方推薦最大節(jié)點(diǎn)數(shù)為1000左右。如圖展示了新加入結(jié)點(diǎn)服務(wù)器時(shí)的通信交互圖：

注:圖片來自網(wǎng)絡(luò)

總起來說Redis官方集群是一個(gè)去中心化的類P2P網(wǎng)絡(luò)，P2P早些年非常流行，像電驢、BT什么的都是P2P網(wǎng)絡(luò)。在Redis集群中Gossip協(xié)議充當(dāng)了去中心化的通信協(xié)議的角色，依據(jù)制定的通信規(guī)則來實(shí)現(xiàn)整個(gè)集群的無中心管理節(jié)點(diǎn)的自治行為。

• 基于Gossip協(xié)議的故障檢測(cè)

集群中的每個(gè)節(jié)點(diǎn)都會(huì)定期地向集群中的其他節(jié)點(diǎn)發(fā)送PING消息，以此交換各個(gè)節(jié)點(diǎn)狀態(tài)信息，檢測(cè)各個(gè)節(jié)點(diǎn)狀態(tài)：在線狀態(tài)、疑似下線狀態(tài)PFAIL、已下線狀態(tài)FAIL。

自己保存信息：當(dāng)主節(jié)點(diǎn)A通過消息得知主節(jié)點(diǎn)B認(rèn)為主節(jié)點(diǎn)D進(jìn)入了疑似下線(PFAIL)狀態(tài)時(shí),主節(jié)點(diǎn)A會(huì)在自己的clusterState.nodes字典中找到主節(jié)點(diǎn)D所對(duì)應(yīng)的clusterNode結(jié)構(gòu)，并將主節(jié)點(diǎn)B的下線報(bào)告添加到clusterNode結(jié)構(gòu)的fail_reports鏈表中，并后續(xù)關(guān)于結(jié)點(diǎn)D疑似下線的狀態(tài)通過Gossip協(xié)議通知其他節(jié)點(diǎn)。

一起裁定：如果集群里面，半數(shù)以上的主節(jié)點(diǎn)都將主節(jié)點(diǎn)D報(bào)告為疑似下線，那么主節(jié)點(diǎn)D將被標(biāo)記為已下線(FAIL)狀態(tài)，將主節(jié)點(diǎn)D標(biāo)記為已下線的節(jié)點(diǎn)會(huì)向集群廣播主節(jié)點(diǎn)D的FAIL消息，所有收到FAIL消息的節(jié)點(diǎn)都會(huì)立即更新nodes里面主節(jié)點(diǎn)D狀態(tài)標(biāo)記為已下線。

最終裁定：將 node 標(biāo)記為 FAIL 需要滿足以下兩個(gè)條件：

1. 有半數(shù)以上的主節(jié)點(diǎn)將 node 標(biāo)記為 PFAIL 狀態(tài)。
2. 當(dāng)前節(jié)點(diǎn)也將 node 標(biāo)記為 PFAIL 狀態(tài)。

也就是說當(dāng)前節(jié)點(diǎn)發(fā)現(xiàn)其他結(jié)點(diǎn)疑似掛掉了，那么就寫在自己的小本本上，等著通知給其他好基友，讓他們自己也看看，最后又一半以上的好基友都認(rèn)為那個(gè)節(jié)點(diǎn)掛了，并且那個(gè)節(jié)點(diǎn)自己也認(rèn)為自己掛了，那么就是真的掛了，過程還是比較嚴(yán)謹(jǐn)?shù)摹?/p>