Redis的Cluster集群搭建的實現步驟

一、引言

 本文檔隻對Redis的Cluster集群做簡單的介紹，並沒有對分佈式系統的所涉及到的概念做深入的探討。本文隻是針對如何設置集群、測試和操作集群做瞭簡述，並且從用戶的角度描述瞭系統的行為，並不涉及Redis集群規范中所包含的細節。但是，本教程試圖從最終用戶的角度來解釋有關Redis的Cluster集群的可用性和一致性的特點，並以簡單易懂的方式講解。

請註意，本教程需要使用Redis 3.0版本或更高版本。

如果您打算部署Redis的Cluster集群，即使不是嚴格的要求，我們也建議閱讀更正式的規范。不過，從這篇文檔開始，我們可以先使用Redis Cluster集群，然後再閱讀規范也是一個不錯的主意。

二、Redis的Cluster模式介紹

1、Redis群集101

Redis集群提供瞭一種運行Redis設備的方式，並且數據可以在多個Redis節點間自動分配的。Redis集群在分區期間也能提供一定程度的可用性，實際上，就是說當某些節點發生故障或無法通信時，集群能夠繼續運行。 但是，如果發生較大故障（例如，大多數主站服務器不可用時），群集會停止運行。

那麼從實際角度而言，您使用Redis Cluster能獲得什麼呢？

1、在多個節點之間自動分割數據集的能力。

2、在節點子集遇到故障或無法與集群其餘部分通信時繼續運行的能力。

2、Redis群集TCP端口

每個Redis群集的節點都需要打開兩個TCP連接，由於這兩個連接就需要兩個端口，分別是用於為客戶端提供服務的常規Redis TCP命令端口（例如6379）以及通過將10000和命令端口相加（10000+6379）而獲得的端口，就是集群端口（例如16379）。

第二個大號端口用於群集總線，即使用二進制協議的節點到節點通信通道。 節點使用群集總線進行故障檢測，配置更新，故障轉移授權等。 客戶端不應嘗試與群集總線端口通信，為瞭保證Redis命令端口的正常使用，請確保在防火墻中打開這兩個端口，否則Redis群集節點將無法通信。

命令端口和集群總線端口偏移量是固定的，始終為10000。

請註意，為瞭讓Redis群集正常工作，您需要為每個節點：

1、用於與客戶端進行通信的普通客戶端通信端口（通常為6379）對所有需要到達群集的客戶端以及所有其他群集節點（使用客戶端端口進行密鑰遷移）都是開放的。

2、集群總線端口（客戶端端口+ 10000）必須可從所有其他集群節點訪問。

如果您不打開這兩個TCP端口，則您的群集將無法正常工作。

集群總線使用不同的二進制協議進行節點到節點的數據交換，這更適合於使用很少的帶寬和處理時間在節點之間交換信息。

3、Redis集群和Docker

目前，Redis群集不支持NAT地址環境，並且在IP地址或TCP端口被重新映射的一般環境中。

Docker使用一種叫做端口映射的技術：Docker容器中運行的程序可能會暴露在與程序認為使用的端口不同的端口上。 這對於在同一服務器中同時使用相同端口運行多個容器很有用。

為瞭使Docker與Redis Cluster兼容，您需要使用Docker的主機聯網模式。 請查看Docker文檔中的–net = host選項以獲取更多信息。

4、Redis集群數據分片

Redis集群沒有使用一致的散列，而是一種不同的分片形式，其中每個 key 在概念上都是我們稱之為散列槽的部分。

Redis集群中有16384個散列槽，為瞭計算給定 key 的散列槽，我們簡單地取16384模的CRC16。

Redis集群中的每個節點負責哈希槽的一個子集，例如，您可能有一個具有3個節點的集群，其中：

1、節點A包含從0到5500的散列槽。
2、節點B包含從5501到11000的散列槽。
3、節點C包含從11001到16383的散列槽。

這允許輕松地添加和刪除集群中的節點。例如，如果我想添加一個新節點D，我需要將節點A，B，C中的一些散列槽移動到D。同樣，如果我想從集群中刪除節點A，我可以隻移動由A使用的散列槽到B和C，當節點A將為空時，我可以將它從群集中徹底刪除。

因為將散列槽從一個節點移動到另一個節點不需要停機操作，添加和移除節點或更改節點占用的散列槽的百分比也不需要任何停機時間。

