Redis的高可用方案

1.1 Redis集群的設計原則和初衷

在官方文檔Cluster Spec中屏轰，作者詳細介紹了Redis集群為什么要設計成現(xiàn)在的樣子。最核心的目標有三個：

性能：這是Redis賴以生存的看家本領，增加集群功能后當然不能對性能產生太大影響，所以Redis采取了P2P而非Proxy方式萍虽、異步復制、客戶端重定向等設計嬉愧，而犧牲了部分的一致性贩挣、使用性。
水平擴展：集群的最重要能力當然是擴展没酣，文檔中稱可以線性擴展到1000結點王财。
可用性：在Cluster推出之前，可用性要靠Sentinel保證裕便。有了集群之后也自動具有了Sentinel的監(jiān)控和自動Failover能力绒净，也就是說Redis集群的主從自動集成了Sentinel的功能，在創(chuàng)建主從的時候無需再使用Sentinel偿衰。

1.2 架構變化與CAP理論

在Redis Cluster出現(xiàn)之前（也就是單機版的Redis）挂疆，每個Master之間是沒有任何通信的，所以我們一般使用客戶端（類似Memcache實現(xiàn)集群的方式下翎，把鍋丟給客戶端Driver）或者codis（豆瓣開源的Redis集群方案）和twemproxy（twitter開源的Redis集群方案）這樣的代理做Pre-sharding缤言。

按照CAP理論來說，單機版的Redis屬于保證CP(Consistency & Partition-Tolerancy)而犧牲A(Availability)视事，也就說Redis能夠保證所有用戶看到相同的數(shù)據(jù)（一致性胆萧，因為Redis不自動冗余數(shù)據(jù)）和網(wǎng)絡通信出問題時，暫時隔離開的子系統(tǒng)能繼續(xù)運行（分區(qū)容忍性俐东，因為Master之間沒有直接關系跌穗，不需要通信）订晌，但是不保證某些結點故障時，所有請求都能被響應（可用性蚌吸，某個Master結點掛了的話锈拨，那么它上面分片的數(shù)據(jù)就無法訪問了）。

有了Cluster功能后羹唠，Redis從一個單純的NoSQL內存數(shù)據(jù)庫變成了分布式NoSQL數(shù)據(jù)庫奕枢，CAP模型也從CP變成了AP。也就是說肉迫，通過自動分片和冗余數(shù)據(jù)验辞，Redis具有了真正的分布式能力，某個結點掛了的話喊衫，因為數(shù)據(jù)在其他結點上有備份，所以其他結點頂上來就可以繼續(xù)提供服務杆怕，保證了Availability族购。然而，也正因為這一點陵珍，Redis無法保證曾經(jīng)的強一致性了（因為Redis的主從是異步復制的寝杖，所以主從數(shù)據(jù)的同步會有延遲）。這也是CAP理論要求的互纯，三者只能取其二瑟幕。

1.3 Redis集群實現(xiàn)

Sharing

一個集群系統(tǒng)最重要的一個點就是Sharding（分片）技術，這是實現(xiàn)水平擴展的前提條件留潦。下面介紹一下Redis集群是如何做分片的只盹。

Redis 集群沒有并使用傳統(tǒng)的一致性哈希來分配數(shù)據(jù)，而是采用另外一種叫做“哈希槽 (hash slot)“的方式來分配的兔院。redis cluster 默認分配了 16384 個slot殖卑，當我們set一個key 時，會用CRC16算法來取模得到所屬的slot坊萝，然后將這個key 分到哈希槽區(qū)間的節(jié)點上孵稽，具體算法就是：hash_slot = CRC16(key) % 16384。從上面我們可以看到redis集群一共有16384個slot十偶，所以一個redis集群也就被限制為最多有16384個節(jié)點菩鲜，當然了，在現(xiàn)實世界中惦积，也不可能會有那么多的節(jié)點接校，因為當節(jié)點數(shù)量達到一定的量級時，Redis集群內部的通訊就會占滿整個帶寬荣刑，何談對外提供服務呢馅笙。另外16384這個數(shù)字也不是作者隨意指定的伦乔，Redis集群內部使用位圖（bit map）來標志一個slot是否被占用，為了減少集群之間信息交換的大小董习，信息的大小被固定為2048字節(jié)烈和，所以，crc16生成的是一個16位的整形皿淋，2^16/2048=214=16384招刹。

