欧美老熟妇人伦人妻6919,午夜激情电影在线视频91

主頁 > 知識庫 > 解析Redis Cluster原理

解析Redis Cluster原理

一、前言

Sentinel集群會對Redis的主從架構(gòu)中的Redis實(shí)例進(jìn)行監(jiān)控，一旦發(fā)現(xiàn)了master節(jié)點(diǎn)宕機(jī)了，就會選舉出一個Sentinel節(jié)點(diǎn)來執(zhí)行故障轉(zhuǎn)移，從原來的slave節(jié)點(diǎn)中選舉出一個，將其提升為master節(jié)點(diǎn)，然后讓其他的節(jié)點(diǎn)去復(fù)制新選舉出來的master節(jié)點(diǎn)。

你可能會覺得這樣沒有問題啊，甚至能夠滿足我們生產(chǎn)環(huán)境的使用需求了，那我們?yōu)槭裁催€需要Redis Cluster呢？

二、為什么需要Redis Cluster

的確，在數(shù)據(jù)上，有replication副本做保證；可用性上，master宕機(jī)會自動的執(zhí)行failover。

那問題在哪兒呢？

首先Redis Sentinel說白了也是基于主從復(fù)制，在主從復(fù)制中slave的數(shù)據(jù)是完全來自于master。

假設(shè)master節(jié)點(diǎn)的內(nèi)存只有4G，那slave節(jié)點(diǎn)所能存儲的數(shù)據(jù)上限也只能是4G。主從復(fù)制架構(gòu)中是讀寫分離的，我們可以通過增加slave節(jié)點(diǎn)來擴(kuò)展主從的讀并發(fā)能力，但是寫能力和存儲能力是無法進(jìn)行擴(kuò)展的，就只能是master節(jié)點(diǎn)能夠承載的上限。

所以，當(dāng)你只需要存儲4G的數(shù)據(jù)時候的，基于主從復(fù)制和基于Sentinel的高可用架構(gòu)是完全夠用的。

但是如果當(dāng)你面臨的是海量的數(shù)據(jù)的時候呢？16G、64G、256G甚至1T呢？現(xiàn)在互聯(lián)網(wǎng)的業(yè)務(wù)里面，如果你的體量足夠大，我覺得是肯定會面臨緩存海量緩存數(shù)據(jù)的場景的。

這就是為什么我們需要引入Redis Cluster。

三、Redis Cluster是什么

知道了為什么需要Redis Cluster之后，我們就可以來對其一探究竟了。

那什么是Redis Cluster呢？

很簡單，你就可以理解為n個主從架構(gòu)組合在一起對外服務(wù)。Redis Cluster要求至少需要3個master才能組成一個集群，同時每個master至少需要有一個slave節(jié)點(diǎn)。

這樣一來，如果一個主從能夠存儲32G的數(shù)據(jù)，如果這個集群包含了兩個主從，則整個集群就能夠存儲64G的數(shù)據(jù)。

我們知道，主從架構(gòu)中，可以通過增加slave節(jié)點(diǎn)的方式來擴(kuò)展讀請求的并發(fā)量，那Redis Cluster中是如何做的呢？雖然每個master下都掛載了一個slave節(jié)點(diǎn)，但是在Redis Cluster中的讀、寫請求其實(shí)都是在master上完成的。

slave節(jié)點(diǎn)只是充當(dāng)了一個數(shù)據(jù)備份的角色，當(dāng)master發(fā)生了宕機(jī)，就會將對應(yīng)的slave節(jié)點(diǎn)提拔為master，來重新對外提供服務(wù)。

四、節(jié)點(diǎn)負(fù)載均衡

知道了什么是Redis Cluster，我們就可以繼續(xù)下面的討論了。

不知道你思考過一個問題沒，這么多的master節(jié)點(diǎn)。我存儲的時候，到底該選擇哪個節(jié)點(diǎn)呢？一般這種負(fù)載均衡算法，會選擇哈希算法。哈希算法是怎么做的呢？

首先就是對key計算出一個hash值，然后用哈希值對master數(shù)量進(jìn)行取模。由此就可以將key負(fù)載均衡到每一個Redis節(jié)點(diǎn)上去。這就是簡單的哈希算法的實(shí)現(xiàn)。