隻要涉及單個命令執行（或整個事務或Lua腳本執行）的所有 key 都屬於同一散列插槽，Redis群集就支持多個 key 操作。用戶可以使用稱為散列標簽的概念強制多個 key 成為同一個散列槽的一部分。

Hash標記記錄在Redis集群規范文檔中，但要點是如果在關鍵字{}括號內有一個子字符串，那麼隻有該花括號“{}”內部的內容被散列，例如 this{foo}key 和 another{foo}key 保證在同一散列槽中，並且可以在具有多個 key 作為參數的命令中一起使用。

5、Redis集群之主從模型

為瞭在主服務器節點的子集失敗或不能與大多數節點通信時保持可用，Redis集群使用主從模型，其中每個散列槽從1（主服務器本身）到N個副本（N -1個附加從節點）。

在我們具有節點A，B，C的示例的群集中，如果節點B失敗，則群集無法繼續，因為我們沒有辦法再在5501-11000范圍內提供散列槽。然而，當創建集群時（或稍後），我們為每個主服務器節點添加一個從服務器節點，以便最終集群由作為主服務器節點的A，B，C以及作為從服務器節點的A1，B1，C1組成，如果節點B發生故障，系統能夠繼續運行。節點B1復制B，並且B失敗，則集群將促使節點B1作為新的主服務器節點並且將繼續正確地操作。

但請註意，如果節點B和B1在同一時間發生故障，則Redis群集無法繼續運行。

6、Redis集群一致性保證

Redis 集群無法保證很強的一致性。實際上，這意味著在某些情況下，Redis 集群可能會丟失系統向客戶確認的寫入。

Redis集群可能會丟失寫入的第一個原因是因為它使用異步復制。這意味著在寫入期間會發生以下事情：

1、你的客戶端寫給主服務器節點 B
2、主服務器節點B向您的客戶端回復確認。
3、主服務器節點B將寫入傳播到它的從服務器B1，B2和B3。

正如你可以看到主服務器節點 B 在回復客戶端之前不等待B1，B2，B3的確認，因為這會對Redis造成嚴重的延遲損失，所以如果你的客戶端寫入瞭某些東西，主服務器節點 B 確認寫入，就在將寫入發送給它的從服務器節點存儲之前系統崩潰瞭，其中一個從站（沒有收到寫入）可以提升為主站，永遠丟失寫入。

這與大多數配置為每秒將數據刷新到磁盤的數據庫所發生的情況非常相似，因為過去的經驗與傳統數據庫系統有關，不會涉及分佈式系統，因此您已經能夠推斷這種情況。同樣，通過強制數據庫在回復客戶端之前刷新磁盤上的數據，這樣可以提高一致性，但這通常會導致性能極低。這與Redis Cluster中的同步復制相當。

基本上，性能和一致性之間需要權衡。

Redis集群在絕對需要時也支持同步寫入，通過WAIT命令實現，這使得丟失寫入的可能性大大降低，但請註意，即使使用同步復制，Redis集群也不可能實現完全的一致性：總是有可能會發生故常，在無法接受寫入的從設備被選為主設備的時候 。

還有另一個值得註意的情況，Redis集群也將丟失數據的寫入，這種情況發生在網絡分區的時候，客戶端與包含至少一個主服務器的少數實例隔離。

以A，B，C，A1，B1，C1三個主站和三個從站組成的6個節點集群為例。還有一個客戶，我們會調用Z1。

分區發生後，可能在分區的一側有A，C，A1，B1，C1，另一側有B和Z1。

Z1仍然能夠寫入B，它也會接受Z1的寫入。如果分區在很短的時間內恢復，則群集將正常繼續。但是，如果分區使用比較長的時間將B1提升為多數側分區的主設備，則Z1發送給B的寫入操作將丟失。

請註意，Z1能夠發送給B的寫入量有一個最大窗口（maximum window）：如果分區多數側有足夠的時間選擇一個從設備作為主設備，那麼少數側的每個主節點將停止接受寫操作。

這個時間值是Redis集群非常重要的配置指令，稱為 node timeout (節點超時)。

在節點超時過後，主節點被認為是失效的，並且可以被其副本之一替換。類似地，節點超時過後，主節點無法感知大多數其他主節點，它進入錯誤狀態並停止接受寫入。