我們假設現(xiàn)在有3個節(jié)點已經(jīng)組成了集群，分別是：A, B, C 三個節(jié)點窝趣，它們可以是一臺機器上的三個端口疯暑，也可以是三臺不同的服務器。那么哑舒，采用哈希槽 (hash slot)的方式來分配16384個slot 的話妇拯，它們三個節(jié)點分別承擔的slot 區(qū)間是：

節(jié)點A覆蓋0－5460;

節(jié)點B覆蓋5461－10922;

節(jié)點C覆蓋10923－16383.

那么，現(xiàn)在我想設置一個key ,比如叫my_name:

set my_name hanyugang

按照redis cluster的哈希槽算法：CRC16('my_name')%16384 = 12803洗鸵。那么就會把這個key 的存儲分配到 C上了越锈。

-----------------------------------------------------------------------------------------------------------------------------下面插播一條小貼士------------------------------------------------------------------------------------------------------------------------------------------------------

Tips：如何計算一個key的hash slot值呢？

1膘滨、使用redis集群自帶的CLUSTER KEYSLOT key命令來計算：

使用cluster keyslots 命令計算hash slot

2甘凭、使用在線計算工具：http://www.ip33.com/crc.html

使用在線工具命令計算hash slot

記得參數(shù)模型選擇CRC-16/XMODEM哦，計算出來的數(shù)值別忘了MOD16384呢火邓！

---------------------------------------------------------------------------------------------------------------------------------------------------------------小貼士完-----------------------------------------------------------------------------------------------------------------------------------

這也是使用redis集群管理工具redis-trib.rb的默認slot的分配結果丹弱。當然了我們也可以不使用redis-trib.rb工具，通過redis提供的cluster指令集設置和分配slot铲咨，這是后話躲胳，暫且不提。

你可能注意到redis集群使用hash_slot來切分數(shù)據(jù)鸣驱，而不是傳統(tǒng)的一致性哈希算法來切分數(shù)據(jù)泛鸟。hash slot的算法比較簡單，相當于最最原始的取模算法的加強版踊东，這樣做的好處就是計算簡單北滥，邏輯清晰。壞處當然也大大的闸翅，不然那么多的一致性哈希算法被發(fā)明出來也就沒道理了再芋。我假設您了解一致性hash算法的目的，一句話：相當于提供了一個虛擬的中間層济赎，把虛擬的slot和真實的物理節(jié)點關聯(lián)起來，當動態(tài)地添加和減少節(jié)點時司训，能夠有效地減少數(shù)據(jù)的遷移量，這也應證了業(yè)界著名的一句格言：沒有什么是添加一層（中間件）解決不了問題的壳猜。由于redis的集群沒有使用一致性hash算法勾徽，它的hash slot在集群初始化就是固定分配好的统扳，因此當添加一個或者減少一個節(jié)點時，就不能做到自動化了咒钟，也就是說當添加一個節(jié)點或者刪除一個節(jié)點時吹由，需要人工的介入，這點和cassandra等分布式NOSQL比起來簡直是遜爆了倾鲫，不是嗎萍嬉？好在redis的作者也意識到這個問題帚湘，提供了一個redis-trib.rb集群工具甚淡，可以“比較”方便地對進行數(shù)據(jù)的遷移。^_

添加一個節(jié)點：
1资柔、把新的節(jié)點添加到集群中撵割，通過cluster meet命令啡彬，這樣添加后的新節(jié)點就是一個slot為空的主節(jié)點
2、為新的節(jié)點分配slot纵搁，由于之前的集群可能把slot已經(jīng)分配完畢往踢，這個時候就需要從其他節(jié)點把slot遷移過來（當然數(shù)據(jù)也會一起遷移過來）

