1.Redis Cluster的基本概念

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

[[284726]]

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

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

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

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

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

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

如果單實例作為主存，那么問題就比較大了，因為涉及到持久化問題，無論是bgsave還是aof都會造成刷盤阻塞，此時造成服務(wù)請求成功率下降，這個并不是單實例可以解決的，因為由于作為主存儲，持久化是必須的。

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

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

• 集群與分片

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

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

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

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

• 中間層分片的集群版Redis

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

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

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

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

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

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

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

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

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

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

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

2.Redis Cluster的基本運行原理

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

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

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

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

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

• Gossip協(xié)議的概念

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

在分布式系統(tǒng)中被廣泛使用，比如我們可以使用 gossip 協(xié)議來確保網(wǎng)絡(luò)中所有節(jié)點的數(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é)點的數(shù)量增加，每個節(jié)點的負(fù)載也不會增加很多，幾乎是恒定的。這就允許Consul管理的集群規(guī)模能橫向擴(kuò)展到數(shù)千個節(jié)點。

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

上面的描述都比較學(xué)術(shù)，其實Gossip協(xié)議對于我們吃瓜群眾來說一點也不陌生，Gossip協(xié)議也成為流言協(xié)議，說白了就是八卦協(xié)議，這種傳播規(guī)模和傳播速度都是非?？斓模憧梢泽w會一下。所以計算機中的很多算法都是源自生活，而又高于生活的。

• Gossip協(xié)議的使用

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

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

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

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

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

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

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

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

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

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

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

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

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

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