調(diào)研比較了三個(gè)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)不會(huì)轉(zhuǎn)發(fā)請求，只是重定向Client

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

數(shù)據(jù)分片算法：
Key空間被劃分為16384個(gè)區(qū)間,每個(gè)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個(gè)區(qū)間, 對于每個(gè)key來說, 通過以下公式確定所屬的 Slot Id : SlotId = crc32(key) % 1024

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

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

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

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

Redis Cluster:

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

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

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

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

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

Codis:

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

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

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

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

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

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

Codis:

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

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

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

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

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

• 此后Master將啟動(dòng)后臺(tái)存盤進(jìn)程，同時(shí)收集所有接收到的用于修改數(shù)據(jù)集的命令，在后臺(tái)進(jìn)程執(zhí)行完畢后，Master將傳送整個(gè)數(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端都不會(huì)阻塞。

• Slave會(huì)周期性確認(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本身通過三個(gè)配置項(xiàng)實(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，都超時(shí)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í)評估
假設(shè)配置：timeout=400ms, server_failure_limit=2， 則故障轉(zhuǎn)移需要耗時(shí)800ms。


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

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

4.2.1 啟動(dòng)Redis Sentinel

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

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

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

4.2.2 故障檢測

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

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

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

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

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

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è)定的故障遷移超時(shí)時(shí)間的兩倍之后， 重新嘗試當(dāng)選。 如果當(dāng)選成功， 那么執(zhí)行以下步驟。

• 選出一個(gè)Slave節(jié)點(diǎn)，并將它升級(jí)為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)，此時(shí)需要引入第四方工具redis-twemproxy-agent（node.js），更新Twemproxy配置，并重啟。


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

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

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

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

• 選出一個(gè)Slave節(jié)點(diǎn)，并將它升級(jí)為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

• 總計(jì)耗時(shí)：6.5s

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

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

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

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

PFAIL狀態(tài)：

• 當(dāng)一個(gè)節(jié)點(diǎn)發(fā)現(xiàn)某一節(jié)點(diǎn)在長達(dá)NODE_TIMEOUT的時(shí)間內(nèi)都無法訪問時(shí)，將其標(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)一個(gè)節(jié)點(diǎn)發(fā)現(xiàn)另一節(jié)點(diǎn)被自己標(biāo)記為PFAIL狀態(tài)，并且在(NODE_TIMEOUT * FAIL_REPORT_VALIDITY_MULT)的時(shí)間范圍內(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選舉的時(shí)機(jī)
當(dāng)某一Slave節(jié)點(diǎn)發(fā)現(xiàn)它的Master節(jié)點(diǎn)處于FAIL狀態(tài)時(shí)，可以發(fā)起一次Slave選舉，試圖將自己晉升為Master。一個(gè)Master節(jié)點(diǎn)的所有Slave節(jié)點(diǎn)都可以發(fā)起選舉，但最終只有一個(gè)Slave節(jié)點(diǎn)會(huì)贏得選舉。Slave發(fā)起選舉的條件：

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

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

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

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

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

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

• 則把自己的currentEpoch+1

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

Cluster epoch：
每一個(gè)節(jié)點(diǎn)啟動(dòng)的時(shí)候都會(huì)創(chuàng)建currentEpoch字段，無論是Master節(jié)點(diǎn)還是Slave節(jié)點(diǎn)，并設(shè)置初始值為0。每當(dāng)一個(gè)節(jié)點(diǎn)收到來 自其他節(jié)點(diǎn)的PING/PONG包時(shí)，若其他節(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ù)包給每一個(gè)MASTER節(jié)點(diǎn)

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

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

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

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

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

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

• Master節(jié)點(diǎn)維護(hù)lastVoteEpoch字段，每當(dāng)MASTER給某個(gè)選舉請求投票時(shí)，更新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)時(shí)，不會(huì)立刻試圖進(jìn)行選舉，而是會(huì)延遲一段時(shí)間，延遲時(shí)常用以下公式進(jìn)行計(jì)算：

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í)評估

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

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

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

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

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

• 總計(jì)耗時(shí)約：13s

4.3.3 主備平衡功能
Redis Cluster能夠自動(dòng)的遷移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)來說，如果另一個(gè)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時(shí)開始觸發(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ù)，控制主備平衡遷移的時(shí)候，遷出Master最少需要擁有的Good Slave數(shù)

4.4 Codis

• 支持故障檢測并報(bào)警

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

• 由管理員通過Web界面/命令行來手動(dòng)操作

5.功能限制
Twemproxy:

• 不支持多key操作

• 不支持MULTI/EXEC

• 不支持EVAL

Redis Cluster:

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

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

• 不支持MULTI/EXEC

• Redis 3.0 正式版時(shí)間：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個(gè)節(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:

• 輕量級(jí)

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

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

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

Redis Cluster：

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

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

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

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

Codis：

• 基于Zookeeper的Proxy高可用

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

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

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

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

總結(jié)

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

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