刪除一個節(jié)點：
1、redis集群是無法刪除一個slot不為空的節(jié)點的利职，因此想要刪除一個節(jié)點猪贪，就需要把該節(jié)點的slot遷移到其他節(jié)點上去
2、slot遷移完畢后干花，使用cluster forget命令把該節(jié)點從集群中刪除

看到了嗎池凄，搓搓的鬼廓。

另外Redis集群本身不提供任何的負載均衡，因此當出現(xiàn)嚴重的負載不均的問題時——由于Redis集群使用key對數(shù)據(jù)進行分片尤慰，因此如果您給key起名的時候過于執(zhí)著伟端，剛好所有的key都映射到同一個節(jié)點上去了匪煌，其他的節(jié)點數(shù)據(jù)為空（當然了萎庭，這不太可能，crc16算法還是比較均衡的肴敛，O(∩_∩)O哈哈~医男，您不可能那么點背巩搏，這里只是為了說明Redis集群本身不提供任何的Load Balance而已）———我們需要人工的對數(shù)據(jù)進行遷移（對數(shù)據(jù)的遷移實際上就是對slot的遷移嘛）贯底，這點也是搓搓的撒强。

Proxy飘哨？NOＫ銎尽Ｍ城！

Redis集群使用了去中心化腕扶、去中間件的設計方案半抱。如果您熟悉Mongodb的話膜宋，一定對mongos記憶猶新秋茫，然而Redis集群不提供像mongodb提供的mongos一樣的東西，把客戶端發(fā)出的一條指令轉發(fā)到不同的節(jié)點乘瓤，然后再把結果合并返回給客戶端。Redis集群使用下面的策略來處理一條命令：

1抬吟、假設客戶端連接到A節(jié)點火本，去請求一個key叫做key_3的值钙畔，很巧，這個key所在的slot位于A節(jié)點上(CRC16('key3')=3740)簿盅，那么Redis就會直接返回key_3的值給客戶端

2、如果這時客戶端去請求一個key叫做my_name的值該怎么辦呢棚瘟？我們知道key=my_name的值存儲在C節(jié)點上偎蘸，這時Redis就會返回一個MOVED的反饋給客戶端瞬内，告訴客戶端my_name這個值在C節(jié)點上，你要到那里去取章咧。如下圖所示：

MOVED重定向

可以看到慧邮，Redis集群返回了一個Redirect消息給客戶端舟陆，告訴客戶端你要的key=my_name的值存儲在10.91.42.213也就是C節(jié)點上秦躯，你到那里去取吧踱承。如你所見，最終服務器還是返回了hanyugang值給客戶端昙沦，那么這個返回值是Redis內部做了跳轉返回給客戶端的嗎载荔？你太天真了懒熙，這個其實是redis-cli又發(fā)起了一次請求到C節(jié)點上才取回的（所以在運行redis-cli的時候要加上-c參數(shù)哦工扎，該參數(shù)表示讓redis-cli支持集群功能）。實際上Redis集群什么都沒做呈础，它只是告訴你key=my_name的值在C節(jié)點上而已猪落。希望您可以通過這個例子看出Redis集群對命令的處理方式，No Proxy的方式就是這樣做的蓝仲，把鍋丟給客戶端袱结，我不會做任何的內部處理途凫。

您也可能會問维费，Redis集群是怎么知道key=my_name的值存儲在C節(jié)點上的犀盟？原因就是Redis集群通過bus port，使用Gossip的協(xié)議在集群之間相互交換信息倡怎，也就是說整個集群是知道節(jié)點和slot的對應關系的监署，通過計算my_name的slot是12803就知道這個值存儲在C節(jié)點上了（C節(jié)點負責的slot是10923－16383嘛）钠乏。值得注意的是春塌，這個Bus Port是無法設置的摔笤，它的值永遠是與客戶端通信的端口（默認是6379）+10000垦写，默認值當然也就是16379了梯投。還需要注意的一個點是：在早期的Redis集群版本中，在節(jié)點相互通信的時候尔许，整個集群會檢查16384個slot是否被完全覆蓋终娃，如果發(fā)現(xiàn)沒有被完全覆蓋，整個集群是拒絕對外提供服務的余佛，這個就比較坑爹了辉巡，一部分節(jié)點down掉時蕊退，整個節(jié)點就無法對外提供服務瓤荔，說好的高可用呢茉贡？所以在新的版本里，這個問題得到了修正放椰，在redis的配置文件中砾医，有個cluster-require-full-coverage的設置項如蚜，我們建議一定要把這個值設置為no（默認是yes哦）影暴，不然redis集群的高可用會變的辣雞無比型宙。

