在服務(wù)開(kāi)發(fā)中，單機(jī)都會(huì)存在單點(diǎn)故障的問(wèn)題，及服務(wù)部署在一場(chǎng)臺(tái)服務(wù)器上，一旦服務(wù)器宕機(jī)服務(wù)就不可用，所以為了讓服務(wù)高可用，分布式服務(wù)就出現(xiàn)了，將同一服務(wù)部署到多臺(tái)機(jī)器上，即使其中幾臺(tái)服務(wù)器宕機(jī)，只要有一臺(tái)服務(wù)器可用服務(wù)就可用。

redis也是一樣，為了解決單機(jī)故障引入了主從模式，但主從模式存在一個(gè)問(wèn)題：master節(jié)點(diǎn)故障后服務(wù)，需要人為的手動(dòng)將slave節(jié)點(diǎn)切換成為maser節(jié)點(diǎn)后服務(wù)才恢復(fù)。redis為解決這一問(wèn)題又引入了哨兵模式，哨兵模式能在master節(jié)點(diǎn)故障后能自動(dòng)將salve節(jié)點(diǎn)提升成master節(jié)點(diǎn)，不需要人工干預(yù)操作就能恢復(fù)服務(wù)可用。但是主從模式、哨兵模式都沒(méi)有達(dá)到真正的數(shù)據(jù)sharding存儲(chǔ)，每個(gè)redis實(shí)例中存儲(chǔ)的都是全量數(shù)據(jù)，所以redis cluster就誕生了，實(shí)現(xiàn)了真正的數(shù)據(jù)分片存儲(chǔ)。但是由于redis cluster發(fā)布得比較晚（2015年才發(fā)布正式版 ），各大廠等不及了，陸陸續(xù)續(xù)開(kāi)發(fā)了自己的redis數(shù)據(jù)分片集群模式，比如：Twemproxy、Codis等。

1、主從模式

redis單節(jié)點(diǎn)雖然有通過(guò)RDB和AOF持久化機(jī)制能將數(shù)據(jù)持久化到硬盤(pán)上，但數(shù)據(jù)是存儲(chǔ)在一臺(tái)服務(wù)器上的，如果服務(wù)器出現(xiàn)硬盤(pán)故障等問(wèn)題，會(huì)導(dǎo)致數(shù)據(jù)不可用，而且讀寫(xiě)無(wú)法分離，讀寫(xiě)都在同一臺(tái)服務(wù)器上，請(qǐng)求量大時(shí)會(huì)出現(xiàn)I/O瓶頸。為了避免單點(diǎn)故障 和 讀寫(xiě)不分離，Redis 提供了復(fù)制（replication）功能實(shí)現(xiàn)master數(shù)據(jù)庫(kù)中的數(shù)據(jù)更新后，會(huì)自動(dòng)將更新的數(shù)據(jù)同步到其他slave數(shù)據(jù)庫(kù)上。

如上redis主從結(jié)構(gòu)特點(diǎn)：一個(gè)master可以有多個(gè)salve節(jié)點(diǎn)；salve節(jié)點(diǎn)可以有slave節(jié)點(diǎn)，從節(jié)點(diǎn)是級(jí)聯(lián)結(jié)構(gòu)。

主從模式優(yōu)缺點(diǎn)

優(yōu)點(diǎn)： 主從結(jié)構(gòu)具有讀寫(xiě)分離，提高效率、數(shù)據(jù)備份，提供多個(gè)副本等優(yōu)點(diǎn)。

不足： 最大的不足就是主從模式不具備自動(dòng)容錯(cuò)和恢復(fù)功能，主節(jié)點(diǎn)故障，集群則無(wú)法進(jìn)行工作，可用性比較低，從節(jié)點(diǎn)升主節(jié)點(diǎn)需要人工手動(dòng)干預(yù)。

普通的主從模式，當(dāng)主數(shù)據(jù)庫(kù)崩潰時(shí)，需要手動(dòng)切換從數(shù)據(jù)庫(kù)成為主數(shù)據(jù)庫(kù)：

