Redis，一款技術(shù)研發(fā)者們耳熟能詳?shù)膬?nèi)存數(shù)據(jù)庫。作為數(shù)據(jù)庫，存儲數(shù)據(jù)的容量都是有限的，不能超過主機內(nèi)存的大小。通常而言，一臺主機服務(wù)器的內(nèi)存只有十幾G，較大可達100G或200G。

[[271805]]

為了解決Redis存儲瓶頸問題，各大企業(yè)紛紛開始尋找解決方案，將數(shù)據(jù)分片(sharding)存儲在多個Redis實例之中，每一個分片就是一個Redis實例，然后實現(xiàn)多個Redis實例協(xié)同運行。這就是Redis集群原理。本篇將圍繞Redis集群方案展開重點介紹。

Redis集群實現(xiàn)方式：

• 分區(qū)，將數(shù)據(jù)分割劃分到多個Redis實例中去，然后保證每個實例只保存key的一個子集;
• 通過多臺計算機的內(nèi)存和值構(gòu)造更大的數(shù)據(jù)庫;
• 通過多臺計算機擴展計算能力;
• 通過多臺計算機機和網(wǎng)絡(luò)適配，擴展網(wǎng)絡(luò)寬帶。

集群的實現(xiàn)方式：

• 客戶端分片
• 基于代理的分片
• 路由查詢

下面我們對三種實現(xiàn)方式展開介紹：

客戶端分片

客戶端分片就是將分片工作放在業(yè)務(wù)程序端實現(xiàn)，程序代碼根據(jù)Redis客戶端預(yù)先定義好的路由規(guī)則，直接對不同的Redis實例進行分布式訪問，最終再把結(jié)果匯集在一起。

這種方案的優(yōu)勢就在于所有邏輯都是可以控制的，沒有第三方中間件干預(yù)，開發(fā)人員很清楚如何實現(xiàn)分片及路由規(guī)則，實現(xiàn)方法完全由自己掌控。

但是客戶端分片方案的弊端也是令開發(fā)者也是十分懊惱的。由于客戶端分片方案是一種靜態(tài)的分片方案，無論是增加或是減少Redis實例的數(shù)量，都必須要開發(fā)者手動調(diào)整分片程序，對開發(fā)者的依賴很強;其次在運維上，該方案運維性較差，一旦集群數(shù)據(jù)出現(xiàn)問題，就需要開發(fā)人員和運維人員共同解決，在不同的客戶端程序中，維護相同的分片邏輯成本很大，需要消耗巨大的開發(fā)成本才能保證兩套業(yè)務(wù)系統(tǒng)分片邏輯一致。所以，客戶端分片方案并不適合中小型的企業(yè)使用。

基于代理的分片

基于代理分片就是客戶端發(fā)送請求到一個代理，由代理來解析客戶端的數(shù)據(jù)，再將請求轉(zhuǎn)發(fā)到正確的節(jié)點，最終將結(jié)果回復(fù)給客戶端。常用的基于代理的分片方案有兩種，Twemproxy、codis。

Twemproxy

Twemproxy是一款由Twitter開源的redis proxy方案，在Twitter、Yahoo都有使用。當(dāng)Twemproxy工作時，Redis客戶端會把請求發(fā)送到Twemproxy，Twemproxy會使用一致性hash算法，根據(jù)路由規(guī)則發(fā)送正確的Redis實例，最后Twemproxy再把結(jié)果返給客戶端，從而實現(xiàn)Redis集群。

由于Twemproxy是單線程方案，所以只能使用單核cpu，如果前端含keepalive或haproxy相關(guān)代理，可以為Twemproxy做1+1準(zhǔn)備。

當(dāng)Twemproxy應(yīng)用于多臺Redis服務(wù)器時，那么實現(xiàn)的性能只能達到單臺Redis服務(wù)器80%，剩余20%性能損耗。Redis-Sentinel是Redis官方推薦的一種高可用性解決方案，當(dāng)用Redis做Master-slave的高可用方案時，如果Master宕機了，Twemproxy會訂閱Sentinel,完成主備切換。由于Redis-sentinel本身是一個獨立運行的進程，它能監(jiān)控多個master-slave集群，發(fā)現(xiàn)master宕機后可以進行自動切換。

Twemproxy優(yōu)點：