7、Redis群集配置參數

我們即將創建示例集群部署。在繼續之前，讓我們介紹一下Redis Cluster在redis.conf文件中引入的配置參數。有些命令的意思是顯而易見的，有些命令在你閱讀下面的解釋後才會更加清晰。

1、cluster-enabled <yes/no>：如果想在特定的Redis實例中啟用Redis群集支持就設置為yes。 否則，實例通常作為獨立實例啟動。

2、cluster-config-file <filename>：請註意，盡管有此選項的名稱，但這不是用戶可編輯的配置文件，而是Redis群集節點每次發生更改時自動保留群集配置（基本上為狀態）的文件，以便能夠 在啟動時重新讀取它。 該文件列出瞭群集中其他節點，它們的狀態，持久變量等等。 由於某些消息的接收，通常會將此文件重寫並刷新到磁盤上。

3、cluster-node-timeout <milliseconds>：Redis群集節點可以不可用的最長時間，而不會將其視為失敗。 如果主節點超過指定的時間不可達，它將由其從屬設備進行故障切換。 此參數控制Redis群集中的其他重要事項。 值得註意的是，每個無法在指定時間內到達大多數主節點的節點將停止接受查詢。

4、cluster-slave-validity-factor <factor>：如果設置為0，無論主設備和從設備之間的鏈路保持斷開連接的時間長短，從設備都將嘗試故障切換主設備。 如果該值為正值，則計算最大斷開時間作為節點超時值乘以此選項提供的系數，如果該節點是從節點，則在主鏈路斷開連接的時間超過指定的超時值時，它不會嘗試啟動故障切換。 例如，如果節點超時設置為5秒，並且有效因子設置為10，則與主設備斷開連接超過50秒的從設備將不會嘗試對其主設備進行故障切換。 請註意，如果沒有從服務器節點能夠對其進行故障轉移，則任何非零值都可能導致Redis群集在主服務器出現故障後不可用。 在這種情況下，隻有原始主節點重新加入集群時，集群才會返回可用。

5、cluster-migration-barrier <count>：主設備將保持連接的最小從設備數量，以便另一個從設備遷移到不受任何從設備覆蓋的主設備。有關更多信息，請參閱本教程中有關副本遷移的相應部分。

6、cluster-require-full-coverage <yes / no>：如果將其設置為yes，則默認情況下，如果key的空間的某個百分比未被任何節點覆蓋，則集群停止接受寫入。 如果該選項設置為no，則即使隻處理關於keys子集的請求，群集仍將提供查詢。

三、創建和使用Redis群集

註意：手動部署Redis群集，這對瞭解集群的操作細節方面是非常重要的。但是，如果想要啟動群集並盡快運行（盡快），請跳過本節和下一節，直接使用create-cluster腳本直接創建Redis群集。

要創建一個集群，我們需要做的第一件事是在集群模式下運行幾個空的Redis實例。這就意味著群集不是使用普通的Redis實例創建的，因為需要配置特殊模式，以便Redis實例啟用群集特定的功能和命令。

以下是最小的Redis集群配置文件：

　port 7000
　　　　cluster-enabled yes
　　　　cluster-config-file nodes.conf
　　　　cluster-node-timeout 5000
　　　　appendonly yes

正如您所看到的那樣，啟用群集模就是使用 cluster-enabled 這個指令。 每個Redis的實例還包含存儲此節點配置信息的文件的路徑，默認情況下為nodes.conf。 這個文件內容永遠不要人為地去修改，但是可以修改其名稱，它僅在Redis集群實例啟動時生成，並在每次需要時進行更新。

請註意，按預期工作的最小群集需要至少包含三個主節點。 對於第一次測試，強烈建議啟動一個由三個主服務器節點和三個從服務器節點組成的六個節點群集。我們通過以下步驟來一步一步的搭建Redis的Cluster集群環境。

1、我們創建相關目錄，主文件夾是redis-cluster，在此文件夾下建立6個子文件夾，名稱分別是：7000,7001,7002,7003,7004,7005，該目錄以我們將在任何給定目錄內運行的實例的端口號命名。

然後創建6個子目錄，如下圖：

mkdir redis-cluster
cd redis-cluster
mkdir 7000 7001 7002 7003 7004 7005

