1.搭建步驟

第一步：在第一臺機器的/usr/local下創建文件夾redis‐cluster，然后在其下面分別創建2個文件夾如下
1. mkdir ‐p /opt/module/redis‐cluster
2. mkdir 8001 8004

第二步：把之前的redis.conf配置文件copy到8001下，修改如下內容：
1. daemonize yes
2. port 8001（分別對每個機器的端口號進行設置）
3. pidfile /var/run/redis_8001.pid # 把pid進程號寫入pidfile配置的文件
4. dir /opt/module/redis‐cluster/8001/（指定數據文件存放位置，必須要指定不同的目錄位置，不然會 丟失數據）
5. cluster‐enabled yes（啟動集群模式）
6. cluster‐config‐file nodes‐8001.conf（集群節點信息文件，這里800x最好和port對應上）
7. cluster‐node‐timeout 10000
8. # bind 127.0.0.1（bind綁定的是自己機器網卡的ip，如果有多塊網卡可以配多個ip，代表允許客戶端通 過機器的哪些網卡ip去訪問，內網一般可以不配置bind，注釋掉即可）
9. protected‐mode no （關閉保護模式）
10. appendonly yes
11. 如果要設置密碼需要增加如下配置：
requirepass 123456 (設置redis訪問密碼)
masterauth 123456 (設置集群節點間訪問密碼，跟上面一致)

第三步：把修改后的配置文件，copy到8004，修改第2、3、4、6項里的端口號，可以用批量替換：:%s/源字符串/目的字符串/g

第四步：另外兩臺機器也需要做上面幾步操作，第二臺機器用8002和8005，第三臺機器用8003和8006

第五步：分別啟動6個redis實例，然后檢查是否啟動成功
1. /opt/module/redis‐7.0.4/src/redis‐server /opt/module/redis‐cluster/800*/redis.conf
2. ps ‐ef | grep redis 查看是否啟動成功

第六步：用redis‐cli創建整個redis集群(redis5以前的版本集群是依靠ruby腳本redis‐trib.rb實現)
# 下面命令里的1代表為每個創建的主服務器節點創建一個從服務器節點
# 執行這條命令需要確認三臺機器之間的redis實例要能相互訪問，可以先簡單把所有機器防火墻關掉，如果不關閉防火墻則需要打開redis服務端口和集群節點gossip通信端口16379(默認是在redis端口號上加1W)
# 關閉防火墻
# systemctl stop firewalld # 臨時關閉防火墻
# systemctl disable firewalld # 禁止開機啟動
/opt/module/redis‐7.0.4/src/redis‐cli ‐a 123456 ‐‐cluster create ‐‐cluster‐replicas 1 192.168.140.129:8001 192.168.140.130:8003 192.168.140.131:8002 192.168.140.129:8004 192.168.140.130:8006 192.168.140.131:8005??

?‐‐cluster‐replicas 1 代表為集群里面所有主節點配一個副本，這個例子里面就相當于三主三從

?下面表示的集群分片的計劃，總共有16384個邏輯分片，類似于先將你所有主節點的內存統計出來，然后分配到16384個hash slot里面，然后平均分配給各個主節點，前面M代表master，S代表slaver，只會給主節點指定槽位

第七步：驗證集群：