在從數(shù)據(jù)庫(kù)中使用SLAVE NO ONE命令將從數(shù)據(jù)庫(kù)提升成主數(shù)據(jù)繼續(xù)服務(wù)。

啟動(dòng)之前崩潰的主數(shù)據(jù)庫(kù)，然后使用SLAVEOF命令將其設(shè)置成新的主數(shù)據(jù)庫(kù)的從數(shù)據(jù)庫(kù)，即可同步數(shù)據(jù)。

2、哨兵模式

第一種主從同步/復(fù)制的模式，當(dāng)主服務(wù)器宕機(jī)后，需要手動(dòng)把一臺(tái)從服務(wù)器切換為主服務(wù)器，這就需要人工干預(yù)，費(fèi)事費(fèi)力，還會(huì)造成一段時(shí)間內(nèi)服務(wù)不可用，這時(shí)候就需要哨兵模式登場(chǎng)了。哨兵模式是從Redis的2.6版本開(kāi)始提供的，但是當(dāng)時(shí)這個(gè)版本的模式是不穩(wěn)定的，直到Redis的2.8版本以后，這個(gè)哨兵模式才穩(wěn)定下來(lái)。哨兵模式核心還是主從復(fù)制，只不過(guò)在相對(duì)于主從模式在主節(jié)點(diǎn)宕機(jī)導(dǎo)致不可寫(xiě)的情況下，多了一個(gè)競(jìng)選機(jī)制：從所有的從節(jié)點(diǎn)競(jìng)選出新的主節(jié)點(diǎn)。競(jìng)選機(jī)制的實(shí)現(xiàn)，是依賴(lài)于在系統(tǒng)中啟動(dòng)一個(gè)sentinel進(jìn)程。

如上圖，哨兵本身也有單點(diǎn)故障的問(wèn)題，所以在一個(gè)一主多從的Redis系統(tǒng)中，可以使用多個(gè)哨兵進(jìn)行監(jiān)控，哨兵不僅會(huì)監(jiān)控主數(shù)據(jù)庫(kù)和從數(shù)據(jù)庫(kù)，哨兵之間也會(huì)相互監(jiān)控。每一個(gè)哨兵都是一個(gè)獨(dú)立的進(jìn)程，作為進(jìn)程，它會(huì)獨(dú)立運(yùn)行。

（1）哨兵模式的作用：

監(jiān)控所有服務(wù)器是否正常運(yùn)行：通過(guò)發(fā)送命令返回監(jiān)控服務(wù)器的運(yùn)行狀態(tài)，處理監(jiān)控主服務(wù)器、從服務(wù)器外，哨兵之間也相互監(jiān)控。故障切換：當(dāng)哨兵監(jiān)測(cè)到master宕機(jī)，會(huì)自動(dòng)將slave切換成master，然后通過(guò)發(fā)布訂閱模式通知其他的從服務(wù)器，修改配置文件，讓它們切換master。同時(shí)那臺(tái)有問(wèn)題的舊主也會(huì)變?yōu)樾轮鞯膹?，也就是說(shuō)當(dāng)舊的主即使恢復(fù)時(shí)，并不會(huì)恢復(fù)原來(lái)的主身份，而是作為新主的一個(gè)從。

（2）哨兵實(shí)現(xiàn)原理

哨兵在啟動(dòng)進(jìn)程時(shí)，會(huì)讀取配置文件的內(nèi)容，通過(guò)如下的配置找出需要監(jiān)控的主數(shù)據(jù)庫(kù)：

sentinel monitor master-name ip port quorum #master-name是主數(shù)據(jù)庫(kù)的名字 #ip和port 是當(dāng)前主數(shù)據(jù)庫(kù)地址和端口號(hào) #quorum表示在執(zhí)行故障切換操作前，需要多少哨兵節(jié)點(diǎn)同意。這里之所以只需要連接主節(jié)點(diǎn)，是因?yàn)橥ㄟ^(guò)主節(jié)點(diǎn)的info命令，獲取從節(jié)點(diǎn)信息，從而和從節(jié)點(diǎn)也建立連接，同時(shí)也能通過(guò)主節(jié)點(diǎn)的info信息知道新增從節(jié)點(diǎn)的信息。一個(gè)哨兵節(jié)點(diǎn)可以監(jiān)控多個(gè)主節(jié)點(diǎn)，但是并不提倡這么做，因?yàn)楫?dāng)哨兵節(jié)點(diǎn)崩潰時(shí)，同時(shí)有多個(gè)集群切換會(huì)發(fā)生故障。哨兵啟動(dòng)后，會(huì)與主數(shù)據(jù)庫(kù)建立兩條連接。

