redis集群簡(jiǎn)述

哨兵模式中如果主從中 master宕機(jī)了，是通過(guò)哨兵來(lái)選舉出新的master，在這個(gè)選舉切換主從的過(guò)程，整個(gè)redis服務(wù)是不可用的。而且哨兵模式中只有一個(gè)主節(jié)點(diǎn)對(duì)外提供服務(wù)，因此沒(méi)法支持更高的并發(fā)。而且當(dāng)個(gè)主節(jié)點(diǎn)的內(nèi)存設(shè)置也不宜過(guò)大。否則會(huì)導(dǎo)致持久化文件過(guò)大，影響數(shù)據(jù)恢復(fù)或主從同步的效率。

[[323144]]

redis集群是由 一系列的 主從節(jié)點(diǎn)群組成的分布式服務(wù)器群，它具有復(fù)制、高可用和分片特性。 Redis集群不需要 sentinel哨兵也能完成節(jié)點(diǎn)移除和故障轉(zhuǎn)移的功能。需要將每個(gè)節(jié)點(diǎn)設(shè)置成集群模式，這種集群模式?jīng)]有中心節(jié)點(diǎn) ，客戶(hù)端通過(guò) CRC16算法對(duì)key進(jìn)行hash

得到一個(gè)值，來(lái)判斷該 key存儲(chǔ)在哪個(gè)主從服務(wù)上面，因此就算是某一個(gè)主從整個(gè)宕機(jī)，redis集群也是部分可用的。方便 水平擴(kuò)展， 可以根據(jù)業(yè)務(wù)規(guī)?？梢噪S時(shí)加減配置。 據(jù)官方文檔稱(chēng)可以線(xiàn)性擴(kuò)展到上萬(wàn)個(gè)節(jié)點(diǎn) ( 但是 官方推薦不超過(guò) 1000個(gè)節(jié)點(diǎn))。redis集群的性能和高可用性均優(yōu)于哨兵模式 。

Redis 集群搭建

1. 修改 redis.conf 配置文件

• daemonize yes 后臺(tái)啟動(dòng)
• cluster-enabled yes 開(kāi)啟集群模式
• cluster-config-file nodes-6379.conf 集群配置信息存放文件名
• cluster-node-timeout 5000 節(jié)點(diǎn)離線(xiàn)時(shí)間限制，到達(dá)此值時(shí)發(fā)起某個(gè)主從重新選舉 master
• protected-mode no 關(guān)閉保護(hù)模式
• requirepass xxx 設(shè)置本機(jī)密碼
• masterauth xxx 設(shè)置訪(fǎng)問(wèn)別的機(jī)器的密碼

2. 注意關(guān)閉服務(wù)器的防火墻，否則可能造成節(jié)點(diǎn)之間無(wú)法通信，無(wú)法搭建集群

使用修改好的配置文件啟動(dòng) redis 服務(wù)，我這里使用三個(gè)一主一從來(lái)搭建。因此先將 6 個(gè) redis 服務(wù)使用指定的配置文件 redis-master.conf 啟動(dòng)起來(lái)： src/redis-server redis-master.conf

3.搭建集群服務(wù)

為了保險(xiǎn)起見(jiàn)最好先檢查下每臺(tái)機(jī)器的 redis 服務(wù)是否正常啟動(dòng)了 ps -ef|grep redis

可以看見(jiàn) redis 服務(wù)進(jìn)程后面有個(gè) cluster 的標(biāo)志，普通啟動(dòng)的 redis 服務(wù)是沒(méi)有這個(gè)標(biāo)志的

5.0 版本可以直接使用 C 語(yǔ)言客戶(hù)端提供的指令去構(gòu)建集群：

src/redis-cli -a xxx --cluster create --cluster-replicas 1 192.168.0.67:6379 192.168.0.68:6379 192.168.0.69:6379 192.168.0.70:6379 192.168.0.71:6379 192.168.0.72:6379 

-a 配置的密碼

--cluster create 表示集群創(chuàng)建

--cluster-replicas 表示每個(gè) master 幾個(gè) slave ，上面一共 6 個(gè) redis 節(jié)點(diǎn)，因此會(huì)構(gòu)建三個(gè)一主一從。