No Proxy妆兑？ ProblemＣ恰Ｐ究薄荷愕！

正是由于上面介紹的去中心化路翻、去中間件的設計，Redis集群對Multi Key的操作做了諸多限制蝶桶。一句話：對于Multi Key的操作被限制在同一個slot上面真竖，跨節(jié)點的Multi Key操作恢共，就更別想了讨韭。在單機版本中愉快的使用MGET key_1 key_2 key_3 ...的命令癣蟋，在集群版本中會報錯哦疯搅！

支持multi key的命令需要所有的key都在一個hash slot上

同理幔欧，Lua腳本中的multi key操作礁蔗，transcation上面的multi key操作浴井，pipleline上的multi key操作等都會受到這個限制的影響。MMP，怎么辦屠缭？好消息是Redis集群提供了hash tag的解決辦法（這個hash tag其實并不是什么新鮮玩意呵曹，在redis官方集群方案出來之前奄喂，第三方的tweenproxy和codis等早就采取了這個方案）跨新，你可以這么做在set的時候使用hash tag：mset {key}_1 xxx {key}_2 yyy {key}_3 zzz域帐，這樣就可以在集群上執(zhí)行mget {key}_1 {key}_2 {key}_3了：

hash tag的作用

這正是hash tag的用處：

在計算hash slots時有一個意外的情況肖揣，用于支持“hash tags”龙优；

hash tags用于確保多個keys能夠被分配在同一個hash slot中彤断，用于支持multi-key操作。

hash tags的實現(xiàn)比較簡單筒愚，key中“{}”之間的字符串就是當前key的hash tags巢掺，在計算slot的時候只使用hash tag陆淀，而不是使用整個key轧苫，因此具有相同hash tag的key總會被存儲在相同的slot上含懊；

hash tag還支持多級嵌套，我想為了程序的簡單化酥筝，還是不要使用多級嵌套了嘿歌，傷腦宙帝，因為為key起個有意義的名字本身就是一件很有挑戰(zhàn)性的難題了募闲，不是嗎？

Redis集群對一些復雜的運算沪编，比如Set的intersection等操作進行了重新實現(xiàn)蚁廓，只要兩個Set位于同一個節(jié)點厨幻，就可以進行運算相嵌；另外對Publish/Subscribe做了重新實現(xiàn)，能夠保證在集群環(huán)境下况脆，提供和單機版本相同的功能饭宾，也就是說在集群上任何一個節(jié)點上Publish格了，在集群的任何一個節(jié)點上都能夠Sub到這個信息。

還有一種很特別的情況盛末，就是當Redis集群在做數(shù)據(jù)遷移時，一個key剛從一個節(jié)點遷移到另外一個節(jié)點悄但，那么請求該節(jié)點數(shù)據(jù)的時候檐嚣，Redis會返回一個ASK反饋，并附帶該key目前所處的新節(jié)點的位置，此時客戶端Driver需要向新的節(jié)點位置發(fā)起ASKING請求嗡贺；當然這是對單個key進行操作的情況隐解，如果是multi key的操作，那么Redis將會直接返回一個失敗的消息诫睬。因此在做數(shù)據(jù)遷移的時候厢漩，multi key的操作有很大的概率會出錯。目前這個無解哦岩臣，您只能等待遷移完成在或者遷移回滾再進行操作了。

順便提一下：Redis集群取消了db number的支持宵膨，也就是說之前單機版本的db0架谎、db1...db16不復存在了，在集群環(huán)境中使用SELECT命令是會報錯了辟躏。

Tips：客戶端Driver是如何實現(xiàn)Redis集群的這些奇葩的特性的谷扣？

客戶端Driver和Redis集群的連接：

