調(diào)研比較了三個Redis集群的解決方案：

系統(tǒng)	貢獻(xiàn)者	是否官方Redis實(shí)現(xiàn)	編程語言
Twemproxy	Twitter	是	C
Redis Cluster	Redis官方	是	C
Codis	豌豆莢	否	Go+C

1.基本架構(gòu)
1.1 Twemproxy

• 增加Proxy層，由Proxy實(shí)現(xiàn)一致性哈希算法（支持：KETAMA/取模/隨機(jī)）

數(shù)據(jù)分片算法：
采用一致性哈希算法，以KETAMA為例：


1.2 Redis Cluster

• 無中心自組織的結(jié)構(gòu)

• 各節(jié)點(diǎn)維護(hù)Key->Server的映射關(guān)系

• Client可以向任意節(jié)點(diǎn)發(fā)起請求，節(jié)點(diǎn)不會轉(zhuǎn)發(fā)請求，只是重定向Client

• 如果在Client第一次請求和重定向請求之間，Cluster拓?fù)浒l(fā)生改變，則第二次重定向請求將被再次重定向，直到找到正確的Server為止

數(shù)據(jù)分片算法：
Key空間被劃分為16384個區(qū)間,每個Master節(jié)點(diǎn)負(fù)責(zé)一部分區(qū)間。

1.3 Codis

• 客戶端可以連接到任意的codis-proxy,就和連接原生的Redis Server

• 由Zookeeper維護(hù)數(shù)據(jù)路由表和 codis-proxy 節(jié)點(diǎn)的元信息

數(shù)據(jù)分片算法：

• Key空間被劃分為1024個區(qū)間, 對于每個key來說, 通過以下公式確定所屬的 Slot Id : SlotId = crc32(key) % 1024

• 每一個 slot 都會有一個特定的 server group id 來表示這個 slot 的數(shù)據(jù)由哪個 server group 來提供

2.水平擴(kuò)容
Twemproxy:

• 不支持運(yùn)行時水平擴(kuò)容，需要重啟。

• 根據(jù)一致性哈希算法進(jìn)行數(shù)據(jù)重新分片。

Redis Cluster:

• 支持通過運(yùn)行時增加Master節(jié)點(diǎn)來水平擴(kuò)容，提升存儲容量，盡力降低命中率波動

• 存在節(jié)點(diǎn)A，需要遷出其中的部分Key區(qū)間。新增節(jié)點(diǎn)B，接收由節(jié)點(diǎn)A遷出的Key區(qū)間。

• 相應(yīng)Key區(qū)間的請求首先還是會發(fā)送給A節(jié)點(diǎn)：如果請求為新建Key則直接重定向到B節(jié)點(diǎn)；如果請求不是新建Key且A節(jié)點(diǎn)存儲有對應(yīng)的Key則直接作出響應(yīng)，否則重定向到B節(jié)點(diǎn)

• 同時Cluster會調(diào)用實(shí)用工具redis-trib向A節(jié)點(diǎn)發(fā)送MIGRATE命令，把遷移區(qū)間內(nèi)的所有Key原子的遷移到B節(jié)點(diǎn)：同時鎖住A、B節(jié)點(diǎn)=》在A節(jié)點(diǎn)刪除Key=》在B節(jié)點(diǎn)新建Key=》解鎖

• 運(yùn)行時動態(tài)遷移大尺寸鍵值可能造成響應(yīng)時延

Codis:

• 支持運(yùn)行時水平擴(kuò)容

• 底層基于Codis Server特殊實(shí)現(xiàn)原子的數(shù)據(jù)遷移指令

3.主從備份
3.1 主從備份是否必須
Twemproxy:

• 沒有數(shù)據(jù)復(fù)制不影響可用節(jié)點(diǎn)頂替故障節(jié)點(diǎn)

• 故障發(fā)生時，沒有數(shù)據(jù)復(fù)制的故障節(jié)點(diǎn)的Key會全部丟失

Redis Cluster:
沒有主從備份的節(jié)點(diǎn)一旦故障，將導(dǎo)致整個集群失敗：無法寫入/讀取任何Key；無法進(jìn)行數(shù)據(jù)重新分片。