訂閱主數(shù)據(jù)庫(kù)_sentinel_:hello頻道以獲取同樣監(jiān)控該數(shù)據(jù)庫(kù)的哨兵節(jié)點(diǎn)信息

定期向主數(shù)據(jù)庫(kù)發(fā)送info命令，獲取主數(shù)據(jù)庫(kù)本身的信息。

跟主數(shù)據(jù)庫(kù)建立連接后會(huì)定時(shí)執(zhí)行以下三個(gè)操作：（1）每隔10s向master和 slave發(fā)送info命令。作用是獲取當(dāng)前數(shù)據(jù)庫(kù)信息，比如發(fā)現(xiàn)新增從節(jié)點(diǎn)時(shí)，會(huì)建立連接，并加入到監(jiān)控列表中，當(dāng)主從數(shù)據(jù)庫(kù)的角色發(fā)生變化進(jìn)行信息更新。（2）每隔2s向主數(shù)據(jù)里和從數(shù)據(jù)庫(kù)的_sentinel_:hello頻道發(fā)送自己的信息。作用是將自己的監(jiān)控?cái)?shù)據(jù)和哨兵分享。每個(gè)哨兵會(huì)訂閱數(shù)據(jù)庫(kù)的_sentinel:hello頻道，當(dāng)其他哨兵收到消息后，會(huì)判斷該哨兵是不是新的哨兵，如果是則將其加入哨兵列表，并建立連接。（3）每隔1s向所有主從節(jié)點(diǎn)和所有哨兵節(jié)點(diǎn)發(fā)送ping命令，作用是監(jiān)控節(jié)點(diǎn)是否存活。

（3）主觀下線(xiàn)和客觀下線(xiàn)

哨兵節(jié)點(diǎn)發(fā)送ping命令時(shí)，當(dāng)超過(guò)一定時(shí)間（down-after-millisecond）后，如果節(jié)點(diǎn)未回復(fù)，則哨兵認(rèn)為主觀下線(xiàn)。主觀下線(xiàn)表示當(dāng)前哨兵認(rèn)為該節(jié)點(diǎn)已經(jīng)下面，如果該節(jié)點(diǎn)為主數(shù)據(jù)庫(kù)，哨兵會(huì)進(jìn)一步判斷是夠需要對(duì)其進(jìn)行故障切換，這時(shí)候就要發(fā)送命令（SENTINEL is-master-down-by-addr）詢(xún)問(wèn)其他哨兵節(jié)點(diǎn)是否認(rèn)為該主節(jié)點(diǎn)是主觀下線(xiàn)，當(dāng)達(dá)到指定數(shù)量（quorum）時(shí)，哨兵就會(huì)認(rèn)為是客觀下線(xiàn)。當(dāng)主節(jié)點(diǎn)客觀下線(xiàn)時(shí)就需要進(jìn)行主從切換，主從切換的步驟為：

選出領(lǐng)頭哨兵。

領(lǐng)頭哨兵所有的slave選出優(yōu)先級(jí)最高的從數(shù)據(jù)庫(kù)。優(yōu)先級(jí)可以通過(guò)slave-priority選項(xiàng)設(shè)置。

如果優(yōu)先級(jí)相同，則從復(fù)制的命令偏移量越大（即復(fù)制同步數(shù)據(jù)越多，數(shù)據(jù)越新），越優(yōu)先。

如果以上條件都一樣，則選擇run ID較小的從數(shù)據(jù)庫(kù)。

