一、引言

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

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

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

二、Redis的Cluster模式介紹

1、Redis群集101

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

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

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

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

2、Redis群集TCP端口

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

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

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

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

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

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

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

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

3、Redis集群和Docker

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

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

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

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

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

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

Redis集群中的每個(gè)節(jié)點(diǎn)負(fù)責(zé)哈希槽的一個(gè)子集，例如，您可能有一個(gè)具有3個(gè)節(jié)點(diǎn)的集群，其中：

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

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

因?yàn)閷⑸⒘胁蹚囊粋€(gè)節(jié)點(diǎn)移動到另一個(gè)節(jié)點(diǎn)不需要停機(jī)操作，添加和移除節(jié)點(diǎn)或更改節(jié)點(diǎn)占用的散列槽的百分比也不需要任何停機(jī)時(shí)間。

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

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

5、Redis集群之主從模型

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

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

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

6、Redis集群一致性保證

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

Redis集群可能會丟失寫入的第一個(gè)原因是因?yàn)樗褂卯惒綇?fù)制。這意味著在寫入期間會發(fā)生以下事情：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要創(chuàng)建一個(gè)集群，我們需要做的第一件事是在集群模式下運(yùn)行幾個(gè)空的Redis實(shí)例。這就意味著群集不是使用普通的Redis實(shí)例創(chuàng)建的，因?yàn)樾枰渲锰厥饽Ｊ?，以便Redis實(shí)例啟用群集特定的功能和命令。

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

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

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

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

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

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

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

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

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

bind 192.168.127.130  //綁定服務(wù)器IP地址
port 7000  //綁定端口號，必須修改，以此來區(qū)分Redis實(shí)例
daemonize yes  //后臺運(yùn)行
pidfile /var/run/redis-7000.pid  //修改pid進(jìn)程文件名，以端口號命名
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  //配置每個(gè)節(jié)點(diǎn)的配置文件，同樣以端口號為名稱
cluster-node-timeout 15000  //配置集群節(jié)點(diǎn)的超時(shí)時(shí)間，可改可不改
appendonly yes  //啟動AOF增量持久化策略
appendfsync always  //發(fā)生改變就記錄日志

3、7000目錄下的Redis.conf配置文件修改后，分別拷貝到其他子目錄，依次為：7001，7002，7003，7004，7005，根據(jù)上面的配置，我們只需修改和端口號有關(guān)的項(xiàng)目，在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 分別進(jìn)行全局替換，并保存，完成對其他子目錄下的配置文件的修改。

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

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

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腳本，這個(gè)腳本文件可以拷貝出來，我是把它放在這個(gè)目錄：/root/application/program/redis/，當(dāng)然在這個(gè)目錄下，也有其他文件，比如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集群命令行實(shí)用程序redis-trib的幫助，Ruby實(shí)用程序?qū)?shí)例執(zhí)行特殊命令以創(chuàng)建新集群，檢查或重新設(shè)置現(xiàn)有集群，等等。 redis-trib實(shí)用程序位于Redis源代碼分發(fā)的src目錄中，當(dāng)然也可以拷貝到其他目錄中，以方便使用。 您需要安裝redis gem才能運(yùn)行redis-trib。

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

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

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

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

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ù)來測試集群效果。直接看截圖效果吧：

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

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

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

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

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

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

1、create-cluster stop.

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

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

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

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

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

$ 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é)點(diǎn)。 讓我們用 DEBUG SEGFAULT 命令使節(jié)點(diǎn)7002崩潰：

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

現(xiàn)在我們可以看一致性測試的輸出以查看它報(bào)告的內(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)建任何不一致。 這聽起來可能會出乎意料，因?yàn)樵诒窘坛痰牡谝徊糠种?，我們聲明Redis群集在故障轉(zhuǎn)移期間可能會丟失寫入，因?yàn)樗褂卯惒綇?fù)制。 我們沒有說的是，這種情況不太可能發(fā)生，因?yàn)镽edis會將答復(fù)發(fā)送給客戶端，并將命令復(fù)制到從服務(wù)器，同時(shí)，因此會有一個(gè)非常小的窗口來丟失數(shù)據(jù)。 但是很難觸發(fā)這一事實(shí)并不意味著這是不可能的，所以這不會改變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è)置（注意，在此期間，我重新啟動了崩潰的實(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é)點(diǎn)正在端口7000,7001和7002上運(yùn)行。以前是主服務(wù)器節(jié)點(diǎn)，即運(yùn)行在端口7005上的Redis實(shí)例，現(xiàn)在是7002的從服務(wù)器節(jié)點(diǎn)。

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

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

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

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

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

＃接受用戶的手動故障轉(zhuǎn)移請求。
       　?。Ｒ褧和５闹鞣?wù)器手動故障轉(zhuǎn)移接收復(fù)制的偏移量：347540
       　?。Ｌ幚硭兄鞣?wù)器節(jié)點(diǎn)的復(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é)點(diǎn)上的客戶端都已停止工作。與此同時(shí)，主服務(wù)器節(jié)點(diǎn)將其復(fù)制偏移量發(fā)送給從服務(wù)器節(jié)點(diǎn)，該從服務(wù)器節(jié)點(diǎn)將等待達(dá)到其側(cè)面的偏移量。當(dāng)達(dá)到復(fù)制偏移量時(shí)，將啟動故障轉(zhuǎn)移，并向舊主服務(wù)器通知配置開關(guān)。 當(dāng)舊主服務(wù)器節(jié)點(diǎn)上的客戶端被解鎖時(shí)，它們會被重定向到新主服務(wù)器。

七、總結(jié)

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

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