• 一、集群簡介
• 二、Redis Cluster資料磁區原理
  • 2.1 Hash磁區方案
    • 2.1.1節點取余磁區
    • 2.1.2一致性哈希
  • 2.2 Redis Cluster資料磁區方案
• 三、搭建集群
  • 3.1 準備節點
  • 3.2 創建集群
• 四、節點通信原理
  • 4.1 Gossip訊息
  • 4.2 通信節點選擇

一、集群簡介

Redis Cluster是redis3.0后正式推出的分布式解決方案，

之前介紹了復制和哨兵，解決了高可用問題，通過復制，讀操作可以分發到多個節點（讀實作了負載均衡），但是寫操作依然只有一個節點，無法實作寫操作的負載均衡，但是依然面臨單機記憶體和并發的瓶頸，

集群就是用來解決寫操作負載均衡的問題，其核心有兩個作用

1. 資料分片：這是集群最最核心的功能，通過發片，突破了redis的單機記憶體限制，資料發布到多個節點，每個節點都可以提供讀寫操作，回應能力也得到提高
2. 高可用：這個和復制-哨兵一樣，每個節點都由主從組成，同時實作了自動故障轉移，

二、Redis Cluster資料磁區原理

2.1 Hash磁區方案

常見哈希磁區主要兩種：

1. 節點取余磁區
2. 一致性哈希（distributed hash table）

2.1.1節點取余磁區

N為節點的數量，這種方案優點是簡單，缺點是當有節點數量變化（擴容or縮容），資料節點映射關系需要重新計算，會導致資料重新遷移，

一般用于節點可以預估不變的場景，比如資料庫分表分庫，比如訂單庫可以分64個，orderId mod 64可得到這個訂單資料應該寫入那個庫，

2.1.2一致性哈希

實作思路是為系統中的每一個節點分配一個token，范圍一般為0~2的32次方，這個這些token構成一個哈希環，

當有資料寫入時，先根據key計算出哈希值X，然后順時針尋找到第一個大于X的token的節點，然后把值存入該節點即可，下圖中：

1. A存入node1
2. B存入node2
3. ，，，

一致性哈希磁區中，如果增加或者減少節點，只影響節點改節點相鄰的節點，其他節點毫無影響，比如在node1之前增加一個節點，只會使得原來存盤到node1的資料一部分資料（比如A）轉移到新節點，其他節點毫無影響，

一致性哈希的最大問題是，當節點比較少時，新增或者洗掉節點會導致資料的分配嚴重不均衡， 在上圖中，如果洗掉node1和node2：

1. 原有node1和node2存盤的資料會全部遷移到node3，導致node3的資料從原來的的1/6變成了1/2
2. node（4，5，6）三個節點總共存盤1/2，嚴重不平衡，

虛擬槽磁區是對一致性哈希的改進，用來解決負載均衡的問題，

2.2 Redis Cluster資料磁區方案

Redis Cluster采用虛擬槽磁區，槽是介于實際節點和資料之間的虛擬概念，每個節點對應一定范圍的槽，每個槽包含一定范圍內的哈希值，使用了虛擬槽磁區后，資料的映射關系從hash-》節點變成了hash-》槽-》節點，

Redis Cluster槽的范圍是16384（0_{16383），所有鍵基于哈希函式映射到0}16383整數槽內(CRC取模)，計算公式：

示意圖如下：

使用虛擬槽磁區后，節點的變動對系統影響較小，比如上圖中，洗掉node1，只需要對0-3276的槽重新分配即可，

三、搭建集群

搭建一個三主三從的集群，在同一臺機器上，由埠號進行區分，

1. 三主：7000，7001，7002
2. 三從：8000，8001，8002

3.1 準備節點

7000節點配置如下：

#埠號
port 7000
#開啟集群模式
cluster-enabled yes
#節點超時時間（毫秒）
cluster-node-timeout 15000
#集群內部組態檔
cluster-config-file "nodes-7000.conf"
logfile "log-7000.log"
protected-mode no
daemonize yes