2、目錄創建好後，我們把Redis源文件裡面包含的配置文件redis.conf拷貝一份，存放在7000目錄下，然後對其配置項進行修改，這個配置文件Redis.conf會作為其他Redis實例的配置文件的模板，並拷貝到其他目錄。

由於我們是做測試，並沒有啟動6個真正的物理節點，而是把6個Redis實例都部署在瞭同一臺Linux服務器上，地址：192.168.127.130，為瞭區分Redis實例，我們是以不同的端口號來區分Redis實例的。然後我們修改Redis.conf的配置文件，修改項如下：

bind 192.168.127.130  //綁定服務器IP地址
port 7000  //綁定端口號，必須修改，以此來區分Redis實例
daemonize yes  //後臺運行
pidfile /var/run/redis-7000.pid  //修改pid進程文件名，以端口號命名
logfile /root/application/program/redis-cluster/7000/redis.log  //修改日志文件名稱，以端口號為目錄來區分
dir /root/application/program/redis-cluster/7000/  //修改數據文件存放地址，以端口號為目錄名來區分
cluster-enabled yes  //啟用集群
cluster-config-file nodes-7000.conf  //配置每個節點的配置文件，同樣以端口號為名稱
cluster-node-timeout 15000  //配置集群節點的超時時間，可改可不改
appendonly yes  //啟動AOF增量持久化策略
appendfsync always  //發生改變就記錄日志

3、7000目錄下的Redis.conf配置文件修改後，分別拷貝到其他子目錄，依次為：7001，7002，7003，7004，7005，根據上面的配置，我們隻需修改和端口號有關的項目，在Linux系統下，我們通過命令：%s/7000/7001/g，：%s/7000/7002/g，：%s/7000/7002/g，：%s/7000/7003/g，：%s/7000/7004/g，：%s/7000/7005/g 分別進行全局替換，並保存，完成對其他子目錄下的配置文件的修改。

4、我們安裝Redis的Cluster集群，需要使用Ruby命令，所以我們必須安裝對Ruby的支持。　　　　　　　　

在此說明一下，以前的Redis版本下，需要安裝Ruby和Rubygems，但是最新的版本不需要瞭，隻要安裝Ruby，Rubygems就會自動安裝。

yum install ruby //安裝ruby
yum install rubygems  //安裝rubygems，最新版本會自動安裝

5、我們安裝完 Ruby 和 Rubygems 後，還需要繼續安裝Redis的Ruby接口程序。

gem install redis

安裝Redis的ruby接口程序，可能會提示如下，錯誤：redis requires ruby version 2.2.2，怎麼辦呢？如果是第一次遇到這個問題，可能會困擾你一陣子，我這裡也有解決方案，幫你解憂。地址如下：https://www.jb51.net/article/217371.htm，按步驟執行就可以，一切順利。

6、開始啟動我們6個Redis實例，並且要指定配置文件，這些配置文件分別在各自的子目錄下面。

cd 7000
redis-server redis.conf
cd 7001
redis-server redis.conf
cd 7002
redis-server redis.conf
cd 7003
redis-server redis.conf
cd 7004
redis-server redis.conf
cd 7005
redis-server redis.conf

7、創建集群，執行redis-trib.rb腳本，這個腳本文件可以拷貝出來，我是把它放在這個目錄：/root/application/program/redis/，當然在這個目錄下，也有其他文件，比如redis-cli，redis-server等。

ruby redis-trib.rb  create --replicas 1 192.168.127.130:7000 192.168.127.130:7001 192.168.127.130:7002 192.168.127.130:7003 192.168.127.130:7004 192.168.127.130:7005 

我們有Redis集群命令行實用程序redis-trib的幫助，Ruby實用程序對實例執行特殊命令以創建新集群，檢查或重新設置現有集群，等等。 redis-trib實用程序位於Redis源代碼分發的src目錄中，當然也可以拷貝到其他目錄中，以方便使用。 您需要安裝redis gem才能運行redis-trib。

這裡使用的命令是create，因為我們想創建一個新的集群。 選項–replicas 1 意味著我們需要為每個創建的主服務器節點創建一個從服務器節點。其他參數是我想用來創建新集群的實例的地址列表。

顯然，我們要求的唯一設置是創建一個具有3個主站和3個從站的集群。