Codis:

• 若出現(xiàn)故障，需要手動配置節(jié)點(diǎn)，進(jìn)行故障轉(zhuǎn)移。

• 如果沒有進(jìn)行故障轉(zhuǎn)移，只故障節(jié)點(diǎn)負(fù)責(zé)的slots 會失敗

3.2 主從備份方案
Twemproxy本身不支持出從備份，和Redis Cluster一樣，需要引入Redis本身的主備復(fù)制功能。

• 可以設(shè)置1主1備或者1主多備

• 當(dāng)Slave節(jié)點(diǎn)接入Cluster時，就會向配置的Master節(jié)點(diǎn)發(fā)送SYNC命令。斷開重連時，也會再次發(fā)送SYNC命令

• 此后Master將啟動后臺存盤進(jìn)程，同時收集所有接收到的用于修改數(shù)據(jù)集的命令，在后臺進(jìn)程執(zhí)行完畢后，Master將傳送整個數(shù)據(jù) 庫文件到Slave，以完成一次完全同步。而Slave服務(wù)器在接收到數(shù)據(jù)庫文件數(shù)據(jù)之后將其存盤并加載到內(nèi)存中。此后，Master繼續(xù)將所有已經(jīng)收集 到的修改命令，和新的修改命令依次傳送給Slaves，Slave將在本次執(zhí)行這些數(shù)據(jù)修改命令，從而達(dá)到最終的數(shù)據(jù)同步。

• Redis的數(shù)據(jù)復(fù)制是異步的，無論在Master端還是Slave端都不會阻塞。

• Slave會周期性確認(rèn)收到的備份數(shù)據(jù)

Twemproxy引入主備復(fù)制后的架構(gòu)更新為：


開啟主備復(fù)制后的Redis Cluster的架構(gòu)更新為下圖，Client可以向任意節(jié)點(diǎn)發(fā)起請求，無論是Master節(jié)點(diǎn)還是Slave節(jié)點(diǎn)。



4.故障檢測與轉(zhuǎn)移
4.1 Twemproxy
4.1.1 故障檢測
Twemproxy本身通過三個配置項實(shí)現(xiàn)：

Txt代碼 ?

auto_eject_hosts:?true??

timeout:?400??

server_failure_limit:?3??

如果Server Pool開啟了auto_eject_hosts，則當(dāng)連續(xù)server_failure_limit次訪問某Server，都超時timeout無響應(yīng)，則標(biāo)記該節(jié)點(diǎn)為故障。

4.1.2 故障轉(zhuǎn)移
故障節(jié)點(diǎn)將從Hash環(huán)上直接取下，之前保存在該Server上的Key將丟失。

4.1.3 故障轉(zhuǎn)移耗時評估
假設(shè)配置：timeout=400ms, server_failure_limit=2， 則故障轉(zhuǎn)移需要耗時800ms。


4.2 Twemproxy借助其他工具
使用Twemproxy時可以引入Redis Sentinel來進(jìn)行故障檢測。引入Redis Sentinel后Twemproxy的架構(gòu)更新為：

• 每個Sentinel節(jié)點(diǎn)可以監(jiān)控一個或多個Master節(jié)點(diǎn)，及其所有Slave節(jié)點(diǎn)

4.2.1 啟動Redis Sentinel

• redis-sentinel /path/to/sentinel.conf，其中的配置文件是必須的，配置文件將會被用來存儲運(yùn)行時狀態(tài)信息。在配置文件中只需要指明要監(jiān)視的Master節(jié)點(diǎn)列表。

• 無須為運(yùn)行的每個 Sentinel 分別設(shè)監(jiān)聽同一Master的其他 Sentinel 的地址， 因?yàn)?Sentinel 可以通過發(fā)布與訂閱功能來自動發(fā)現(xiàn)正在監(jiān)視相同主服務(wù)器的其他 Sentinel

• 不必手動列出主服務(wù)器屬下的所有從服務(wù)器， 因?yàn)?Sentinel 可以通過詢問主服務(wù)器來獲得所有從服務(wù)器的信息。