對于Redis集群而言，客戶端無論連接到A節(jié)點還是C節(jié)點捎琐，其實總能獲取到相同的結果会涎，因此Redis集群的客戶端Driver在和集群建立連接的時候并不是同時與集群中的所有節(jié)點都建立連接哦，實際上是這樣做的：隨機選擇集群中的一個節(jié)點（集群中的節(jié)點們當然組成了一個HOST:PORT數(shù)組）瑞凑，進行連接末秃，如果連接不成功，重試下一個節(jié)點籽御，直到有一個節(jié)點能夠連接成功练慕。

客戶端Driver處理重定向的方式：

上面已經(jīng)介紹了Redis集群經(jīng)常會返回重定向的反饋消息告訴客戶端Driver，信息沒有存儲在我這里技掏，你到另外一個節(jié)點去找吧铃将。如果客戶端Driver按照這個思路來做，實際上是要發(fā)起2次請求的哑梳，這和Redis集群的設計初衷相違背（Redis集群之所以使用重定向來處理命令劲阎，就是為了速度，現(xiàn)在要發(fā)起2次請求才能獲取到最終值鸠真，豈不是南轅北轍了悯仙？）。當然客戶端Driver不會那么傻的弧哎，它們在實現(xiàn)的時候是這么做的：客戶端本地會保存一份slot與節(jié)點的映射Map雁比，比如現(xiàn)在要存儲key=my_name的值，客戶端driver計算出CRC16('my_name') mod 16384 = 12803撤嫩，然后查找本地存儲的slot與節(jié)點的映射Map偎捎，發(fā)現(xiàn)slot 12803位于節(jié)點C上，因此客戶端Driver會直接向C節(jié)點發(fā)起請求寻拂，這就做到了一步到位祭钉〖号妫可以想象申尼，這個Map并不是一直不變的师幕，什么時候客戶端要更新自己本地的映射Map呢，很簡單啦灭将，當出現(xiàn)MOVED反饋的時候庙曙，客戶端Driver不但會再次發(fā)起請求矾利，還會更新本地的映射Map哦馋袜。另外對于Redis集群返回的ASK請求欣鳖，客戶端Driver是不應該更新本地的映射Map的，因為處于ASK狀態(tài)只是一種臨時的狀態(tài)（ASK狀態(tài)本身是由于數(shù)據(jù)的遷移造成的什荣，數(shù)據(jù)遷移很可能會取消稻爬，所以這只是一種臨時狀態(tài)桅锄，只有當遷移完畢時，slot的位置才是確定的）翠肘。

說了那么多束倍，Redis集群的客戶端Driver必須要按照上面的要求實現(xiàn)嗎绪妹？不是的柿究，這只是一個建議而已笛求。你完全可以按照使用2次請求的方案來實現(xiàn)探入，不過有點笨是不是蜂嗽？

-------------------------------------------------------------------------------------------------------------------------------------小貼士完-------------------------------------------------------------------------------------------------------------------------------------------------------------

高可用

下面介紹一下Redis集群是怎么實現(xiàn)高可用的植旧。傳統(tǒng)的分布式NOSQL數(shù)據(jù)庫一般都是使用數(shù)據(jù)副本的概念來實現(xiàn)數(shù)據(jù)的冗余病附，從而實現(xiàn)高可用完沪。

Redis集群由于歷史包袱或者說實現(xiàn)的簡單化嵌戈，使用主從異步復制的技術來實現(xiàn)數(shù)據(jù)的冗余熟呛，并通過集成Sentinel的功能實現(xiàn)自動Fail Over來實現(xiàn)整個集群的高可用庵朝。

也就是說我們在做Redis集群的時候又厉，如果沒有為主節(jié)點掛載一個Slave馋没，那么這個集群就是脆弱的篷朵，不堪一擊的声旺，因為只要有主節(jié)點掛掉腮猖，沒有Slave節(jié)點頂上赞枕，整個slot環(huán)就會有缺失炕婶，從而導致集群變得”部分可用”。

當我們在談論Redis集群的時候项滑，自然就把Slave包含進去了枪狂，嗯州疾，這是約定俗成孝治。