依次配置7001，7002，8000，8001，8002，

啟動6個節點：

src/redis-server redis-7000.conf 
src/redis-server redis-7001.conf 
src/redis-server redis-7002.conf 
src/redis-server redis-8000.conf 
src/redis-server redis-8001.conf 
src/redis-server redis-8002.conf 

配置相關說明

上面的配置中cluster-enabled 和cluster-config-file是集群相關的配置，

cluster-enabled 設定為yes，代表集群模式，默認redis是單機模式，

cluster-config-file是集群特有的組態檔，在redis啟動的時候如果發現沒有組態檔會自動創建一個組態檔，

打開組態檔，如果集群組態檔已經存在，則直接讀取，集群組態檔由redis自動維護，無需手動修改，

7000首次啟動后生成的集群組態檔如下：

877e9d061f80cea70285e823cbc4246041752149 :7000@17000 myself,master - 0 0 0 connected 5474 5798 11459 11958 12706 13735
vars currentEpoch 0 lastVoteEpoch 0

記錄了集群的初始狀態，最重要的是第一個40位的16進制字串，是集群的節點ID，節點ID在集群初始化的時候只創建一次，重啟后會加載集群組態檔進行重用，集群節點ID不用于redis的運行id，運行id每次重啟后都會變好，

3.2 創建集群

直接使用redis-cli命令來創建（redis5.0之后）

輸入命令

redis-cli --cluster create 192.168.118.129:7000 192.168.118.129:7001 192.168.118.129:7002 192.168.118.129:8000 192.168.118.129:8001 192.168.118.129:8002 --cluster-replicas 1

--cluster-replicas 1表示每一個主節點分配一個從節點，

（上面的warning是因為我把所有節點部署到了同一個機器）

輸入yes繼續

集群配置成功，16384個slots分配完畢，

整體結構

Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.118.129:8001 to 192.168.118.129:7000
Adding replica 192.168.118.129:8002 to 192.168.118.129:7001
Adding replica 192.168.118.129:8000 to 192.168.118.129:7002

用上面命令創建的集群是無法手工指定主從關系的，

四、節點通信原理

4.1 Gossip訊息

Redis采用Gossip協議（P2P），Gossip協議的作業原理就是節點之間不斷通信交換資訊，一段時間后所有節點都會知道集群的完整資訊，類似于流言傳播，類似于下圖：

通信程序：

1. cluster中的每一個節點都會單獨開辟一個TCP通道，用于節點之間的彼此通信，通信埠號是在節點基礎埠號上加10000，比如原埠號是7000，則對應的Gossip埠號則為17000，
2. 每個節點在固定周期內通過特定規則選擇幾個節點發送ping訊息
3. 接收到ping訊息的節點用pong訊息作為回應，

Gossip訊息型別：

Gossip訊息決議流程：

meet

4.2 通信節點選擇

上面的Gossip訊息中，ping/pong訊息都需要攜帶當前節點的資訊和部分其他節點的資訊（狀態等），這些頻繁的資訊交換勢必會加重帶寬和計算負擔，依次每次選擇多少個節點進行通信（每次要發給多少個節點）變得特別重要：

1. 太多：交換成本高
2. 太少：訊息交換頻率低，影響故障判斷，節點發現的速度，

具體選擇：

選擇發送節點

5個節點是指集群內隨機找5個節點，取其中一個其他節點發送ping，

10次：針對上一步選出來的一個節點每100毫秒掃描一次本地的節點串列，如果發現節點最近一次接受pong訊息的時間大于cluster-node-timeout/2 ，則需要給該節點發送ping訊息，總節點數量：

• num(node.pong_received > cluster_node_timeout/2)

ping訊息數量

自身節點數量+1/10其他節點的數量

由此可見，節點的cluster_node_timeout和整個集群節點的數量都會影響集群節點之間的資訊交換，

標籤：NoSQL

上一篇：抖音資料采集Frida教程，rpc、Process、Module、Memory使用方法及示例

下一篇：JDBC鏈接資料庫