4.2.2 故障檢測

• 每個 Sentinel 以每秒鐘一次的頻率向它所知的主服務(wù)器、從服務(wù)器以及其他 Sentinel 實(shí)例發(fā)送一個 PING 命令。

• 如果一個實(shí)例（instance）距離最后一次有效回復(fù) PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 那么這個實(shí)例會被 Sentinel 標(biāo)記為主觀下線。

• 如果一個Master被標(biāo)記為主觀下線， 那么正在監(jiān)視這個Master的所有 Sentinel 要以每秒一次的頻率確認(rèn)主服務(wù)器的確進(jìn)入了主觀下線狀態(tài)。

• 如果一個主服務(wù)器被標(biāo)記為主觀下線， 并且有足夠數(shù)量的 Sentinel （至少要達(dá)到配置文件指定的數(shù)量）在指定的時間范圍內(nèi)同意這一判斷， 那么這個主服務(wù)器被標(biāo)記為客觀下線。

• 當(dāng)沒有足夠數(shù)量的 Sentinel 同意主服務(wù)器已經(jīng)下線， 主服務(wù)器的客觀下線狀態(tài)就會被移除。 當(dāng)主服務(wù)器重新向 Sentinel 的 PING 命令返回有效回復(fù)時， 主服務(wù)器的主觀下線狀態(tài)就會被移除。

4.2.3 故障轉(zhuǎn)移
Redis Sentinel進(jìn)行故障轉(zhuǎn)移的過程：

• 某Sentinel節(jié)點(diǎn)發(fā)現(xiàn)主服務(wù)器已經(jīng)進(jìn)入客觀下線狀態(tài)。

• 該Sentinel發(fā)起選舉，試圖當(dāng)選故障轉(zhuǎn)移主持節(jié)點(diǎn)

• 如果當(dāng)選失敗， 那么在設(shè)定的故障遷移超時時間的兩倍之后， 重新嘗試當(dāng)選。 如果當(dāng)選成功， 那么執(zhí)行以下步驟。

• 選出一個Slave節(jié)點(diǎn)，并將它升級為Master節(jié)點(diǎn)

• 向被選中的從服務(wù)器發(fā)送 SLAVEOF NO ONE 命令，讓它轉(zhuǎn)變?yōu)镸aster節(jié)點(diǎn)

• 通過發(fā)布與訂閱功能， 將更新后的配置傳播給所有其他 Sentinel ， 其他 Sentinel 對它們自己的配置進(jìn)行更新。

• 向已下線主服務(wù)器的Slave節(jié)點(diǎn)發(fā)送 SLAVEOF 命令， 讓它們?nèi)?fù)制新的Master節(jié)點(diǎn)

Redis Sentinel選擇新的Master節(jié)點(diǎn)進(jìn)行故障轉(zhuǎn)移之后，Twemproxy無法找到新的Master節(jié)點(diǎn)，此時需要引入第四方工具redis-twemproxy-agent（node.js），更新Twemproxy配置，并重啟。


4.2.4 故障轉(zhuǎn)移耗時評估

• 每個 Sentinel 以每秒鐘發(fā)送一次PING，配置down-after-milliseconds=2s，則主觀下線耗時3s

• 由主觀下線升：數(shù)量的 Sentinel （至少要達(dá)到配置文件指定的數(shù)量）在指定的時間范圍內(nèi)同意這一判斷1s

• Sentinel當(dāng)選故障轉(zhuǎn)移主持節(jié)點(diǎn)：1s

• 選出一個Slave節(jié)點(diǎn)，并將它升級為Master節(jié)點(diǎn),向被選中的從服務(wù)器發(fā)送 SLAVEOF NO ONE 命令，讓它轉(zhuǎn)變?yōu)镸aster節(jié)點(diǎn):0.5s

• 通過發(fā)布與訂閱功能， 將更新后的配置傳播給所有其他 Sentinel ， 其他 Sentinel 對它們自己的配置進(jìn)行更新:1s

• 總計耗時：6.5s

4.3 Redis Cluster
4.3.1 故障檢測
節(jié)點(diǎn)狀態(tài)的維護(hù)：