這也解釋了為什么我們在做Redis集群的時候要開啟6個實例（3主3從嘛）审磁。至于為什么要3主态蒂，因為redis集群提供的redis-trib.rb工具要求要有3主3從呀，至于為什么要使用redis-trib.rb的集群工具手素，當然是為了方便集群的部署咯。

Redis集群可以2主2從嗎稿黍，可以的巡球，這需要我們手工為Redis集群分配slot等一系列繁瑣的操作邓嘹。得不償失。

另外Redis集群的主從自動集成了Sentinel的功能矿筝，所有的failover和主節(jié)點down掉后恢復自動成為新主節(jié)點的Slave窖维，這些都是自動化的铸史，因為有sentinel细诸。這算是Redis集群比較良心的一個點了震贵。

另外Redis集群還支持Slave Migration的功能水评，一句話：當某個主節(jié)點A配置了多于1個的Slave時中燥，如果另外一個主節(jié)點B的所有Slave不巧都掛掉了疗涉，那么A主節(jié)點下面的某個slave（不是隨機哦）會自動遷移，成為B節(jié)點的Slave绽淘。這個特性加強了Redis集群的可用性沪铭。詳見redis配置文件中的cluster-migration-barrier配置項。

Redis集群的部署

上面介紹了Redis集群的一些實現(xiàn)細節(jié)椰憋，下面我們開始實踐了赔退，首先要部署集群的環(huán)境离钝，Let's GO！

建立Redis集群的前提條件

首先我們要開啟Redis的集群功能哦慧域，這個比較簡單昔榴，就是修改Redis的配置文件而已碘橘，一個最小化的集群的配置如下：

綁定地址：bind 192.168.XXX.XXX痘拆。不能綁定到127.0.0.1或localhost纺蛆，否則指導客戶端重定向時會報”Connection refused”的錯誤。
開啟Cluster：cluster-enabled yes
集群配置文件：cluster-config-file nodes-7000.conf温峭。這個配置文件不是要我們去配的凤藏，而是Redis運行時保存配置的文件揖庄，所以我們也不可以修改這個文件欠雌。
集群超時時間：cluster-node-timeout 15000桨昙。結點超時多久則認為它宕機了。
槽是否全覆蓋：cluster-require-full-coverage no齐苛。默認是yes凹蜂，只要有結點宕機導致16384個槽沒全被覆蓋玛痊，整個集群就全部停止服務，所以一定要改為no

修改了這些配置之后擂煞，才算真正的開啟了Redis的集群功能对省。

然后準備6個Redis的實例吧（每個Redis的實例都要做上面的配置修改哦）。我們假設集群的環(huán)境如下：

Host	Port	Master/Salve
10.91.42.211	6379	Master
10.91.42.211	6479	Slave
10.91.42.212	6379	Master
10.91.42.212	6479	Slave
10.91.42.213	6379	Master
10.91.42.213	6479	Slave

啟動這6個實例哦０小２质帧嗽冒！
redis-server /etc/redis/redis.conf
然后運行redis集群提供的集群工具：

./redis-trib.rb create \
--replicas 1 \
10.91.42.211:6379 \
10.91.42.212:6379 \
10.91.42.213:6379 \
10.91.42.211:6479 \
10.91.42.212:6479 \
10.91.42.213:6479

這個創(chuàng)建集群的命令行會使用前三個參數(shù)作為Master辛慰，后三個作為Slave，然后會詢問你是否接受這樣的配置麻汰，輸入“yes”戚篙。

等待一會岔擂，整個集群就會被建立起來。很方便的塑崖。值得注意的是：這時候Redis的配置不能設置密碼规婆，因為redis-trib.rb工具不支持提供密碼驗證的功能抒蚜。

至此嗡髓，使用redis-trib.rb工具就已經(jīng)把所有的Redis集群環(huán)境搭建起來了。下面介紹一下如何手工搭建一個Redis的集群環(huán)境颅夺，知其然才能知其所以然嘛吧黄！