執(zhí)行命令之前，如果你的 redis 環(huán)境以前搭建過(guò)主從或者哨兵之類(lèi)的，數(shù)據(jù)不干凈可能會(huì)報(bào)錯(cuò)，最好將持久化文件刪掉，然后 flushdb ，將以前臟數(shù)據(jù)清理掉，否則可能出現(xiàn)如下錯(cuò)誤：

正常執(zhí)行會(huì)返回一個(gè)集群分配計(jì)劃，我們按照它的計(jì)劃即可：

然后節(jié)點(diǎn)之間就開(kāi)始通信構(gòu)建集群，最后會(huì)看見(jiàn) 16384 個(gè) slots 分配完畢，可以看見(jiàn)構(gòu)建計(jì)劃中有三個(gè) master ，每個(gè) master 都是有指定槽位的。意思就是存入的 key 經(jīng)過(guò) crc16 hash 算法之后得到的值，在哪個(gè)范圍內(nèi)，就存儲(chǔ)到那個(gè) redis 主從上面去，這就是 redis 的分片集群模式。

至此集群搭建完畢

4.集群操作

以集群方式連接 redis 客戶(hù)端通過(guò) cluster info 查看集群信息，通過(guò) cluster nodes 查看節(jié)點(diǎn)信息

src/redis-cli -a 密碼 -c 集群方式連接

我們?cè)O(shè)置 set abc 123 一個(gè)值 會(huì)看見(jiàn)客戶(hù)點(diǎn)會(huì)計(jì)算 abc 的 slot 是 7638 ， 然后重定向到對(duì)應(yīng)的主從的 master 上面去寫(xiě)數(shù)據(jù)

現(xiàn)在我看下 java 客戶(hù)端的 jedis 里面的 key 值計(jì)算 redis.clients.util.JedisClusterCRC16#getSlot(java.lang.String) ：

最后計(jì)算結(jié)果就會(huì)落到 0-16383 之間去。

當(dāng) Redis Cluster 的客戶(hù)端來(lái)連接集群時(shí)，它也會(huì)得到一份集群的槽位配置信息并將其緩存在客戶(hù)端本地。這樣當(dāng)客戶(hù) 端要查找某個(gè) key 時(shí)，可以直接定位到目標(biāo)節(jié)點(diǎn)。同時(shí)因?yàn)椴畚坏男畔⒖赡軙?huì)存在客戶(hù)端與服務(wù)器不一致的情況，還需 要糾正機(jī)制來(lái)實(shí)現(xiàn)槽位信息的校驗(yàn)調(diào)整。

集中式集群和分片式集群

Redis 節(jié)點(diǎn)之間使用的是 gossip 協(xié)議進(jìn)行通信，每個(gè)節(jié)點(diǎn)之間都會(huì)互相通信。

gossip 協(xié)議包含多種消息，包括 ping ， pong ， meet ， fail 等等。

ping ：每個(gè)節(jié)點(diǎn)都會(huì)頻繁給其他節(jié)點(diǎn)發(fā)送 ping ，其中包含自己的狀態(tài)還有自己維護(hù)的集群元數(shù)據(jù)，互相通過(guò) ping 交換元數(shù)據(jù);

pong: 返回 ping 和 meet ，包含自己的狀態(tài)和其他信息，也可以用于信息廣播和更新;

fail: 某個(gè)節(jié)點(diǎn)判斷另一個(gè)節(jié)點(diǎn) fail 之后，就發(fā)送 fail 給其他節(jié)點(diǎn)，通知其他節(jié)點(diǎn)，指定的節(jié)點(diǎn)宕機(jī)了。

meet ：某個(gè)節(jié)點(diǎn)發(fā)送 meet 給新加入的節(jié)點(diǎn)，讓新節(jié)點(diǎn)加入集群中，然后新節(jié)點(diǎn)就會(huì)開(kāi)始與其他節(jié)點(diǎn)進(jìn)行通信，不需要發(fā)送形成網(wǎng)絡(luò)的所需的所有 CLUSTER MEET 命令。發(fā)送 CLUSTER MEET 消息以便每個(gè)節(jié)點(diǎn)能夠達(dá)到其他每個(gè)節(jié)點(diǎn)只需通 過(guò)一條已知的節(jié)點(diǎn)鏈就夠了。由于在心跳包中會(huì)交換 gossip 信息，將會(huì)創(chuàng)建節(jié)點(diǎn)間缺失的鏈接。