• 節(jié)點(diǎn)的拓?fù)浣Y(jié)構(gòu)是一張完全圖：對于N個節(jié)點(diǎn)的Cluster，每個節(jié)點(diǎn)都持有N-1個輸入TCP連接和N-1個輸出TCP連接。

• 節(jié)點(diǎn)信息的維護(hù)：每秒隨機(jī)選擇節(jié)點(diǎn)發(fā)送PING包（無論Cluster規(guī)模，PING包規(guī)模是常量）；每個節(jié)點(diǎn)保證在NODE_TIMEOUT/2 時間內(nèi)，對于每個節(jié)點(diǎn)都至少發(fā)送一個PING包或者收到一個PONG包.

在節(jié)點(diǎn)間相互交換的PING/PONG包中有兩個字段用來發(fā)現(xiàn)故障節(jié)點(diǎn)：PFAIL（Possible Fail）和FAIL。

PFAIL狀態(tài)：

• 當(dāng)一個節(jié)點(diǎn)發(fā)現(xiàn)某一節(jié)點(diǎn)在長達(dá)NODE_TIMEOUT的時間內(nèi)都無法訪問時，將其標(biāo)記為PFAIL狀態(tài)。

• 任意節(jié)點(diǎn)都可以將其他節(jié)點(diǎn)標(biāo)記為PFAIL狀態(tài)，無論它是Master節(jié)點(diǎn)還是Slave節(jié)點(diǎn)。

FAIL狀態(tài)：
當(dāng)一個節(jié)點(diǎn)發(fā)現(xiàn)另一節(jié)點(diǎn)被自己標(biāo)記為PFAIL狀態(tài)，并且在(NODE_TIMEOUT * FAIL_REPORT_VALIDITY_MULT)的時間范圍內(nèi)，與其他節(jié)點(diǎn)交換的PING/PONG包中，大部分Master節(jié)點(diǎn)都把該節(jié)點(diǎn)標(biāo)記為 PFAIL或者FAIL狀態(tài)，則把該節(jié)點(diǎn)標(biāo)記為FAIL狀態(tài)，并且進(jìn)行廣播。

4.3.2 故障轉(zhuǎn)移
4.3.2.1 Slave選舉的時機(jī)
當(dāng)某一Slave節(jié)點(diǎn)發(fā)現(xiàn)它的Master節(jié)點(diǎn)處于FAIL狀態(tài)時，可以發(fā)起一次Slave選舉，試圖將自己晉升為Master。一個Master節(jié)點(diǎn)的所有Slave節(jié)點(diǎn)都可以發(fā)起選舉，但最終只有一個Slave節(jié)點(diǎn)會贏得選舉。Slave發(fā)起選舉的條件：

• Slave的Master處于FAIL狀態(tài)

• 該MASTER節(jié)點(diǎn)存儲的Key數(shù)量>0

• Slave與Master節(jié)點(diǎn)失去連接的時間小于閥值，以保證參與選舉的Slave節(jié)點(diǎn)的數(shù)據(jù)的新鮮度

4.3.2.2 Cluster邏輯時鐘
Config epoch：
每個Master節(jié)點(diǎn)啟動時都會為自己創(chuàng)建并維護(hù)configEpoch字段，設(shè)置初始值為0。Master會在自己的PING/PONG包中廣 播自己的configEpoch字段。Redis Cluster盡力保持各個Master節(jié)點(diǎn)的configEpoch字段取值都不同。算法：

• 每當(dāng)一個Master節(jié)點(diǎn)發(fā)現(xiàn)有別的Master節(jié)點(diǎn)的configEpoch字段與自己相同時

• 并且自己的Node ID比對方小（字母順序）

• 則把自己的currentEpoch+1

Slave的PING/PONG包中也包含configEpoch字段，Slave的configEpoch字段取值是它的Master的configEpoch字段取值，由最后一次與Master交換PING/PONG包時取得。