看似非常簡單拗慨，可是這個腳本都干了什么事情呢赵抢，如果我們手動建立Redis的集群該怎么做呢？
1烦却、假設我們已經(jīng)運行了上面介紹的6個redis的實例

2其爵、集群發(fā)現(xiàn)：CLUSTER MEET
最開始時摩渺，每個Redis實例自己是一個集群摇幻，我們通過cluster meet讓各個結點（這里是指角色為MASTER的節(jié)點啦）互相“握手”绰姻。這也是Redis Cluster目前的一個欠缺之處：缺少結點的自動發(fā)現(xiàn)功能狂芋。

redis-cli -h 10.91.42.211 -p 6379 CLUSTER MEET 10.91.42.212 6379
redis-cli -h 10.91.42.211 -p 6379 CLUSTER MEET 10.91.42.213 6379

運行了上面的命令之后主節(jié)點的集群就建立起來了辆影，他們會自動發(fā)現(xiàn)彼此黍特。

3次慢、角色設置：CLUSTER REPLICATE
主節(jié)點全部“握手”成功后，就可以用cluster replicate命令為結點指定角色了翔曲，默認每個結點都是Master迫像。
3.1 把10.91.42.211:6479節(jié)點指派為10.91.42.212:6379節(jié)點的Slave節(jié)點：
redis-cli -c -h 10.91.42.211 -p 6479 cluster replicate 33c0bd93d7c7403ef0239ff01eb79bfa15d2a32c
注意后面的33c0bd93d7c7403ef0239ff01eb79bfa15d2a32c，這個是Redis集群中唯一標識一個Redis實例的Node ID瞳遍，這里我們假設10.91.42.212:6379節(jié)點的Node ID為：33c0bd93d7c7403ef0239ff01eb79bfa15d2a32c闻妓，這個ID可以通過cluster nodes命令來顯示，也可以通過nodes.conf來查看掠械，還記得cluster-config-file配置項嗎由缆，這個ID就會保存在這個配置文件中。
3.2 把10.91.42.212:6479節(jié)點指派為10.91.42.213:6379節(jié)點的Slave節(jié)點：
redis-cli -c -h 10.91.42.212 -p 6479 cluster replicate 63162ed000db9d5309e622ec319a1dcb29a3304e
3.3 把10.91.42.213:6479節(jié)點指派為10.91.42.211:6379節(jié)點的Slave節(jié)點：
redis-cli -c -h 10.91.42.213 -p 6479 cluster replicate 45baa2cb45435398ba5d559cdb574cfae4083893
Tips：不要把主從都設置在同一臺機器上哦猾蒂，原因你懂得均唉，一臺機器壞掉主從都掛掉，還談什么主從切換舔箭，fail over时捌！

4、hash slot 指派：CLUSTER ADDSLOTS
設置好主從關系之后扒袖，就可以用cluster addslots命令指派16384個槽的位置了（這里要在Master節(jié)點上指派哦）

redis-cli -c -h 10.91.42.211 -p 6379 cluster addslots {0..5460}
redis-cli -c -h 10.91.42.212 -p 6379 cluster addslots {5461..10922}
redis-cli -c -h 10.91.42.211 -p 6379 cluster addslots {10923..16383}

嗯呢飒泻，16384個slot已經(jīng)分配完畢了史辙。
至此生巡，我們手工搭建了和redis-trib.rb工具搭建的一樣的Redis的集群環(huán)境了。嗯呢，其實redis-trib.rb腳本就是干了這些事情寥院。
這也解釋了為什么我們需要6臺Redis的實例估蹄，因為redis-trib.rb工具需要呀，我們當然可以手工搭建2主2從的Redis集群，步驟有些麻煩不是嗎？再者，Redis官方也建議3主3從的集群配置垢村，因此我們?yōu)榱送祽型刂睿褪褂?主3從的Redis集群環(huán)境吧倍谜！
至于添加一個節(jié)點到集群露泊，以及刪除集群中的一個節(jié)點耘拇，以及數(shù)據(jù)的遷移嘉涌，redis-trib工具都有相應的功能题篷，為了防止這個文檔過長，具體的細節(jié)就不再贅述了，當您需要時，您可以查閱Redis的官方文檔。