Redis進階實踐之十一 Redis的Cluster集羣搭建

1、引言

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

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

      　　若是您打算部署Redis的Cluster集羣，即便不是嚴格的要求，咱們也建議閱讀更正式的規範。不過，從這篇文檔開始，咱們能夠先使用Redis Cluster集羣，而後再閱讀規範也是一個不錯的主意。

2、Redis的Cluster模式介紹

　　一、Redis羣集101

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

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

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

     　　　　二、在節點子集遇到故障或沒法與集羣其他部分通訊時繼續運行的能力。


　　二、Redis羣集TCP端口

      　　　　每一個Redis羣集的節點都須要打開兩個TCP鏈接，因爲這兩個鏈接就須要兩個端口，分別是用於爲客戶端提供服務的常規Redis TCP命令端口（例如6379）以及經過將10000和命令端口相加（10000+6379）而得到的端口，就是集羣端口（例如16379）。

     　　 　　第二個大號端口用於羣集總線，即便用二進制協議的節點到節點通訊通道。 節點使用羣集總線進行故障檢測，配置更新，故障轉移受權等。 客戶端不該嘗試與羣集總線端口通訊，爲了保證Redis命令端口的正常使用，請確保在防火牆中打開這兩個端口，不然Redis羣集節點將沒法通訊。

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

     　　　　請注意，爲了讓Redis羣集正常工做，您須要爲每一個節點：

       　　　　一、用於與客戶端進行通訊的普通客戶端通訊端口（一般爲6379）對全部須要到達羣集的客戶端以及全部其餘羣集節點（使用客戶端端口進行密鑰遷移）都是開放的。

       　　　　二、集羣總線端口（客戶端端口+ 10000）必須可從全部其餘集羣節點訪問。

    　　 　　若是您不打開這兩個TCP端口，則您的羣集將沒法正常工做。

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

     
　　三、Redis集羣和Docker

    　　　　目前，Redis羣集不支持NAT地址環境，而且在IP地址或TCP端口被從新映射的通常環境中。

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

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


　　四、Redis集羣數據分片

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

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

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

    　　　　　　 一、節點A包含從0到5500的散列槽。

     　　　　　　二、節點B包含從5501到11000的散列槽。

     　　　　　　三、節點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 做爲參數的命令中一塊兒使用。


　　五、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羣集沒法繼續運行。


　　六、Redis集羣一致性保證

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

    　　　　Redis集羣可能會丟失寫入的第一個緣由是由於它使用異步複製。這意味着在寫入期間會發生如下事情：

      　　　　　　一、你的客戶端寫給主服務器節點 B

      　　　　　　二、主服務器節點B向您的客戶端回覆確認。

      　　　　　　三、主服務器節點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 (節點超時)。

     　　　　在節點超時事後，主節點被認爲是失效的，而且能夠被其副本之一替換。相似地，節點超時事後，主節點沒法感知大多數其餘主節點，它進入錯誤狀態並中止接受寫入。


　　七、Redis羣集配置參數


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

       　　　　　　一、cluster-enabled <yes/no>：若是想在特定的Redis實例中啓用Redis羣集支持就設置爲yes。 不然，實例一般做爲獨立實例啓動。

      　　　　　　 二、cluster-config-file <filename>：請注意，儘管有此選項的名稱，但這不是用戶可編輯的配置文件，而是Redis羣集節點每次發生更改時自動保留羣集配置（基本上爲狀態）的文件，以便可以 在啓動時從新讀取它。 該文件列出了羣集中其餘節點，它們的狀態，持久變量等等。 因爲某些消息的接收，一般會將此文件重寫並刷新到磁盤上。

       　　　　　　三、cluster-node-timeout <milliseconds>：Redis羣集節點能夠不可用的最長時間，而不會將其視爲失敗。 若是主節點超過指定的時間不可達，它將由其從屬設備進行故障切換。 此參數控制Redis羣集中的其餘重要事項。 值得注意的是，每一個沒法在指定時間內到達大多數主節點的節點將中止接受查詢。

       　　　　　　四、cluster-slave-validity-factor <factor>：若是設置爲0，不管主設備和從設備之間的鏈路保持斷開鏈接的時間長短，從設備都將嘗試故障切換主設備。 若是該值爲正值，則計算最大斷開時間做爲節點超時值乘以此選項提供的係數，若是該節點是從節點，則在主鏈路斷開鏈接的時間超過指定的超時值時，它不會嘗試啓動故障切換。 例如，若是節點超時設置爲5秒，而且有效因子設置爲10，則與主設備斷開鏈接超過50秒的從設備將不會嘗試對其主設備進行故障切換。 請注意，若是沒有從服務器節點可以對其進行故障轉移，則任何非零值均可能致使Redis羣集在主服務器出現故障後不可用。 在這種狀況下，只有原始主節點從新加入集羣時，集羣纔會返回可用。

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

      　　　　　　 六、cluster-require-full-coverage <yes / no>：若是將其設置爲yes，則默認狀況下，若是key的空間的某個百分比未被任何節點覆蓋，則集羣中止接受寫入。 若是該選項設置爲no，則即便只處理關於keys子集的請求，羣集仍將提供查詢。