Cluster epoch：
每一個節(jié)點(diǎn)啟動的時候都會創(chuàng)建currentEpoch字段，無論是Master節(jié)點(diǎn)還是Slave節(jié)點(diǎn)，并設(shè)置初始值為0。每當(dāng)一個節(jié)點(diǎn)收到來 自其他節(jié)點(diǎn)的PING/PONG包時，若其他節(jié)點(diǎn)的currentEpoch字段大于當(dāng)前節(jié)點(diǎn)的currentEpoch字段，則當(dāng)前節(jié)點(diǎn)把自己的 currentEpoch字段設(shè)置為該新觀察到的currentEpoch值。

4.3.2.3 Slave選舉的過程

• Slave節(jié)點(diǎn)遞增自己的currentEpoch字段

• 發(fā)送FAILOVER_AUTH_REQUEST數(shù)據(jù)包給每一個MASTER節(jié)點(diǎn)

• 若MASTER節(jié)點(diǎn)投票晉升該SLAVE節(jié)點(diǎn)，則回復(fù)FAILOVER_AUTH_ACK。某個MASTER節(jié)點(diǎn)投過票之后，在NODE_TIMEOUT * 2時間內(nèi)不能再給同一MASTER的SLAVE選舉投票。

• 若Slave在MAX((2*NODE_TIMEOUT),2)的時間內(nèi)獲得大多數(shù)MASTER節(jié)點(diǎn)的投票，則贏得選舉

• 其間，所有currentEpoch小于選舉發(fā)起時取值的MASTER投票都會被丟棄

• 若沒有任何Slave贏得選舉，選舉可以在MAX(NODE_TIMEOUT * 4,4)的時間后重新舉行

4.3.2.4 Master節(jié)點(diǎn)投票邏輯

• 請求選舉的Slave的Master必須處于FAIL狀態(tài)

• Master節(jié)點(diǎn)維護(hù)lastVoteEpoch字段，每當(dāng)MASTER給某個選舉請求投票時，更新lastVoteEpoch字段為請求的currentEpoch值

• currentEpoch<lastVoteEpoch的選舉請求都不予投票

• currentEpoch<MASTER currentEpoch字段的選舉請求都不予投票

4.2.3.5 選舉優(yōu)先權(quán)
當(dāng)Slave節(jié)點(diǎn)發(fā)現(xiàn)Master節(jié)點(diǎn)處于FAIL狀態(tài)時，不會立刻試圖進(jìn)行選舉，而是會延遲一段時間，延遲時常用以下公式進(jìn)行計算：

Txt代碼 ?

DELAY?=?500?milliseconds?+?random?delay?between?0?and?500?milliseconds?+???SLAVE_RANK?*?1000?milliseconds??

其中，SLAVE_RANK由Slave收到Master數(shù)據(jù)復(fù)制的更新程度來衡量。在發(fā)起選舉之前，Slave之間交換各自獲得Master數(shù)據(jù)復(fù)制的更新排名，最新更新的SLAVE_RANK = 0， 其次更新的SLAVE_RANK = 1，以此類推...

4.2.3.6 故障轉(zhuǎn)移耗時評估

• 假設(shè)配置NODE_TIMEOUT=2s，FAIL_REPORT_VALIDITY_MULT=3s

• 標(biāo)記Master為PFAIL狀態(tài)耗時NODE_TIMEOUT=2s

• 升級PFAIL狀態(tài)為FAIL狀態(tài)，耗時：NODE_TIMEOUT * FAIL_REPORT_VALIDITY_MULT = 6s

• 選舉前隨機(jī)延時期望：1s

• 收集足夠多Master投票：MAX((2*NODE_TIMEOUT),2)=4s

• 總計耗時約：13s

4.3.3 主備平衡功能
Redis Cluster能夠自動的遷移Slave節(jié)點(diǎn)，從Slave節(jié)點(diǎn)有冗余的Master節(jié)點(diǎn)到完全沒有Slave節(jié)點(diǎn)的Master節(jié)點(diǎn)。
具體算法：

• 首先定義Good Slave：對于某一節(jié)點(diǎn)來說，如果另一個Slave節(jié)點(diǎn)沒有處于FAIL狀態(tài)，則認(rèn)為該Slave節(jié)點(diǎn)為Good Slave節(jié)點(diǎn)。