選出一個(gè)從數(shù)據(jù)庫(kù)后，哨兵發(fā)送slave no one命令升級(jí)為主數(shù)據(jù)庫(kù)，并發(fā)送slaveof命令將其他從節(jié)點(diǎn)的主數(shù)據(jù)庫(kù)設(shè)置為新的主數(shù)據(jù)庫(kù)。

（4）哨兵模式優(yōu)缺點(diǎn)

1.優(yōu)點(diǎn)

哨兵模式是基于主從模式的，解決可主從模式中master故障不可以自動(dòng)切換故障的問(wèn)題。

2.不足-問(wèn)題

是一種中心化的集群實(shí)現(xiàn)方案：始終只有一個(gè)Redis主機(jī)來(lái)接收和處理寫(xiě)請(qǐng)求，寫(xiě)操作受單機(jī)瓶頸影響。

集群里所有節(jié)點(diǎn)保存的都是全量數(shù)據(jù)，浪費(fèi)內(nèi)存空間，沒(méi)有真正實(shí)現(xiàn)分布式存儲(chǔ)。數(shù)據(jù)量過(guò)大時(shí)，主從同步嚴(yán)重影響master的性能。

Redis主機(jī)宕機(jī)后，哨兵模式正在投票選舉的情況之外，因?yàn)橥镀边x舉結(jié)束之前，誰(shuí)也不知道主機(jī)和從機(jī)是誰(shuí)，此時(shí)Redis也會(huì)開(kāi)啟保護(hù)機(jī)制，禁止寫(xiě)操作，直到選舉出了新的Redis主機(jī)。

主從模式或哨兵模式每個(gè)節(jié)點(diǎn)存儲(chǔ)的數(shù)據(jù)都是全量的數(shù)據(jù)，數(shù)據(jù)量過(guò)大時(shí)，就需要對(duì)存儲(chǔ)的數(shù)據(jù)進(jìn)行分片后存儲(chǔ)到多個(gè)redis實(shí)例上。此時(shí)就要用到Redis Sharding技術(shù)。

3、各大廠的Redis集群方案

Redis在3.0版本前只支持單實(shí)例模式，雖然Redis的開(kāi)發(fā)者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才發(fā)布正式版。各大企業(yè)等不急了，在3.0版本還沒(méi)發(fā)布前為了解決Redis的存儲(chǔ)瓶頸，紛紛推出了各自的Redis集群方案。這些方案的核心思想是把數(shù)據(jù)分片（sharding）存儲(chǔ)在多個(gè)Redis實(shí)例中，每一片就是一個(gè)Redis實(shí)例。

（1）客戶(hù)端分片

客戶(hù)端分片是把分片的邏輯放在Redis客戶(hù)端實(shí)現(xiàn)，（比如：jedis已支持Redis Sharding功能，即ShardedJedis），通過(guò)Redis客戶(hù)端預(yù)先定義好的路由規(guī)則（使用一致性哈希），把對(duì)Key的訪問(wèn)轉(zhuǎn)發(fā)到不同的Redis實(shí)例中，查詢(xún)數(shù)據(jù)時(shí)把返回結(jié)果匯集。這種方案的模式如圖所示。

客戶(hù)端分片的優(yōu)缺點(diǎn)：優(yōu)點(diǎn)：客戶(hù)端sharding技術(shù)使用hash一致性算法分片的好處是所有的邏輯都是可控的，不依賴(lài)于第三方分布式中間件。服務(wù)端的Redis實(shí)例彼此獨(dú)立，相互無(wú)關(guān)聯(lián)，每個(gè)Redis實(shí)例像單服務(wù)器一樣運(yùn)行，非常容易線(xiàn)性擴(kuò)展，系統(tǒng)的靈活性很強(qiáng)。開(kāi)發(fā)人員清楚怎么實(shí)現(xiàn)分片、路由的規(guī)則，不用擔(dān)心踩坑。

1.一致性哈希算法：