那Redis Cluster是采取的上面的哈希算法嗎？答案是沒有。

Redis Cluster其實(shí)采取的是類似于一致性哈希的算法來實(shí)現(xiàn)節(jié)點(diǎn)選擇的。那為什么不用哈希算法來進(jìn)行實(shí)例選擇呢？以及為什么說是類似的呢？我們繼續(xù)討論。

因?yàn)槿绻藭r某一臺master發(fā)生了宕機(jī)，那么此時會導(dǎo)致Redis中所有的緩存失效。為什么是所有的？假設(shè)之前有3個master，那么之前的算法應(yīng)該是 hash % 3，但是如果其中一臺master宕機(jī)了，則算法就會變成 hash % 2，會影響到之前存儲的所有的key。而這對緩存后面保護(hù)的DB來說，是致命的打擊。

五、什么是一致性哈希

知道了通過傳統(tǒng)哈希算法來實(shí)現(xiàn)對節(jié)點(diǎn)的負(fù)載均衡的弊端，我們就需要進(jìn)一步了解什么是一致性哈希。

我們上面提過哈希算法是對master實(shí)例數(shù)量來取模，而一致性哈希則是對2^32取模，也就是值的范圍在[0, 2^32 -1]。一致性哈希將其范圍抽象成了一個圓環(huán)，使用CRC16算法計算出來的哈希值會落到圓環(huán)上的某個地方。

然后我們的Redis實(shí)例也分布在圓環(huán)上，我們在圓環(huán)上按照順時針的順序找到第一個Redis實(shí)例，這樣就完成了對key的節(jié)點(diǎn)分配。我們舉個例子。

假設(shè)我們有A、B、C三個Redis實(shí)例按照如圖所示的位置分布在圓環(huán)上，此時計算出來的hash值，取模之后位置落在了位置D，那么我們按照順時針的順序，就能夠找到我們這個key應(yīng)該分配的Redis實(shí)例B。同理如果我們計算出來位置在E，那么對應(yīng)選擇的Redis的實(shí)例就是A。

即使這個時候Redis實(shí)例B掛了，也不會影響到實(shí)例A和C的緩存。

例如此時節(jié)點(diǎn)B掛了，那之前計算出來在位置D的key，此時會按照順時針的順序，找到節(jié)點(diǎn)C。相當(dāng)于自動的把原來節(jié)點(diǎn)B的流量給轉(zhuǎn)移到了節(jié)點(diǎn)C上去。而其他原本就在節(jié)點(diǎn)A和節(jié)點(diǎn)C的數(shù)據(jù)則完全不受影響。

這就是一致性哈希，能夠在我們后續(xù)需要新增節(jié)點(diǎn)或者刪除節(jié)點(diǎn)的時候，不影響其他節(jié)點(diǎn)的正常運(yùn)行。

六、虛擬節(jié)點(diǎn)機(jī)制

但是一致性哈希也存在自身的小問題，例如當(dāng)我們的Redis節(jié)點(diǎn)分布如下時，就有問題了。

此時數(shù)據(jù)落在節(jié)點(diǎn)A上的概率明顯是大于其他兩個節(jié)點(diǎn)的，其次落在節(jié)點(diǎn)C上的概率最小。這樣一來會導(dǎo)致整個集群的數(shù)據(jù)存儲不平衡，AB節(jié)點(diǎn)壓力較大，而C節(jié)點(diǎn)資源利用不充分。為了解決這個問題，一致性哈希算法引入了虛擬節(jié)點(diǎn)機(jī)制。

virtual-dom

在圓環(huán)中，增加了對應(yīng)節(jié)點(diǎn)的虛擬節(jié)點(diǎn)，然后完成了虛擬節(jié)點(diǎn)到真實(shí)節(jié)點(diǎn)的映射。假設(shè)現(xiàn)在計算得出了位置D，那么按照順時針的順序，我們找到的第一個節(jié)點(diǎn)就是C #1，最終數(shù)據(jù)實(shí)際還是會落在節(jié)點(diǎn)C上。