• 當(dāng)有Slave節(jié)點(diǎn)發(fā)現(xiàn)有Master節(jié)點(diǎn)沒有Good Slave時開始觸發(fā)主備平衡遷移。

• 所有發(fā)現(xiàn)有主備平衡需求之后，擁有最多Good Slave節(jié)點(diǎn)的Master節(jié)點(diǎn)的所有Slave中，Node ID最小的Slave節(jié)點(diǎn)真正開始遷移。成為沒有沒有Good Slave Master新Master。

• 可以配置cluster-migration-barrier參數(shù)，控制主備平衡遷移的時候，遷出Master最少需要擁有的Good Slave數(shù)

4.4 Codis

• 支持故障檢測并報警

• codis-redis-group中的Slave節(jié)點(diǎn)無法自動提升為Master節(jié)點(diǎn)

• 由管理員通過Web界面/命令行來手動操作

5.功能限制
Twemproxy:

• 不支持多key操作

• 不支持MULTI/EXEC

• 不支持EVAL

Redis Cluster:

• 當(dāng)Client連接到集群的主體部分時可能有少量的寫丟失，當(dāng)Client連接到集群的小部分時可能有顯著的寫丟失

• 復(fù)雜的多Key操作（Set求并/求交）不能跨節(jié)點(diǎn)操作,可以通過使用Hash Tag使相關(guān)Key強(qiáng)制哈希到同一Server，但是在數(shù)據(jù)重新分片期間，還是可能有時間不可用

• 不支持MULTI/EXEC

• Redis 3.0 正式版時間：2015年2月上旬

Codis:
不支持命令：KEYS, MOVE, OBJECT, RENAME, RENAMENX, SORT, SCAN, BITOP,MSETNX, BLPOP, BRPOP, BRPOPLPUSH, PSUBSCRIBE，PUBLISH, PUNSUBSCRIBE, SUBSCRIBE, UNSUBSCRIBE, DISCARD, EXEC, MULTI, UNWATCH, WATCH, SCRIPT EXISTS, SCRIPT FLUSH, SCRIPT KILL, SCRIPT LOAD, AUTH, ECHO, SELECT, BGREWRITEAOF, BGSAVE, CLIENT KILL, CLIENT LIST, CONFIG GET, CONFIG SET, CONFIG RESETSTAT, DBSIZE, DEBUG OBJECT, DEBUG SEGFAULT, FLUSHALL, FLUSHDB, INFO, LASTSAVE, MONITOR, SAVE, SHUTDOWN, SLAVEOF, SLOWLOG, SYNC, TIME


6. 性能
Twemproxy:[來源：http://antirez.com/news/44]

• 通常操作Proxy與直接操作Redis實(shí)例性能一樣

• 最壞情況下有20%的性能下降

Redis Cluster:[來源: http://redis.io/topics/cluster-spec]
1000個節(jié)點(diǎn)內(nèi)擁有線性的伸縮性：通常情況下與直接操作Redis實(shí)例性能相同。

Codis:[來源：http://0xffff.me/blog/2014/11/11/codis-de-she-ji-yu-shi-xian-part-3/]

• 相對于單Redis實(shí)例40%性能損失

• 支持多核

7. 總結(jié)
Twemprosy:

• 輕量級

• 在Proxy層實(shí)現(xiàn)一致性哈希

• 快速的故障節(jié)點(diǎn)移除

• 可借助Sentinel和重啟工具降低故障節(jié)點(diǎn)移除時的Cache失配

Redis Cluster：

• 無中心自組織結(jié)構(gòu)

• 更強(qiáng)的功能：主備平衡

• 故障轉(zhuǎn)移響應(yīng)時間長

• 暫時未達(dá)到正式版

Codis：

• 基于Zookeeper的Proxy高可用

• 非官方Redis實(shí)現(xiàn)

• 側(cè)重于動態(tài)水平擴(kuò)容

• 手動故障轉(zhuǎn)移

本文轉(zhuǎn)自 msj0905 51CTO博客，原文鏈接:http://blog.51cto.com/sky66/1719189

總結(jié)

以上是生活随笔為你收集整理的Redis集群解决方案比较的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。