是分布式系統(tǒng)中常用的算法。比如，一個(gè)分布式的存儲(chǔ)系統(tǒng)，要將數(shù)據(jù)存儲(chǔ)到具體的節(jié)點(diǎn)上，如果采用普通的hash方法，將數(shù)據(jù)映射到具體的節(jié)點(diǎn)上，如mod（key，d），key是數(shù)據(jù)的key，d是機(jī)器節(jié)點(diǎn)數(shù)，如果有一個(gè)機(jī)器加入或退出這個(gè)集群，則所有的數(shù)據(jù)映射都無(wú)效了。一致性哈希算法解決了普通余數(shù)Hash算法伸縮性差的問(wèn)題，可以保證在上線(xiàn)、下線(xiàn)服務(wù)器的情況下盡量有多的請(qǐng)求命中原來(lái)路由到的服務(wù)器。

2.實(shí)現(xiàn)方式：一致性hash算法，比如MURMUR_HASH散列算法、ketamahash算法

比如Jedis的Redis Sharding實(shí)現(xiàn)，采用一致性哈希算法（consistent hashing），將key和節(jié)點(diǎn)name同時(shí)hashing，然后進(jìn)行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用簡(jiǎn)單類(lèi)似哈希求模映射的主要原因是當(dāng)增加或減少節(jié)點(diǎn)時(shí)，不會(huì)產(chǎn)生由于重新匹配造成的rehashing。一致性哈希只影響相鄰節(jié)點(diǎn)key分配，影響量小。不足：

這是一種靜態(tài)的分片方案，需要增加或者減少Redis實(shí)例的數(shù)量，需要手工調(diào)整分片的程序。

運(yùn)維成本比較高，集群的數(shù)據(jù)出了任何問(wèn)題都需要運(yùn)維人員和開(kāi)發(fā)人員一起合作，減緩了解決問(wèn)題的速度，增加了跨部門(mén)溝通的成本。

在不同的客戶(hù)端程序中，維護(hù)相同的路由分片邏輯成本巨大。比如：java項(xiàng)目、PHP項(xiàng)目里共用一套R(shí)edis集群，路由分片邏輯分別需要寫(xiě)兩套一樣的邏輯，以后維護(hù)也是兩套。

客戶(hù)端分片有一個(gè)最大的問(wèn)題就是，服務(wù)端Redis實(shí)例群拓?fù)浣Y(jié)構(gòu)有變化時(shí)，每個(gè)客戶(hù)端都需要更新調(diào)整。如果能把客戶(hù)端分片模塊單獨(dú)拎出來(lái)，形成一個(gè)單獨(dú)的模塊（中間件），作為客戶(hù)端 和 服務(wù)端連接的橋梁就能解決這個(gè)問(wèn)題了，此時(shí)代理分片就出現(xiàn)了。

（2）代理分片

redis代理分片用得最多的就是Twemproxy，由Twitter開(kāi)源的Redis代理，其基本原理是：通過(guò)中間件的形式，Redis客戶(hù)端把請(qǐng)求發(fā)送到Twemproxy，Twemproxy根據(jù)路由規(guī)則發(fā)送到正確的Redis實(shí)例，最后Twemproxy把結(jié)果匯集返回給客戶(hù)端。Twemproxy通過(guò)引入一個(gè)代理層，將多個(gè)Redis實(shí)例進(jìn)行統(tǒng)一管理，使Redis客戶(hù)端只需要在Twemproxy上進(jìn)行操作，而不需要關(guān)心后面有多少個(gè)Redis實(shí)例，從而實(shí)現(xiàn)了Redis集群。

Twemproxy的優(yōu)點(diǎn)：

客戶(hù)端像連接Redis實(shí)例一樣連接Twemproxy，不需要改任何的代碼邏輯。

支持無(wú)效Redis實(shí)例的自動(dòng)刪除。

Twemproxy與Redis實(shí)例保持連接，減少了客戶(hù)端與Redis實(shí)例的連接數(shù)。

Twemproxy的不足：

由于Redis客戶(hù)端的每個(gè)請(qǐng)求都經(jīng)過(guò)Twemproxy代理才能到達(dá)Redis服務(wù)器，這個(gè)過(guò)程中會(huì)產(chǎn)生性能損失。

沒(méi)有友好的監(jiān)控管理后臺(tái)界面，不利于運(yùn)維監(jiān)控。