通過增加虛擬節(jié)點(diǎn)的方式，使ABC三個節(jié)點(diǎn)在圓環(huán)上的位置更加均勻，平均了落在每一個節(jié)點(diǎn)上的概率。這樣一來就解決了上文提到的數(shù)據(jù)存儲存在不均勻的問題了，這就是一致性哈希的虛擬節(jié)點(diǎn)機(jī)制。

七、Redis Cluster采用的什么算法

上面提到過，Redis Cluster采用的是類一致性哈希算法，之所以是類一致性哈希算法是因?yàn)樗鼈儗?shí)現(xiàn)的方式還略微有差別。

例如一致性哈希是對2^32取模，而Redis Cluster則是對2^14（也就是16384）取模。Redis Cluster將自己分成了16384個Slot（槽位）。通過CRC16算法計算出來的哈希值會跟16384取模，取模之后得到的值就是對應(yīng)的槽位，然后每個Redis節(jié)點(diǎn)都會負(fù)責(zé)處理一部分的槽位，就像下表這樣。

節(jié)點(diǎn)	處理槽位
A	0 - 5000
B	5001 - 10000
C	10001 - 16383

每個Redis實(shí)例會自己維護(hù)一份slot - Redis節(jié)點(diǎn)的映射關(guān)系，假設(shè)你在節(jié)點(diǎn)A上設(shè)置了某個key，但是這個key通過CRC16計算出來的槽位是由節(jié)點(diǎn)B維護(hù)的，那么就會提示你需要去節(jié)點(diǎn)B上進(jìn)行操作。

slot-to-node

八、Redis Cluster如何做到高可用

不知道你思考過一個問題沒，如果Redis Cluster中的某個master節(jié)點(diǎn)掛了，它是如何保證集群自身的高可用的？如果這個時候我們集群需要擴(kuò)容節(jié)點(diǎn)，它該負(fù)責(zé)哪些槽位呢？我們一個一個問題的來看一下。

8.1、集群如何進(jìn)行擴(kuò)容

我們開篇聊過，Redis Cluster可以很方便的進(jìn)行橫向擴(kuò)容，那當(dāng)新的節(jié)點(diǎn)加入進(jìn)來的時候，它是如何獲取對應(yīng)的slot的呢？

答案是通過reshard（重新分片）來實(shí)現(xiàn)。reshard可以將已經(jīng)分配給某個節(jié)點(diǎn)的任意數(shù)量的slot遷移給另一個節(jié)點(diǎn)，在Redis內(nèi)部是由redis-trib負(fù)責(zé)執(zhí)行的。你可以理解為Redis其實(shí)已經(jīng)封裝好了所有的命令，而redis-trib則負(fù)責(zé)向獲取slot的節(jié)點(diǎn)和被轉(zhuǎn)移slot的節(jié)點(diǎn)發(fā)送命令來最終實(shí)現(xiàn)reshard。

假設(shè)我們需要向集群中加入一個D節(jié)點(diǎn)，而此時集群內(nèi)已經(jīng)有A、B、C三個節(jié)點(diǎn)了。

此時redis-trib會向A、B、C三個節(jié)點(diǎn)發(fā)送遷移出槽位的請求，同時向D節(jié)點(diǎn)發(fā)送準(zhǔn)備導(dǎo)入槽位的請求，做好準(zhǔn)備之后A、B、C這三個源節(jié)點(diǎn)就開始執(zhí)行遷移，將對應(yīng)的slot所對應(yīng)的鍵值對遷移至目標(biāo)節(jié)點(diǎn)D。最后redis-trib會向集群中所有主節(jié)點(diǎn)發(fā)送槽位的變更信息。

8.2、高可用及故障轉(zhuǎn)移

Redis Cluster中保證集群高可用的思路和實(shí)現(xiàn)和Redis Sentinel如出一轍

簡單來說，針對A節(jié)點(diǎn)，某一個節(jié)點(diǎn)認(rèn)為A宕機(jī)了，那么此時是主觀宕機(jī)。而如果集群內(nèi)超過半數(shù)的節(jié)點(diǎn)認(rèn)為A掛了，那么此時A就會被標(biāo)記為客觀宕機(jī)。

