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

[[271619]]

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

Redis集群實現方式：

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

集群的實現方式：

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

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

客戶端分片

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

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

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

基于代理的分片

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

Twemproxy

Twemproxy是一款由Twitter開源的redis proxy方案，在Twitter、Yahoo都有使用。當Twemproxy工作時，Redis客戶端會把請求發送到Twemproxy，Twemproxy會使用一致性hash算法，根據路由規則發送正確的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本身是一個獨立運行的進程，它能監控多個master-slave集群，發現master宕機后可以進行自動切換。

Twemproxy優點：

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

Twemproxy不足：

• 無法動態擴容，如果需要擴容功能，必須研發人員手動遷移，比較繁瑣;
• 由于Redis客戶端的請求都需要經過Twemproxy才能到達Redis服務器，期間難免會產生性能損失;
• 無法平滑地擴容/縮容，對于運維人員來說，如果業務需要增加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，每一個組件都可以進行動態擴容。

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

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

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

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

路由查詢

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

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

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

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