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

redis也是一樣，為了解決單機故障引入了主從模式，但主從模式存在一個問題：master節(jié)點故障后服務(wù)，需要人為的手動將slave節(jié)點切換成為maser節(jié)點后服務(wù)才恢復。redis為解決這一問題又引入了哨兵模式，哨兵模式能在master節(jié)點故障后能自動將salve節(jié)點提升成master節(jié)點，不需要人工干預操作就能恢復服務(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等。

主從模式

redis單節(jié)點雖然有通過RDB和AOF持久化機制能將數(shù)據(jù)持久化到硬盤上，但數(shù)據(jù)是存儲在一臺服務(wù)器上的，如果服務(wù)器出現(xiàn)硬盤故障等問題，會導致數(shù)據(jù)不可用，而且讀寫無法分離，讀寫都在同一臺服務(wù)器上，請求量大時會出現(xiàn)I/O瓶頸。

為了避免單點故障 和 讀寫不分離，Redis 提供了復制（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)點。
• 不足: 最大的不足就是主從模式不具備自動容錯和恢復功能，主節(jié)點故障，集群則無法進行工作，可用性比較低，從節(jié)點升主節(jié)點需要人工手動干預。

普通的主從模式，當主數(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ù)。

哨兵模式

第一種主從同步/復制的模式，當主服務(wù)器宕機后，需要手動把一臺從服務(wù)器切換為主服務(wù)器，這就需要人工干預，費事費力，還會造成一段時間內(nèi)服務(wù)不可用，這時候就需要哨兵模式登場了。

哨兵模式是從Redis的2.6版本開始提供的，但是當時這個版本的模式是不穩(wěn)定的，直到Redis的2.8版本以后，這個哨兵模式才穩(wěn)定下來。

哨兵模式核心還是主從復制，只不過在相對于主從模式在主節(jié)點宕機導致不可寫的情況下，多了一個競選機制：從所有的從節(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)控。

故障切換：當哨兵監(jiān)測到master宕機，會自動將slave切換成master，然后通過發(fā)布訂閱模式通知其他的從服務(wù)器，修改配置文件，讓它們切換master。同時那臺有問題的舊主也會變?yōu)樾轮鞯膹?，也就是說當舊的主即使恢復時，并不會恢復原來的主身份，而是作為新主的一個從。

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

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

sentinel monitor master-name ip port quorum
#master-name是主數(shù)據(jù)庫的名字
#ip和port 是當前主數(shù)據(jù)庫地址和端口號
#quorum表示在執(zhí)行故障切換操作前，需要多少哨兵節(jié)點同意。

這里之所以只需要連接主節(jié)點，是因為通過主節(jié)點的info命令，獲取從節(jié)點信息，從而和從節(jié)點也建立連接，同時也能通過主節(jié)點的info信息知道新增從節(jié)點的信息。

一個哨兵節(jié)點可以監(jiān)控多個主節(jié)點，但是并不提倡這么做，因為當哨兵節(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命令。作用是獲取當前數(shù)據(jù)庫信息，比如發(fā)現(xiàn)新增從節(jié)點時，會建立連接，并加入到監(jiān)控列表中，當主從數(shù)據(jù)庫的角色發(fā)生變化進行信息更新。
• （2）每隔2s向主數(shù)據(jù)里和從數(shù)據(jù)庫的_sentinel_:hello頻道發(fā)送自己的信息。作用是將自己的監(jiān)控數(shù)據(jù)和哨兵分享。每個哨兵會訂閱數(shù)據(jù)庫的_sentinel:hello頻道，當其他哨兵收到消息后，會判斷該哨兵是不是新的哨兵，如果是則將其加入哨兵列表，并建立連接。
• （3）每隔1s向所有主從節(jié)點和所有哨兵節(jié)點發(fā)送ping命令，作用是監(jiān)控節(jié)點是否存活。

(3)主觀下線和客觀下線

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

當主節(jié)點客觀下線時就需要進行主從切換，主從切換的步驟為：

• 選出領(lǐng)頭哨兵。
• 領(lǐng)頭哨兵所有的slave選出優(yōu)先級最高的從數(shù)據(jù)庫。優(yōu)先級可以通過slave-priority選項設(shè)置。
• 如果優(yōu)先級相同，則從數(shù)據(jù)庫復制的命令偏移量越大（即復制同步數(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ù)量過大時，主從同步嚴重影響master的性能。
• Redis主機宕機后，哨兵模式正在投票選舉的情況之外，因為投票選舉結(jié)束之前，誰也不知道主機和從機是誰，此時Redis也會開啟保護機制，禁止寫操作，直到選舉出了新的Redis主機。

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

各大廠的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客戶端預先定義好的路由規(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ī)則，不用擔心踩坑。

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。

采用一致性哈希而不是采用簡單類似哈希求模映射的主要原因是當增加或減少節(jié)點時，不會產(chǎn)生由于重新匹配造成的rehashing。一致性哈希只影響相鄰節(jié)點key分配，影響量小。

不足：

• 這是一種靜態(tài)的分片方案，需要增加或者減少Redis實例的數(shù)量，需要手工調(diào)整分片的程序。
• 運維成本比較高，集群的數(shù)據(jù)出了任何問題都需要運維人員和開發(fā)人員一起合作，減緩了解決問題的速度，增加了跨部門溝通的成本。
• 在不同的客戶端程序中，維護相同的路由分片邏輯成本巨大。比如：java項目、PHP項目里共用一套Redis集群，路由分片邏輯分別需要寫兩套一樣的邏輯，以后維護也是兩套。

客戶端分片有一個最大的問題就是，服務(wù)端Redis實例群拓撲結(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最大的痛點在于，無法平滑地擴容/縮容。對于運維人員來說，當因為業(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集群的高可用。當一個主CodisRedis掛掉時，Codis不會自動把一個從CodisRedis提升為主CodisRedis，這涉及數(shù)據(jù)的一致性問題（Redis本身的數(shù)據(jù)同步是采用主從異步復制，當數(shù)據(jù)在主CodisRedis寫入成功時，從CodisRedis是否已讀入這個數(shù)據(jù)是沒法保證的），需要管理員在管理界面上手動把從CodisRedis提升為主CodisRedis。

如果手動處理覺得麻煩，豌豆莢也提供了一個工具Codis-ha，這個工具會在檢測到主CodisRedis掛掉的時候?qū)⑵湎戮€并提升一個從CodisRedis為主CodisRedis。

Codis中采用預分片的形式，啟動的時候就創(chuàng)建了1024個slot，1個slot相當于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)系如下。

圖片

當增加了一個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ù)的均衡。

Redis Cluster

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

• 哨兵模式下每臺 Redis 服務(wù)器都存儲相同的數(shù)據(jù)，很浪費內(nèi)存空間；數(shù)據(jù)量太大，主從同步時嚴重影響了master性能。
• 哨兵模式是中心化的集群實現(xiàn)方案，每個從機和主機的耦合度很高，master宕機到salve選舉master恢復期間服務(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é)點直連，不需要中間代理層?？蛻舳瞬恍枰B接集群所有節(jié)點，連接集群中任何一個可用節(jié)點即可。
• 每一個分區(qū)都是由一個Redis主機和多個從機組成，分片和分片之間是相互平行的。
• 每一個master節(jié)點負責維護一部分槽，以及槽所映射的鍵值數(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算法，預先分配一些卡槽，所有的鍵根據(jù)哈希函數(shù)映射到這些槽內(nèi)，每一個分區(qū)內(nèi)的master節(jié)點負責維護一部分槽以及槽所映射的鍵值數(shù)據(jù)。