gossip 協(xié)議的優(yōu)點(diǎn)在于元數(shù)據(jù)的更新比較分散，不是集中在一個(gè)地方，更新請(qǐng)求會(huì)陸陸續(xù)續(xù)，打到所有節(jié)點(diǎn)上去更新， 有一定的延時(shí)，降低了壓力;缺點(diǎn)在于元數(shù)據(jù)更新有延時(shí)可能導(dǎo)致集群的一些操作會(huì)有一些滯后。

就是自己提供服務(wù)的端口號(hào) +10000 ，比如 6379 ，那么用于節(jié)點(diǎn)間通信 的就是 16379 端口。 每個(gè)節(jié)點(diǎn)每隔一段時(shí)間都會(huì)往另外幾個(gè)節(jié)點(diǎn)發(fā)送 ping 消息，同時(shí)其他幾點(diǎn)接收到 ping 消息之后返回 pong 消息。

還有就是集中式的，比如 ZK 集群

集中式的有點(diǎn)在于數(shù)據(jù)的更新和讀取，時(shí)效性非常好，一旦元數(shù)據(jù)出現(xiàn)變更立即就會(huì)更新到集中式( master )的存儲(chǔ)中，其他節(jié)點(diǎn)讀取的 時(shí)候立即就可以立即感知到;不足在于所有的元數(shù)據(jù)的更新壓力全部集中在一個(gè)地方，可能導(dǎo)致元數(shù)據(jù)的存儲(chǔ)壓力。

Redis 集群選舉機(jī)制

當(dāng) slave發(fā)現(xiàn)自己的master變?yōu)镕AIL狀態(tài)時(shí)，便嘗試 發(fā)起選舉 ，以期成為新的 master。由于掛掉的master可能會(huì)有 多個(gè) slave，從而存在多個(gè)slave競(jìng)爭(zhēng)成為master節(jié)點(diǎn)的過(guò)程， 其過(guò)程如下：

1.slave發(fā)現(xiàn)自己的master變?yōu)镕AIL

2.將自己記錄的集群currentEpoch(選舉輪次標(biāo)記)加1，并廣播信息給集群中其他節(jié)點(diǎn)

3.其他節(jié)點(diǎn)收到該信息，只有master響應(yīng)，判斷請(qǐng)求者的合法性，并發(fā)送結(jié)果

4.嘗試選舉的slave收集master返回的結(jié)果，收到 超過(guò)半數(shù) master的統(tǒng)一 后變成新 Master

5.廣播Pong消息通知其他集群節(jié)點(diǎn)。

如果這次選舉不成功，比如三個(gè)小的主從 A,B,C組成的集群，A的master掛了，A的兩個(gè)小弟發(fā)起選舉，結(jié)果B的master投給A的小弟A1，C的master投給了A的小弟A2，這樣就會(huì)發(fā)起第二次選舉，選舉輪次標(biāo)記+1繼續(xù)上面的流程。事實(shí)上從節(jié)點(diǎn)并不是在主節(jié)點(diǎn)一進(jìn)入 FAIL 狀態(tài)就馬上嘗試發(fā)起選舉，而是有一定延遲，一定的延遲確保我們等待FAIL狀態(tài)在集群中傳播，slave如果立即嘗試選舉，其它masters或許尚未意識(shí)到FAIL狀態(tài)，可能會(huì)拒絕投票。 同時(shí)下面公式里面的隨機(jī)數(shù)，也可以有效避免slave同時(shí)發(fā)起選舉，導(dǎo)致的平票情況。

• 延遲計(jì)算公式：

DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms

• SLAVE_RANK表示此slave已經(jīng)從master復(fù)制數(shù)據(jù)的總量的rank。Rank越小代表已復(fù)制的數(shù)據(jù)越新。這種方式下，持有最新數(shù)據(jù)的slave將會(huì)首先發(fā)起選舉(理論上)。

前面說(shuō)到這種分片的集群模式的集群可以部分提供服務(wù)， 當(dāng) redis.conf的配置cluster-require-full-coverage為no時(shí)， 表示當(dāng)一個(gè)小主從整體掛掉的時(shí)候集群也可以用，也是說(shuō) 0-16383個(gè)槽位中，落在該主從對(duì)應(yīng)的slots上面的key是用不了的，但是如果key落在其他的范圍是仍然可用的。