3、建立和使用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集羣環境。

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

                            

                           而後建立6個子目錄，以下圖：

                            

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

 

                二、目錄建立好後，咱們把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  //發生改變就記錄日誌

    　　　　三、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 分別進行全局替換，並保存，完成對其餘子目錄下的配置文件的修改。

　　　　　　　　  

    　　　　四、咱們安裝Redis的Cluster集羣，須要使用Ruby命令，因此咱們必須安裝對Ruby的支持。

　　　　　　　　　

                             在此說明一下，之前的Redis版本下，須要安裝Ruby和Rubygems，可是最新的版本不須要了，只要安裝Ruby，Rubygems就會自動安裝。

                               

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

    　　　　五、咱們安裝完 Ruby 和 Rubygems 後，還須要繼續安裝Redis的Ruby接口程序。

　　　　　　　　gem install redis

　　　　　　　　安裝Redis的ruby接口程序，可能會提示以下，錯誤：redis requires ruby version 2.2.2，怎麼辦呢？若是是第一次遇到這個問題，可能會困擾你一陣子，我這裏也有解決方案，幫你解憂。地址以下：http://www.cnblogs.com/PatrickLiu/p/8454579.html，按步驟執行就能夠，一切順利。
　　　　　　　　
    　　　　六、開始啓動咱們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

　　　　　　　　
    　　　　七、建立集羣，執行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個從站的集羣。

    　　　　八、 若是一切順利，你會看到相似這樣的消息： [OK] All 16384 slots covered， 這意味着至少有一個主實例服務於每一個16384可用的插槽，成功建立了Redis的Cluster集羣環境。

　　　　　　　　

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

  　　　　　　　　一、登錄7000操做：

　　　　　　　　　　redis-cli -c -h 192.168.127.130 -p 7000

　　　　　　　　    　

                            二、登錄7001操做：

　　　　　　　　　　redis-cli -c -h 192.168.127.130 -p 7001

　　　　　　　　　　

                            三、登錄7002操做：

　　　　　　　　　　redis-cli -c -h 192.168.127.130 -p 7002

　　　　　　　　　　

    　　　　十、經過Cluster Nodes命令和Cluster Info命令來看看集羣效果。

　　　　　　　　

    　　　　十一、在集羣上經過增長數據來測試集羣效果。直接看截圖效果吧：

　　　　　　　　

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

4、使用建立羣集腳本建立Redis羣集

    　　若是您不想經過如上所述手動配置和執行單個實例來建立Redis羣集，則有一個更簡單的系統能夠代替以上操做（但您不會學到相同數量的操做細節）。

    　　只需在Redis發行版中檢查 utils/create-cluster 目錄便可。 裏面有一個名爲create-cluster的腳本（與其包含的目錄名稱相同），它是一個簡單的bash腳本。 要啓動具備3個主站和3個從站的6個節點羣集，只需輸入如下命令：
        
        　　 一、create-cluster start

        　　 二、create-cluster create

    　　當redis-trib實用程序但願您接受集羣佈局時，在步驟2中回覆yes。

    　　您如今能夠與羣集交互，默認狀況下，第一個節點將從端口30001開始。 完成後，中止羣集：

        　　一、create-cluster stop.

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


5、測試故障轉移

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

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

    　　咱們能夠識別一個集羣並使用如下命令將其崩潰：

          　　 $ 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

    　　　　如今，主服務器節點正在端口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...

6、手動故障轉移

    　　有時，強制進行故障轉移並不會在主服務器上致使任何問題。例如，爲了升級其中一個主節點的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.

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

7、總結

     　今天就寫到這裏了，關於Cluster的內容尚未寫完，有關動態擴容的內容將在下一篇文章作詳細介紹。這篇文章對不少東西沒有作更細緻的探討，只是從用戶的角度來簡單說明一下如何搭建Redis的Cluster集羣環境。革命還沒有成功，我還需努力。我把原文的地址也貼出來，裏面的內容不徹底同樣，我按着個人理解寫的更詳細了。地址以下：【Redis cluster tutorial】