一旦節(jié)點(diǎn)A被標(biāo)記為了客觀宕機(jī)，集群就會開始執(zhí)行故障轉(zhuǎn)移。其余正常運(yùn)行的master節(jié)點(diǎn)會進(jìn)行投票選舉，從A節(jié)點(diǎn)的slave節(jié)點(diǎn)中選舉出一個，將其切換成新的master對外提供服務(wù)。當(dāng)某個slave獲得了超過半數(shù)的master節(jié)點(diǎn)投票，就成功當(dāng)選。

cluster-failover

當(dāng)選成功之后，新的master會執(zhí)行slaveof no one來讓自己停止復(fù)制A節(jié)點(diǎn)，使自己成為master。然后將A節(jié)點(diǎn)所負(fù)責(zé)處理的slot，全部轉(zhuǎn)移給自己，然后就會向集群發(fā)PONG消息來廣播自己的最新狀態(tài)。

按照一致性哈希的思想，如果某個節(jié)點(diǎn)掛了，那么就會沿著那個圓環(huán)，按照順時針的順序找到遇到的第一個Redis實(shí)例。

而對于Redis Cluster，某個key它其實(shí)并不關(guān)心它最終要去到哪個節(jié)點(diǎn)，他只關(guān)心他最終落到哪個slot上，無論你節(jié)點(diǎn)怎么去遷移，最終還是只需要找到對應(yīng)的slot，然后再找到slot關(guān)聯(lián)的節(jié)點(diǎn)，最終就能夠找到最終的Redis實(shí)例了。

那這個PONG消息又是什么東西呢？別急，下面就會聊到。

九、簡單了解gossip協(xié)議

這就是Redis Cluster各個節(jié)點(diǎn)之間交換數(shù)據(jù)、通信所采用的一種協(xié)議，叫做gossip。

gossip: 流言、八卦、小道消息

gossip是在1989年的論文上提出的，我看了一堆資料都說的是1987年發(fā)表的，但是文章里的時間明確是1989年1月份發(fā)表。

image-20201215100703648

感興趣的可以去看看Epidemic Algorithms for Replicated . Database Maintenance，在當(dāng)時提出gossip主要是為了解決在分布式數(shù)據(jù)庫中，各個副本節(jié)點(diǎn)的數(shù)據(jù)同步問題。但隨著技術(shù)的發(fā)展，gossip后續(xù)也被廣泛運(yùn)用于信息擴(kuò)散、故障探測等等。

Redis Cluster就是利用了gossip來實(shí)現(xiàn)自身的信息擴(kuò)散的。那使用gossip具體是如何通信的呢？

gossip

很簡單，就像圖里這樣。每個Redis節(jié)點(diǎn)每秒鐘都會向其他的節(jié)點(diǎn)發(fā)送PING，然后被PING的節(jié)點(diǎn)會回一個PONG。

十、gossip協(xié)議消息類型

Redis Cluster中，節(jié)點(diǎn)之間的消息類型有5種，分別是MEET、PING、PONG、FAIL和PUBLISH。這些消息分別傳遞了什么內(nèi)容呢？我簡單總結(jié)了一下。

消息類型	消息內(nèi)容
MEET	給某個節(jié)點(diǎn)發(fā)送MEET消息，請求接收消息的節(jié)點(diǎn)加入到集群中
PING	每隔一秒鐘，選擇5個最久沒有通信的節(jié)點(diǎn)，發(fā)送PING消息，檢測對應(yīng)的節(jié)點(diǎn)是否在線；同時還有一種策略是，如果某個節(jié)點(diǎn)的通信延遲大于了cluster-node-time的值的一半，就會立即給該節(jié)點(diǎn)發(fā)送PING消息，避免數(shù)據(jù)交換延遲過久
PONG	當(dāng)節(jié)點(diǎn)接收到MEET或者PING消息之后，會回一個PONG消息給發(fā)送方，代表自己收到了MEET或者PING消息。同時，節(jié)點(diǎn)也可以主動的通過PONG消息向集群中廣播自己的信息，讓其他節(jié)點(diǎn)獲取到自己最新的屬性，就像完成了故障轉(zhuǎn)移之后新的master向集群發(fā)送PONG消息一樣
FAIL	用于廣播自己的對某個節(jié)點(diǎn)的宕機(jī)判斷，假設(shè)當(dāng)前節(jié)點(diǎn)對A節(jié)點(diǎn)判斷為宕機(jī)，就會立即向Redis Cluster廣播自己對于A節(jié)點(diǎn)的判斷，所有收到消息的節(jié)點(diǎn)就會對A節(jié)點(diǎn)做標(biāo)記
PUBLISH	用于向指定的Channel發(fā)送消息，某個節(jié)點(diǎn)收到PUBLISH消息之后會直接在集群內(nèi)廣播，這樣一來，客戶端無論連接到任何節(jié)點(diǎn)都能夠訂閱這個Channel

