redis集群簡述

哨兵模式中如果主從中 master宕機了，是通過哨兵來選舉出新的master，在這個選舉切換主從的過程，整個redis服務是不可用的。而且哨兵模式中只有一個主節點對外提供服務，因此沒法支持更高的并發。而且當個主節點的內存設置也不宜過大。否則會導致持久化文件過大，影響數據恢復或主從同步的效率。

[[323144]]

redis集群是由 一系列的 主從節點群組成的分布式服務器群，它具有復制、高可用和分片特性。 Redis集群不需要 sentinel哨兵也能完成節點移除和故障轉移的功能。需要將每個節點設置成集群模式，這種集群模式沒有中心節點 ，客戶端通過 CRC16算法對key進行hash

得到一個值，來判斷該 key存儲在哪個主從服務上面，因此就算是某一個主從整個宕機，redis集群也是部分可用的。方便 水平擴展， 可以根據業務規模可以隨時加減配置。 據官方文檔稱可以線性擴展到上萬個節點 ( 但是 官方推薦不超過 1000個節點)。redis集群的性能和高可用性均優于哨兵模式 。

Redis 集群搭建

1. 修改 redis.conf 配置文件

• daemonize yes 后臺啟動
• cluster-enabled yes 開啟集群模式
• cluster-config-file nodes-6379.conf 集群配置信息存放文件名
• cluster-node-timeout 5000 節點離線時間限制，到達此值時發起某個主從重新選舉 master
• protected-mode no 關閉保護模式
• requirepass xxx 設置本機密碼
• masterauth xxx 設置訪問別的機器的密碼

2. 注意關閉服務器的防火墻，否則可能造成節點之間無法通信，無法搭建集群

使用修改好的配置文件啟動 redis 服務，我這里使用三個一主一從來搭建。因此先將 6 個 redis 服務使用指定的配置文件 redis-master.conf 啟動起來： src/redis-server redis-master.conf

3.搭建集群服務

為了保險起見最好先檢查下每臺機器的 redis 服務是否正常啟動了 ps -ef|grep redis

可以看見 redis 服務進程后面有個 cluster 的標志，普通啟動的 redis 服務是沒有這個標志的

5.0 版本可以直接使用 C 語言客戶端提供的指令去構建集群：

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 表示集群創建

--cluster-replicas 表示每個 master 幾個 slave ，上面一共 6 個 redis 節點，因此會構建三個一主一從。

執行命令之前，如果你的 redis 環境以前搭建過主從或者哨兵之類的，數據不干凈可能會報錯，最好將持久化文件刪掉，然后 flushdb ，將以前臟數據清理掉，否則可能出現如下錯誤：

正常執行會返回一個集群分配計劃，我們按照它的計劃即可：

然后節點之間就開始通信構建集群，最后會看見 16384 個 slots 分配完畢，可以看見構建計劃中有三個 master ，每個 master 都是有指定槽位的。意思就是存入的 key 經過 crc16 hash 算法之后得到的值，在哪個范圍內，就存儲到那個 redis 主從上面去，這就是 redis 的分片集群模式。

至此集群搭建完畢

4.集群操作

以集群方式連接 redis 客戶端通過 cluster info 查看集群信息，通過 cluster nodes 查看節點信息

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

我們設置 set abc 123 一個值 會看見客戶點會計算 abc 的 slot 是 7638 ， 然后重定向到對應的主從的 master 上面去寫數據

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

最后計算結果就會落到 0-16383 之間去。

當 Redis Cluster 的客戶端來連接集群時，它也會得到一份集群的槽位配置信息并將其緩存在客戶端本地。這樣當客戶 端要查找某個 key 時，可以直接定位到目標節點。同時因為槽位的信息可能會存在客戶端與服務器不一致的情況，還需 要糾正機制來實現槽位信息的校驗調整。

集中式集群和分片式集群

Redis 節點之間使用的是 gossip 協議進行通信，每個節點之間都會互相通信。

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

ping ：每個節點都會頻繁給其他節點發送 ping ，其中包含自己的狀態還有自己維護的集群元數據，互相通過 ping 交換元數據;

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

fail: 某個節點判斷另一個節點 fail 之后，就發送 fail 給其他節點，通知其他節點，指定的節點宕機了。

meet ：某個節點發送 meet 給新加入的節點，讓新節點加入集群中，然后新節點就會開始與其他節點進行通信，不需要發送形成網絡的所需的所有 CLUSTER MEET 命令。發送 CLUSTER MEET 消息以便每個節點能夠達到其他每個節點只需通 過一條已知的節點鏈就夠了。由于在心跳包中會交換 gossip 信息，將會創建節點間缺失的鏈接。

gossip 協議的優點在于元數據的更新比較分散，不是集中在一個地方，更新請求會陸陸續續，打到所有節點上去更新， 有一定的延時，降低了壓力;缺點在于元數據更新有延時可能導致集群的一些操作會有一些滯后。

就是自己提供服務的端口號 +10000 ，比如 6379 ，那么用于節點間通信 的就是 16379 端口。 每個節點每隔一段時間都會往另外幾個節點發送 ping 消息，同時其他幾點接收到 ping 消息之后返回 pong 消息。

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

集中式的有點在于數據的更新和讀取，時效性非常好，一旦元數據出現變更立即就會更新到集中式( master )的存儲中，其他節點讀取的 時候立即就可以立即感知到;不足在于所有的元數據的更新壓力全部集中在一個地方，可能導致元數據的存儲壓力。

Redis 集群選舉機制

當 slave發現自己的master變為FAIL狀態時，便嘗試 發起選舉 ，以期成為新的 master。由于掛掉的master可能會有 多個 slave，從而存在多個slave競爭成為master節點的過程， 其過程如下：

1.slave發現自己的master變為FAIL

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

3.其他節點收到該信息，只有master響應，判斷請求者的合法性，并發送結果

4.嘗試選舉的slave收集master返回的結果，收到 超過半數 master的統一 后變成新 Master

5.廣播Pong消息通知其他集群節點。

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

• 延遲計算公式：

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

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

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