連接任意一個客戶端即可：./redis‐cli ‐c ‐h ‐p (‐a訪問服務端密碼，‐c表示集群模式，指定ip地址 和端口號）

如：/usr/local/redis‐5.0.3/src/redis‐cli ‐a 123456?‐c ‐h 192.168.0.61 ‐p 800*

進行驗證： cluster info（查看集群信息）、cluster nodes（查看節點列表）

進行數據操作驗證

關閉集群則需要逐個進行關閉，使用命令：

/opt/module/redis‐7.0.4/src/redis‐cli ‐a 123456?‐c ‐h 192.168.0.60 ‐p 800* shutdown

輸入cluster info

3個節點，，已知總共的節點6個，

cluster nodes

前面代表的該節點的id，根據從節點后面的id能夠找到對應的主節點，這邊能看到主從節點不在同一臺服務器上，盡可能錯峰連接，使得數據更加安全，如果主從在一個服務器上，服務器掛掉直接整個數據都會丟失

?會把集群信息寫到這個文件里面，之前那個命令create cluster是用來創建集群的，等你關掉之后，重新啟動就不需要這個命令了，直接啟動每個節點自動生成集群了，就是通過上面文件里面的信息，每次啟動都會向對應服務器發送通訊，又會重新組成集群狀態還原

進入客戶端設置參數，可以看到定位到了8002，因為根據設置的key的hash算法結果為6783，相應分配到8002這個節點，其他節點是沒有這個信息的

Redis集群原理分析?

過程：

就是你先建立集群嘛，然后生成對應的分片信息以及主從節點信息，這些信息都會對應寫到設置的conf里面，你設置key-value的時候就從這個文件里面讀取信息，先算出slot值，然后判斷是在那個范圍內，對應的是哪個服務器，在Java 代碼里面會將文件里面信息進行緩存?

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

槽位定位算法

Cluster 默認會對 key 值使用 crc16 算法進行 hash 得到一個整數值，然后用這個整數值對 16384 進行取模 來得到具體槽位。
HASH_SLOT = CRC16(key) mod 16384?

跳轉重定位 ?

當客戶端向一個錯誤的節點發出了指令，該節點會發現指令的 key 所在的槽位并不歸自己管理，這時它會向客 戶端發送一個特殊的跳轉指令攜帶目標操作的節點地址，告訴客戶端去連這個節點去獲取數據?？蛻舳耸盏街?令后除了跳轉到正確的節點上去操作，還會同步更新糾正本地的槽位映射表緩存，后續所有 key 將使用新的槽 位映射表?

Redis集群節點間的通信機制 ?

redis cluster節點間采取gossip協議進行通信

維護集群的元數據(集群節點信息，主從角色，節點數量，各節點共享的數據等)有兩種方式：集中 式和gossip?

集中式： ?

優點在于元數據的更新和讀取，時效性非常好，一旦元數據出現變更立即就會更新到集中式的存儲中，其他節 點讀取的時候立即就可以立即感知到；不足在于所有的元數據的更新壓力全部集中在一個地方，可能導致元數 據的存儲壓力。 很多中間件都會借助zookeeper集中式存儲元數據。?

gossip：?

gossip協議包含多種消息，包括ping，pong，meet，fail等等。
meet：某個節點發送meet給新加入的節點，讓新節點加入集群中，然后新節點就會開始與其他節點進行通信；
ping：每個節點都會頻繁給其他節點發送ping，其中包含自己的狀態還有自己維護的集群元數據，互相通過 ping交換元數據(類似自己感知到的集群節點增加和移除，hash slot信息等)；
pong: 對ping和meet消息的返回，包含自己的狀態和其他信息，也可以用于信息廣播和更新；
fail: 某個節點判斷另一個節點fail之后，就發送fail給其他節點，通知其他節點，指定的節點宕機了。
gossip協議的優點在于元數據的更新比較分散，不是集中在一個地方，更新請求會陸陸續續，打到所有節點上 去更新，有一定的延時，降低了壓力；缺點在于元數據更新有延時可能導致集群的一些操作會有一些滯后。?

gossip通信的10000端口 ?

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

網絡抖動 ?

真實世界的機房網絡往往并不是風平浪靜的，它們經常會發生各種各樣的小問題。比如網絡抖動就是非常常見 的一種現象，突然之間部分連接變得不可訪問，然后很快又恢復正常。
為解決這種問題，Redis Cluster 提供了一種選項cluster-node-timeout，表示當某個節點持續 timeout 的時間失聯時，才可以認定該節點出現故障，需要進行主從切換。如果沒有這個選項，網絡抖動會導致主從頻 繁切換 (數據的重新復制)。?

Redis集群選舉原理分析

當slave發現自己的master變為FAIL狀態時，便嘗試進行Failover，以期成為新的master。由于掛掉的master 可能會有多個slave，從而存在多個slave競爭成為master節點的過程， 其過程如下：
1.slave發現自己的master變為FAIL
2.將自己記錄的集群currentEpoch加1，并廣播FAILOVER_AUTH_REQUEST 信息
3.其他節點收到該信息，只有master響應，判斷請求者的合法性，并發送FAILOVER_AUTH_ACK，對每一個 epoch只發送一次ack
4.嘗試failover的slave收集master返回的FAILOVER_AUTH_ACK
5.slave收到超過半數master的ack后變成新Master(這里解釋了集群為什么至少需要三個主節點，如果只有兩 個，當其中一個掛了，只剩一個主節點是不能選舉成功的)
6.slave廣播Pong消息通知其他集群節點。
從節點并不是在主節點一進入 FAIL 狀態就馬上嘗試發起選舉，而是有一定延遲，一定的延遲確保我們等待 FAIL狀態在集群中傳播，slave如果立即嘗試選舉，其它masters或許尚未意識到FAIL狀態，可能會拒絕投票

延遲計算公式：
DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
SLAVE_RANK表示此slave已經從master復制數據的總量的rank。Rank越小代表已復制的數據越新。這種方式下，持有最新數據的slave將會首先發起選舉（理論上）?

集群腦裂數據丟失問題

redis集群沒有過半機制會有腦裂問題，網絡分區導致腦裂后多個主節點對外提供寫服務，一旦網絡分區恢復， 會將其中一個主節點變為從節點，這時會有大量數據丟失
規避方法可以在redis配置里加上參數(這種方法不可能百分百避免數據丟失，參考集群leader選舉機制)：

min‐replicas‐to‐write 1 //寫數據成功最少同步的slave數量，這個數量可以模仿大于半數機制配置，比如 集群總共三個節點可以配置1，加上leader就是2，超過了半數

注意：這個配置在一定程度上會影響集群的可用性，比如slave要是少于1個，這個集群就算leader正常也不能 提供服務了，需要具體場景權衡選擇。

集群是否完整才能對外提供服務

當redis.conf的配置cluster-require-full-coverage為no時，表示當負責一個插槽的主庫下線且沒有相應的從 庫進行故障恢復時，集群仍然可用，如果為yes則集群不可用。?

Redis集群為什么至少需要三個master節點，并且推薦節點數為奇數？??

因為新master的選舉需要大于半數的集群master節點同意才能選舉成功，如果只有兩個master節點，當其中 一個掛了，是達不到選舉新master的條件的。

奇數個master節點可以在滿足選舉該條件的基礎上節省一個節點，比如三個master節點和四個master節點的 集群相比，大家如果都掛了一個master節點都能選舉新master節點，如果都掛了兩個master節點都沒法選舉 新master節點了，所以奇數的master節點更多的是從節省機器資源角度出發說的。?

Redis集群對批量操作命令的支持?

對于類似mset，mget這樣的多個key的原生批量操作命令，redis集群只支持所有key落在同一slot的情況，如果有多個key一定要用mset命令在redis集群上操作，則可以在key的前面加上{XX}，這樣參數數據分片hash計 算的只會是大括號里的值，這樣能確保不同的key能落到同一slot里去，示例如下：

mset {user1}:1:name zhuge {user1}:1:age 18 ?

假設name和age計算的hash slot值不一樣，但是這條命令在集群下執行，redis只會用大括號里的 user1 做 hash slot計算，所以算出來的slot值肯定相同，最后都能落在同一slot。?

哨兵leader選舉流程?

當一個master服務器被某sentinel視為下線狀態后，該sentinel會與其他sentinel協商選出sentinel的leader進行故障轉移工作。每個發現master服務器進入下線的sentinel都可以要求其他sentinel選自己為sentinel的leader，選舉是先到先得。同時每個sentinel每次選舉都會自增配置紀元(選舉周期)，每個紀元中只會選擇一個sentinel的leader。如果所有超過一半的sentinel選舉某sentinel作為leader。之后該sentinel進行故障轉移操作，從存活的slave中選舉出新的master，這個選舉過程跟集群的master選舉很類似。哨兵集群只有一個哨兵節點，redis的主從也能正常運行以及選舉master，如果master掛了，那唯一的那個哨兵節點就是哨兵leader了，可以正常選舉新master。不過為了高可用一般都推薦至少部署三個哨兵節點。為什么推薦奇數個哨兵節點原理跟集群奇數個master節點類似

總結

以上是生活随笔為你收集整理的七、Redis集群搭建的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。