Twemproxy最大的痛點(diǎn)在于，無(wú)法平滑地?cái)U(kuò)容/縮容。對(duì)于運(yùn)維人員來(lái)說(shuō)，當(dāng)因?yàn)闃I(yè)務(wù)需要增加Redis實(shí)例時(shí)工作量非常大。

Twemproxy作為最被廣泛使用、最久經(jīng)考驗(yàn)、穩(wěn)定性最高的Redis代理，在業(yè)界被廣泛使用。

（3）Codis

Twemproxy不能平滑增加Redis實(shí)例的問(wèn)題帶來(lái)了很大的不便，于是豌豆莢自主研發(fā)了Codis，一個(gè)支持平滑增加Redis實(shí)例的Redis代理軟件，其基于Go和C語(yǔ)言開(kāi)發(fā)，并于2014年11月在GitHub上開(kāi)源。

在Codis的架構(gòu)圖中，Codis引入了Redis Server Group，其通過(guò)指定一個(gè)主CodisRedis和一個(gè)或多個(gè)從CodisRedis，實(shí)現(xiàn)了Redis集群的高可用。當(dāng)一個(gè)主CodisRedis掛掉時(shí)，Codis不會(huì)自動(dòng)把一個(gè)從CodisRedis提升為主CodisRedis，這涉及數(shù)據(jù)的一致性問(wèn)題（Redis本身的數(shù)據(jù)同步是采用主從異步復(fù)制，當(dāng)數(shù)據(jù)在主CodisRedis寫(xiě)入成功時(shí)，從CodisRedis是否已讀入這個(gè)數(shù)據(jù)是沒(méi)法保證的），需要管理員在管理界面上手動(dòng)把從CodisRedis提升為主CodisRedis。如果手動(dòng)處理覺(jué)得麻煩，豌豆莢也提供了一個(gè)工具Codis-ha，這個(gè)工具會(huì)在檢測(cè)到主CodisRedis掛掉的時(shí)候?qū)⑵湎戮€(xiàn)并提升一個(gè)從CodisRedis為主CodisRedis。Codis中采用預(yù)分片的形式，啟動(dòng)的時(shí)候就創(chuàng)建了1024個(gè)slot，1個(gè)slot相當(dāng)于1個(gè)箱子，每個(gè)箱子有固定的編號(hào)，范圍是1~1024。slot這個(gè)箱子用作存放Key，至于Key存放到哪個(gè)箱子，可以通過(guò)算法“crc32（key）%1024”獲得一個(gè)數(shù)字，這個(gè)數(shù)字的范圍一定是1~1024之間，Key就放到這個(gè)數(shù)字對(duì)應(yīng)的slot。例如，如果某個(gè)Key通過(guò)算法“crc32（key）%1024”得到的數(shù)字是5，就放到編碼為5的slot（箱子）。1個(gè)slot只能放1個(gè)Redis Server Group，不能把1個(gè)slot放到多個(gè)Redis Server Group中。1個(gè)Redis Server Group最少可以存放1個(gè)slot，最大可以存放1024個(gè)slot。因此，Codis中最多可以指定1024個(gè)Redis Server Group。Codis最大的優(yōu)勢(shì)在于支持平滑增加（減少）Redis Server Group（Redis實(shí)例），能安全、透明地遷移數(shù)據(jù)，這也是Codis 有別于Twemproxy等靜態(tài)分布式 Redis 解決方案的地方。Codis增加了Redis Server Group后，就牽涉到slot的遷移問(wèn)題。例如，系統(tǒng)有兩個(gè)Redis Server Group，Redis Server Group和slot的對(duì)應(yīng)關(guān)系如下。

當(dāng)增加了一個(gè)Redis Server Group，slot就要重新分配了。Codis分配slot有兩種方法：第一種：通過(guò)Codis管理工具Codisconfig手動(dòng)重新分配，指定每個(gè)Redis Server Group所對(duì)應(yīng)的slot的范圍，例如：可以指定Redis Server Group和slot的新的對(duì)應(yīng)關(guān)系如下。

