一、引言

 本文檔只對Redis的Cluster集群做簡單的介紹，并沒有對分布式系統(tǒng)的所涉及到的概念做深入的探討。本文只是針對如何設(shè)置集群、測試和操作集群做了簡述，并且從用戶的角度描述了系統(tǒng)的行為，并不涉及Redis集群規(guī)范中所包含的細節(jié)。但是，本教程試圖從最終用戶的角度來解釋有關(guān)Redis的Cluster集群的可用性和一致性的特點，并以簡單易懂的方式講解。

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

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

二、Redis的Cluster模式介紹

1、Redis群集101

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

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

1、在多個節(jié)點之間自動分割數(shù)據(jù)集的能力。

2、在節(jié)點子集遇到故障或無法與集群其余部分通信時繼續(xù)運行的能力。

2、Redis群集TCP端口

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

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

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

請注意，為了讓Redis群集正常工作，您需要為每個節(jié)點：

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

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

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

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

3、Redis集群和Docker

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

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

為了使Docker與Redis Cluster兼容，您需要使用Docker的主機聯(lián)網(wǎng)模式。 請查看Docker文檔中的--net = host選項以獲取更多信息。

4、Redis集群數(shù)據(jù)分片

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

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

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

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

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

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

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

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

5、Redis集群之主從模型

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

在我們具有節(jié)點A，B，C的示例的群集中，如果節(jié)點B失敗，則群集無法繼續(xù)，因為我們沒有辦法再在5501-11000范圍內(nèi)提供散列槽。然而，當創(chuàng)建集群時（或稍后），我們?yōu)槊總€主服務(wù)器節(jié)點添加一個從服務(wù)器節(jié)點，以便最終集群由作為主服務(wù)器節(jié)點的A，B，C以及作為從服務(wù)器節(jié)點的A1，B1，C1組成，如果節(jié)點B發(fā)生故障，系統(tǒng)能夠繼續(xù)運行。節(jié)點B1復(fù)制B，并且B失敗，則集群將促使節(jié)點B1作為新的主服務(wù)器節(jié)點并且將繼續(xù)正確地操作。

但請注意，如果節(jié)點B和B1在同一時間發(fā)生故障，則Redis群集無法繼續(xù)運行。

6、Redis集群一致性保證

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

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

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

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

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

基本上，性能和一致性之間需要權(quán)衡。

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

還有另一個值得注意的情況，Redis集群也將丟失數(shù)據(jù)的寫入，這種情況發(fā)生在網(wǎng)絡(luò)分區(qū)的時候，客戶端與包含至少一個主服務(wù)器的少數(shù)實例隔離。

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

分區(qū)發(fā)生后，可能在分區(qū)的一側(cè)有A，C，A1，B1，C1，另一側(cè)有B和Z1。

Z1仍然能夠?qū)懭隑，它也會接受Z1的寫入。如果分區(qū)在很短的時間內(nèi)恢復(fù)，則群集將正常繼續(xù)。但是，如果分區(qū)使用比較長的時間將B1提升為多數(shù)側(cè)分區(qū)的主設(shè)備，則Z1發(fā)送給B的寫入操作將丟失。

請注意，Z1能夠發(fā)送給B的寫入量有一個最大窗口（maximum window）：如果分區(qū)多數(shù)側(cè)有足夠的時間選擇一個從設(shè)備作為主設(shè)備，那么少數(shù)側(cè)的每個主節(jié)點將停止接受寫操作。

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

在節(jié)點超時過后，主節(jié)點被認為是失效的，并且可以被其副本之一替換。類似地，節(jié)點超時過后，主節(jié)點無法感知大多數(shù)其他主節(jié)點，它進入錯誤狀態(tài)并停止接受寫入。

7、Redis群集配置參數(shù)

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

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

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

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

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

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

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

三、創(chuàng)建和使用Redis群集

注意：手動部署Redis群集，這對了解集群的操作細節(jié)方面是非常重要的。但是，如果想要啟動群集并盡快運行（盡快），請?zhí)^本節(jié)和下一節(jié)，直接使用create-cluster腳本直接創(chuàng)建Redis群集。

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

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

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

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

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

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

然后創(chuàng)建6個子目錄，如下圖：

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

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

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

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

3、7000目錄下的Redis.conf配置文件修改后，分別拷貝到其他子目錄，依次為：7001，7002，7003，7004，7005，根據(jù)上面的配置，我們只需修改和端口號有關(guān)的項目，在Linux系統(tǒng)下，我們通過命令：%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 后，還需要繼續(xù)安裝Redis的Ruby接口程序。