• 支持Redis和memcached兩種集群代理;
• 后端Redis和memcached無需任何改動，只需要提供IP和端口給Twemproxy即可，操作簡單;
• 支持無效Redis實例的自動刪除;
• 支持狀態(tài)監(jiān)控......

Twemproxy不足：

• 無法動態(tài)擴容，如果需要擴容功能，必須研發(fā)人員手動遷移，比較繁瑣;
• 由于Redis客戶端的請求都需要經(jīng)過Twemproxy才能到達Redis服務(wù)器，期間難免會產(chǎn)生性能損失;
• 無法平滑地擴容/縮容，對于運維人員來說，如果業(yè)務(wù)需要增加Redis實例，工作量會非常大......

Codis

Codis是由豌豆莢于2014年11月在GitHub上開源，基于Go和C語言，支持平滑增加Redis實例的集群解決方案。使用Codis時，設(shè)置好下屬的Redis實例，在需要連接Redis的地方改為連接Codis,之后Codis會以一個代理的身份接受請求，并使用一致性hash算法，將請求轉(zhuǎn)接到具體Redis，最后再將結(jié)果返回到Codis。作為基于代理的分片，功能與Twemproxy類似。

Codis主要包含四大組件Codis Proxy(codis proxy)、Codis Manager(codisconfig)、Codis Redis(codis-server)和ZooKeeper，每一個組件都可以進行動態(tài)擴容。

Codis Proxy：客戶端連接到Redis代理服務(wù)，本身已實現(xiàn)了Redis協(xié)議，Redis客戶端連接到Codis Proxy可以進行各種操作。Codis Proxy是無狀態(tài)的，一個業(yè)務(wù)可以通過Keepalived等負(fù)載均衡軟件部署多個Codis Proxy;

Codisconfig：Codisconfig是Codis的管理工具，支持添加/刪除Redis節(jié)點、添加/刪除Proxy節(jié)點、發(fā)起數(shù)據(jù)遷移等操作。另外Codisconfig自帶http server，里面集成一個管理界面，運維人員可以在瀏覽器上觀察Codis集群的運行狀態(tài)并進行相關(guān)操作;

Codis Redis：Codis Redis基于 redis-2.8.21 分支開發(fā)，是Codis項目維護的一個Redis分支，其中加入了slot支持和原子數(shù)據(jù)遷移指令;

ZooKeeper：Codis通過ZooKeeper來存放數(shù)據(jù)路由表和Codis Proxy節(jié)點的原信息，Codisconfig發(fā)起的命令都會通過ZooKeeper同步到各存活的Codis Proxy節(jié)點。

路由查詢

路由查詢是指將任務(wù)請求發(fā)送到任意節(jié)點，接收到請求的節(jié)點會將查詢請求發(fā)送到正確的節(jié)點上執(zhí)行任務(wù)。在Redis集群方案中使用的路由查詢方案有Redis cluster。

Redis Cluster由Redis官方推出，是一種服務(wù)器Sharding技術(shù)，3.0版本開始正式提供，可線性擴展到1000個節(jié)點。在Redis Cluster中，Sharding將所有Key映射到slot中，slot個數(shù)一共16384個。Redis集群中，每個節(jié)點都會負(fù)責(zé)16384個slot中的一部分。當(dāng)動態(tài)添加或減少節(jié)點時，需要將16384個slot重做分配，slot中對應(yīng)的Key也要做遷移。這項工作目前是需要人工介入手動操作的。在使用Redis Cluster時，要確保16384個slot對應(yīng)節(jié)點都能正常工作，如果有一個節(jié)點發(fā)生故障，整個集群都會無法工作。

為了增加集群的可訪問性，Redis官方推薦將節(jié)點配置成主從結(jié)構(gòu)(一個master主節(jié)點掛多個salve從節(jié)點)如果主節(jié)點失效，Redis Cluster會根據(jù)選舉算法從slave節(jié)點中選擇一個上升為主節(jié)點，整個集群繼續(xù)對外提供服務(wù)。

使用Redis cluster時，由于官方并未提供圖形管理工具，所以運維比較復(fù)雜。而且集群管理與數(shù)據(jù)存儲上存在耦合，一旦集群管理出現(xiàn)問題，整個Redis都需要升級整合。Redis Cluster自2015年發(fā)布以來，成功使用的企業(yè)還并不是很多。