第二種：通過(guò)Codis管理工具Codisconfig的rebalance功能，會(huì)自動(dòng)根據(jù)每個(gè)Redis Server Group的內(nèi)存對(duì)slot進(jìn)行遷移，以實(shí)現(xiàn)數(shù)據(jù)的均衡。

4、Redis Cluster

Redis 的哨兵模式雖然已經(jīng)可以實(shí)現(xiàn)高可用，讀寫(xiě)分離 ，但是存在幾個(gè)方面的不足：

哨兵模式下每臺(tái) Redis 服務(wù)器都存儲(chǔ)相同的數(shù)據(jù)，很浪費(fèi)內(nèi)存空間；數(shù)據(jù)量太大，主從同步時(shí)嚴(yán)重影響了master性能。

哨兵模式是中心化的集群實(shí)現(xiàn)方案，每個(gè)從機(jī)和主機(jī)的耦合度很高，master宕機(jī)到salve選舉master恢復(fù)期間服務(wù)不可用。

哨兵模式始終只有一個(gè)Redis主機(jī)來(lái)接收和處理寫(xiě)請(qǐng)求，寫(xiě)操作還是受單機(jī)瓶頸影響，沒(méi)有實(shí)現(xiàn)真正的分布式架構(gòu)。

redis在3.0上加入了 Cluster 集群模式，實(shí)現(xiàn)了 Redis 的分布式存儲(chǔ)，也就是說(shuō)每臺(tái) Redis 節(jié)點(diǎn)上存儲(chǔ)不同的數(shù)據(jù)。cluster模式為了解決單機(jī)Redis容量有限的問(wèn)題，將數(shù)據(jù)按一定的規(guī)則分配到多臺(tái)機(jī)器，內(nèi)存/QPS不受限于單機(jī)，可受益于分布式集群高擴(kuò)展性。Redis Cluster是一種服務(wù)器Sharding技術(shù)（分片和路由都是在服務(wù)端實(shí)現(xiàn)），采用多主多從，每一個(gè)分區(qū)都是由一個(gè)Redis主機(jī)和多個(gè)從機(jī)組成，片區(qū)和片區(qū)之間是相互平行的。Redis Cluster集群采用了P2P的模式，完全去中心化。

如上圖，官方推薦，集群部署至少要 3 臺(tái)以上的master節(jié)點(diǎn)，最好使用 3 主 3 從六個(gè)節(jié)點(diǎn)的模式。Redis Cluster集群具有如下幾個(gè)特點(diǎn)：

集群完全去中心化，采用多主多從；所有的redis節(jié)點(diǎn)彼此互聯(lián)（PING-PONG機(jī)制），內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬。

客戶(hù)端與 Redis 節(jié)點(diǎn)直連，不需要中間代理層?？蛻?hù)端不需要連接集群所有節(jié)點(diǎn)，連接集群中任何一個(gè)可用節(jié)點(diǎn)即可。

每一個(gè)分區(qū)都是由一個(gè)Redis主機(jī)和多個(gè)從機(jī)組成，分片和分片之間是相互平行的。

每一個(gè)master節(jié)點(diǎn)負(fù)責(zé)維護(hù)一部分槽，以及槽所映射的鍵值數(shù)據(jù)；集群中每個(gè)節(jié)點(diǎn)都有全量的槽信息，通過(guò)槽每個(gè)node都知道具體數(shù)據(jù)存儲(chǔ)到哪個(gè)node上。

redis cluster主要是針對(duì)海量數(shù)據(jù)+高并發(fā)+高可用的場(chǎng)景，海量數(shù)據(jù)，如果你的數(shù)據(jù)量很大，那么建議就用redis cluster，數(shù)據(jù)量不是很大時(shí)，使用sentinel就夠了。redis cluster的性能和高可用性均優(yōu)于哨兵模式。Redis Cluster采用虛擬哈希槽分區(qū)而非一致性hash算法，預(yù)先分配一些卡槽，所有的鍵根據(jù)哈希函數(shù)映射到這些槽內(nèi)，每一個(gè)分區(qū)內(nèi)的master節(jié)點(diǎn)負(fù)責(zé)維護(hù)一部分槽以及槽所映射的鍵值數(shù)據(jù)。