gem install redis

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

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、創(chuàng)建集群，執(zhí)行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實用程序?qū)嵗龍?zhí)行特殊命令以創(chuàng)建新集群，檢查或重新設(shè)置現(xiàn)有集群，等等。 redis-trib實用程序位于Redis源代碼分發(fā)的src目錄中，當然也可以拷貝到其他目錄中，以方便使用。 您需要安裝redis gem才能運行redis-trib。

這里使用的命令是create，因為我們想創(chuàng)建一個新的集群。 選項--replicas 1 意味著我們需要為每個創(chuàng)建的主服務(wù)器節(jié)點創(chuàng)建一個從服務(wù)器節(jié)點。其他參數(shù)是我想用來創(chuàng)建新集群的實例的地址列表。

顯然，我們要求的唯一設(shè)置是創(chuàng)建一個具有3個主站和3個從站的集群。

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

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、在集群上通過增加數(shù)據(jù)來測試集群效果。直接看截圖效果吧：

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

四、使用創(chuàng)建群集腳本創(chuàng)建Redis群集

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

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

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

您現(xiàn)在可以與群集交互，默認情況下，第一個節(jié)點將從端口30001開始。 完成后，停止群集：

1、create-cluster stop.

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

五、測試故障轉(zhuǎn)移

注意：在此測試期間，應(yīng)該運行一致性測試應(yīng)用程序時打開選項卡。

為了觸發(fā)故障轉(zhuǎn)移，我們可以做的最簡單的事情（這也是分布式系統(tǒng)中可能發(fā)生的語義上最簡單的故障）是使單個進程崩潰，在我們的當前的情況下就是單個主進程。

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

$ 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都是主服務(wù)器節(jié)點。 讓我們用 DEBUG SEGFAULT 命令使節(jié)點7002崩潰：

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

現(xiàn)在我們可以看一致性測試的輸出以查看它報告的內(nèi)容。

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) |

正如您在故障轉(zhuǎn)移期間所看到的，系統(tǒng)無法接受578次讀取和577次寫入，但是在數(shù)據(jù)庫中未創(chuàng)建任何不一致。 這聽起來可能會出乎意料，因為在本教程的第一部分中，我們聲明Redis群集在故障轉(zhuǎn)移期間可能會丟失寫入，因為它使用異步復(fù)制。 我們沒有說的是，這種情況不太可能發(fā)生，因為Redis會將答復(fù)發(fā)送給客戶端，并將命令復(fù)制到從服務(wù)器，同時，因此會有一個非常小的窗口來丟失數(shù)據(jù)。 但是很難觸發(fā)這一事實并不意味著這是不可能的，所以這不會改變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

現(xiàn)在我們可以檢查故障轉(zhuǎn)移后的群集設(shè)置（注意，在此期間，我重新啟動了崩潰的實例，以便它重新加入作為從屬群集）：

$ 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

現(xiàn)在，主服務(wù)器節(jié)點正在端口7000,7001和7002上運行。以前是主服務(wù)器節(jié)點，即運行在端口7005上的Redis實例，現(xiàn)在是7002的從服務(wù)器節(jié)點。

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...

六、手動故障轉(zhuǎn)移

有時，強制進行故障轉(zhuǎn)移并不會在主服務(wù)器上導致任何問題。例如，為了升級其中一個主節(jié)點的Redis進程，最好將其故障轉(zhuǎn)移，以便將其轉(zhuǎn)變?yōu)橐粋€對可用性影響最小的從服務(wù)器。

Redis Cluster使用CLUSTER FAILOVER命令支持手動故障轉(zhuǎn)移，該命令必須在要故障轉(zhuǎn)移的主服務(wù)器的一個從服務(wù)器上執(zhí)行。

手動故障轉(zhuǎn)移是比較特殊的，并且與實際主控故障導致的故障轉(zhuǎn)移相比更安全，因為它們是以避免數(shù)據(jù)丟失的方式發(fā)生，只有在系統(tǒng)確定新主服務(wù)器節(jié)點處理完全部來自舊主服務(wù)器節(jié)點的復(fù)制流后才將客戶從原始主服務(wù)器節(jié)點切換到新主服務(wù)器節(jié)點。

這是您在執(zhí)行手動故障轉(zhuǎn)移時在從服務(wù)器節(jié)點的日志中看到的內(nèi)容：

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

          # 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.

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

七、總結(jié)

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

到此這篇關(guān)于Redis的Cluster集群搭建的實現(xiàn)步驟的文章就介紹到這了,更多相關(guān)Redis Cluster集群搭建內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！