十一、使用gossip的優(yōu)劣

既然Redis Cluster選擇了gossip，那肯定存在一些gossip的優(yōu)點(diǎn)，我們接下來簡單梳理一下。

優(yōu)點(diǎn)	描述
擴(kuò)展性	網(wǎng)絡(luò)可以允許節(jié)點(diǎn)的任意增加和減少，新增加的節(jié)點(diǎn)的狀態(tài)最終會與其他節(jié)點(diǎn)一致。
容錯性	由于每個節(jié)點(diǎn)都持有一份完整元數(shù)據(jù)，所以任何節(jié)點(diǎn)宕機(jī)都不會影響gossip的運(yùn)行
健壯性	與容錯性類似，由于所有節(jié)點(diǎn)都持有數(shù)據(jù)，地位平臺，是一個去中心化的設(shè)計，任何節(jié)點(diǎn)都不會影響到服務(wù)的運(yùn)行
最終一致性	當(dāng)有新的信息需要傳遞時，消息可以快速的發(fā)送到所有的節(jié)點(diǎn)，讓所有的節(jié)點(diǎn)都擁有最新的數(shù)據(jù)

gossip可以在O(logN) 輪就可以將信息傳播到所有的節(jié)點(diǎn)，為什么是O(logN)呢？因?yàn)槊看蝡ing，當(dāng)前節(jié)點(diǎn)會帶上自己的信息外加整個Cluster的1/10數(shù)量的節(jié)點(diǎn)信息，一起發(fā)送出去。你可以簡單的把這個模型抽象為：

你轉(zhuǎn)發(fā)了一個特別有意思的文章到朋友圈，然后你的朋友們都覺得還不錯，于是就一傳十、十傳百這樣的散播出去了，這就是朋友圈的裂變傳播。

當(dāng)然，gossip仍然存在一些缺點(diǎn)。例如消息可能最終會經(jīng)過很多輪才能到達(dá)目標(biāo)節(jié)點(diǎn)，而這可能會帶來較大的延遲。同時由于節(jié)點(diǎn)會隨機(jī)選出5個最久沒有通信的節(jié)點(diǎn)，這可能會造成某一個節(jié)點(diǎn)同時收到n個重復(fù)的消息。

十二、總結(jié)

總的來說，Redis Cluster相當(dāng)于是把Redis的主從架構(gòu)和Sentinel集成到了一起，從Redis Cluster的高可用機(jī)制、判斷故障轉(zhuǎn)移以及執(zhí)行故障轉(zhuǎn)移的過程，都和主從、Sentinel相關(guān)，這也是為什么我在之前的文章里說，主從是Redis高可用架構(gòu)的基石。

以上就是解析Redis Cluster原理的詳細(xì)內(nèi)容，更多關(guān)于Redis Cluster的資料請關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章:

詳解SpringBoot Redis自適應(yīng)配置(Cluster Standalone Sentinel)
Redis Cluster集群數(shù)據(jù)分片機(jī)制原理
docker redis5.0 cluster集群搭建的實(shí)現(xiàn)
使用Ruby腳本部署Redis Cluster集群步驟講解
php成功操作redis cluster集群的實(shí)例教程
Redis cluster集群的介紹
Windows環(huán)境下Redis Cluster環(huán)境搭建(圖文)
如何用docker部署redis cluster的方法
spring集成redis cluster詳解
Redis Cluster添加、刪除的完整操作步驟

標(biāo)簽：北京果洛楊凌臺州江蘇吉安朝陽大慶

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《解析Redis Cluster原理》，本文關(guān)鍵詞解析,Redis,Cluster,原理,解析,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。