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

[[271619]]

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

Redis集群實現方式：

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

集群的實現方式：

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

下面我們對三種實現方式展開介紹：

客戶端分片

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

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

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

基于代理的分片

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

Twemproxy

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

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

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

Twemproxy優(yōu)點：

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

Twemproxy不足：

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

Codis

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

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

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

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

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

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

路由查詢

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

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

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

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