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

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

1、主從模式

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

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

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

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

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

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

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

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

2、哨兵模式

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

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

（1）哨兵模式的作用：

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

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

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

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

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

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

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

（3）主觀下線和客觀下線

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

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

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

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

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

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

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

1.優(yōu)點

哨兵模式是基于主從模式的，解決可主從模式中master故障不可以自動切換故障的問題。

2.不足-問題

是一種中心化的集群實現(xiàn)方案：始終只有一個Redis主機來接收和處理寫請求，寫操作受單機瓶頸影響。

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

Redis主機宕機后，哨兵模式正在投票選舉的情況之外，因為投票選舉結(jié)束之前，誰也不知道主機和從機是誰，此時Redis也會開啟保護機制，禁止寫操作，直到選舉出了新的Redis主機。

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

3、各大廠的Redis集群方案

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

（1）客戶端分片

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

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

1.一致性哈希算法：

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

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

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

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

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

在不同的客戶端程序中，維護相同的路由分片邏輯成本巨大。比如：java項目、PHP項目里共用一套Redis集群，路由分片邏輯分別需要寫兩套一樣的邏輯，以后維護也是兩套。

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

（2）代理分片

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

Twemproxy的優(yōu)點：

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

支持無效Redis實例的自動刪除。

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

Twemproxy的不足：

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

沒有友好的監(jiān)控管理后臺界面，不利于運維監(jiān)控。

Twemproxy最大的痛點在于，無法平滑地擴容/縮容。對于運維人員來說，當(dāng)因為業(yè)務(wù)需要增加Redis實例時工作量非常大。

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

（3）Codis

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

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

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

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

4、Redis Cluster

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

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

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

哨兵模式始終只有一個Redis主機來接收和處理寫請求，寫操作還是受單機瓶頸影響，沒有實現(xiàn)真正的分布式架構(gòu)。

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

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

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

客戶端與 Redis 節(jié)點直連，不需要中間代理層。客戶端不需要連接集群所有節(jié)點，連接集群中任何一個可用節(jié)點即可。

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

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

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