8、 如果一切順利，你會看到類似這樣的消息： [OK] All 16384 slots covered， 這意味著至少有一個主實例服務於每個16384可用的插槽，成功創建瞭Redis的Cluster集群環境。

9、分別登陸7000,7001,7002Redis的實例客戶端，進行測試。效果如圖：

1、登陸7000操作：

redis-cli -c -h 192.168.127.130 -p 7000

2、登陸7001操作：

　redis-cli -c -h 192.168.127.130 -p 7001

3、登陸7002操作：

redis-cli -c -h 192.168.127.130 -p 7002

10、通過Cluster Nodes命令和Cluster Info命令來看看集群效果。

11、在集群上通過增加數據來測試集群效果。直接看截圖效果吧：

每個Redis的節點都有一個ID值，此ID將被此特定redis實例永久使用，以便實例在集群上下文中具有唯一的名稱。 每個節點都會記住使用此ID的每個其他節點，而不是通過IP或端口。IP地址和端口可能會發生變化，但唯一的節點標識符在節點的整個生命周期內都不會改變。 我們簡單地稱這個標識符為節點ID。

四、使用創建群集腳本創建Redis群集

如果您不想通過如上所述手動配置和執行單個實例來創建Redis群集，則有一個更簡單的系統可以代替以上操作（但您不會學到相同數量的操作細節）。

隻需在Redis發行版中檢查 utils/create-cluster 目錄即可。 裡面有一個名為create-cluster的腳本（與其包含的目錄名稱相同），它是一個簡單的bash腳本。 要啟動具有3個主站和3個從站的6個節點群集，隻需輸入以下命令：
1、create-cluster start
2、create-cluster create

當redis-trib實用程序希望您接受集群佈局時，在步驟2中回復yes。

您現在可以與群集交互，默認情況下，第一個節點將從端口30001開始。 完成後，停止群集：

1、create-cluster stop.

請閱讀此目錄中的自述文件以獲取有關如何運行腳本的更多信息。

五、測試故障轉移

註意：在此測試期間，應該運行一致性測試應用程序時打開選項卡。

為瞭觸發故障轉移，我們可以做的最簡單的事情（這也是分佈式系統中可能發生的語義上最簡單的故障）是使單個進程崩潰，在我們的當前的情況下就是單個主進程。

我們可以識別一個集群並使用以下命令將其崩潰：

$ redis-cli -p 7000 cluster nodes | grep master
          　　 3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385482984082 0 connected 5960-10921
          　　 2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 master - 0 1385482983582 0 connected 11423-16383
          　　 97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5959 10922-11422

好吧，7000,7001和7002都是主服務器節點。 讓我們用 DEBUG SEGFAULT 命令使節點7002崩潰：

$ redis-cli -p 7002 debug segfault
Error: Server closed the connection

現在我們可以看一致性測試的輸出以查看它報告的內容。

18849 R (0 err) | 18849 W (0 err) |
23151 R (0 err) | 23151 W (0 err) |
27302 R (0 err) | 27302 W (0 err) |
... many error warnings here ...
   
29659 R (578 err) | 29660 W (577 err) |
33749 R (578 err) | 33750 W (577 err) |
37918 R (578 err) | 37919 W (577 err) |
42077 R (578 err) | 42078 W (577 err) |

正如您在故障轉移期間所看到的，系統無法接受578次讀取和577次寫入，但是在數據庫中未創建任何不一致。 這聽起來可能會出乎意料，因為在本教程的第一部分中，我們聲明Redis群集在故障轉移期間可能會丟失寫入，因為它使用異步復制。 我們沒有說的是，這種情況不太可能發生，因為Redis會將答復發送給客戶端，並將命令復制到從服務器，同時，因此會有一個非常小的窗口來丟失數據。 但是很難觸發這一事實並不意味著這是不可能的，所以這不會改變Redis集群提供的一致性保證。

$ redis-cli -p 7000 cluster nodes
3fc783611028b1707fd65345e763befb36454d73 127.0.0.1:7004 slave 3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 0 1385503418521 0 connected
a211e242fc6b22a9427fed61285e85892fa04e08 127.0.0.1:7003 slave 97a3a64667477371c4479320d683e4c8db5858b1 0 1385503419023 0 connected
97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5959 10922-11422
3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7005 master - 0 1385503419023 3 connected 11423-16383
3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385503417005 0 connected 5960-10921
2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385503418016 3 connected

現在我們可以檢查故障轉移後的群集設置（註意，在此期間，我重新啟動瞭崩潰的實例，以便它重新加入作為從屬群集）：

$ redis-cli -p 7000 cluster nodes
    　　　　　　3fc783611028b1707fd65345e763befb36454d73 127.0.0.1:7004 slave 3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 0 1385503418521 0 connected
    　　　　　　a211e242fc6b22a9427fed61285e85892fa04e08 127.0.0.1:7003 slave 97a3a64667477371c4479320d683e4c8db5858b1 0 1385503419023 0 connected
    　　　　　　97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5959 10922-11422
    　　　　　　3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7005 master - 0 1385503419023 3 connected 11423-16383
    　　　　　　3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385503417005 0 connected 5960-10921
    　　　　　　2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385503418016 3 connected

現在，主服務器節點正在端口7000,7001和7002上運行。以前是主服務器節點，即運行在端口7005上的Redis實例，現在是7002的從服務器節點。

Node ID
   　　　　　　 ip:port
   　　　　　　 flags: master, slave, myself, fail, ...
    　　　　　　if it is a slave, the Node ID of the master
    　　　　　　Time of the last pending PING still waiting for a reply.
       　　　　Time of the last PONG received.
        　　　 Configuration epoch for this node (see the Cluster specification).
       　　　　Status of the link to this node.
        　　　 Slots served...

六、手動故障轉移

有時，強制進行故障轉移並不會在主服務器上導致任何問題。例如，為瞭升級其中一個主節點的Redis進程，最好將其故障轉移，以便將其轉變為一個對可用性影響最小的從服務器。

Redis Cluster使用CLUSTER FAILOVER命令支持手動故障轉移，該命令必須在要故障轉移的主服務器的一個從服務器上執行。

手動故障轉移是比較特殊的，並且與實際主控故障導致的故障轉移相比更安全，因為它們是以避免數據丟失的方式發生，隻有在系統確定新主服務器節點處理完全部來自舊主服務器節點的復制流後才將客戶從原始主服務器節點切換到新主服務器節點。

這是您在執行手動故障轉移時在從服務器節點的日志中看到的內容：

＃接受用戶的手動故障轉移請求。
       　　＃已暫停的主服務器手動故障轉移接收復制的偏移量：347540
       　　＃處理所有主服務器節點的復制流，手動故障轉移可以開始。
       　　＃選舉開始延遲0毫秒（等級＃0，偏移量347540）。
       　　＃為epoch 7545啟動故障轉移選舉。
       　　＃故障轉移選舉勝出：我是新主人。

          # Manual failover user request accepted.
       　　# Received replication offset for paused master manual failover: 347540
      　　 # All master replication stream processed, manual failover can start.
      　　 # Start of election delayed for 0 milliseconds (rank #0, offset 347540).
       　　# Starting a failover election for epoch 7545.
       　　# Failover election won: I'm the new master.

基本上連接到我們正在故障轉移的主服務器節點上的客戶端都已停止工作。與此同時，主服務器節點將其復制偏移量發送給從服務器節點，該從服務器節點將等待達到其側面的偏移量。當達到復制偏移量時，將啟動故障轉移，並向舊主服務器通知配置開關。 當舊主服務器節點上的客戶端被解鎖時，它們會被重定向到新主服務器。

七、總結

今天就寫到這裡瞭，關於Cluster的內容還沒有寫完，有關動態擴容的內容將在下一篇文章做詳細介紹。這篇文章對很多東西沒有做更細致的探討，隻是從用戶的角度來簡單說明一下如何搭建Redis的Cluster集群環境。革命尚未成功，我還需努力。我把原文的地址也貼出來，裡面的內容不完全一樣，我按著我的理解寫的更詳細瞭。地址如下：【Redis cluster tutorial】

到此這篇關於Redis的Cluster集群搭建的實現步驟的文章就介紹到這瞭,更多相關Redis Cluster集群搭建內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：

• Redis7.0部署集群的實現步驟
• redis集群搭建過程(非常詳細,適合新手)
• Redis5之後版本的高可用集群搭建的實現
• 詳解三分鐘快速搭建分佈式高可用的Redis集群
• Docker中部署Redis集群與部署微服務項目的詳細過程