這多是最全的 Redis 集羣方案介紹了

時間 2019-11-06

標籤 redis 集羣方案介紹欄目 Redis 简体版

原文原文鏈接

這多是最全的 Redis 集羣方案介紹了

原創 2016-06-01 曾健生 運維幫算法

因爲Redis出衆的性能，其在衆多的移動互聯網企業中獲得普遍的應用。Redis在3.0版本前只支持單實例模式，雖然如今的服務器內存能夠到100GB、200GB的規模，可是單實例模式限制了Redis無法知足業務的需求（例如新浪微博就曾經用Redis存儲了超過1TB的數據）。Redis的開發者Antirez早在博客上就提出在Redis 3.0版本中加入集羣的功能，但3.0版本等到2015年才發佈正式版。各大企業在3.0版本還沒發佈前爲了解決Redis的存儲瓶頸，紛紛推出了各自的Redis集羣方案。這些方案的核心思想是把數據分片（sharding）存儲在多個Redis實例中，每一片就是一個Redis實例。tomcat

下面介紹Redis的集羣方案。安全

1.客戶端分片

客戶端分片是把分片的邏輯放在Redis客戶端實現，經過Redis客戶端預先定義好的路由規則，把對Key的訪問轉發到不一樣的Redis實例中，最後把返回結果聚集。這種方案的模式如圖1所示。服務器

圖1　客戶端分片的模式微信

客戶端分片的好處是全部的邏輯都是可控的，不依賴於第三方分佈式中間件。開發人員清楚怎麼實現分片、路由的規則，不用擔憂踩坑。架構

客戶端分片方案有下面這些缺點。負載均衡

這是一種靜態的分片方案，須要增長或者減小Redis實例的數量，須要手工調整分片的程序。運維
可運維性差，集羣的數據出了任何問題都須要運維人員和開發人員一塊兒合做，減緩了解決問題的速度，增長了跨部門溝通的成本。異步
在不一樣的客戶端程序中，維護相同的分片邏輯成本巨大。例如，系統中有兩套業務系統共用一套Redis集羣，一套業務系統用Java實現，另外一套業務系統用PHP實現。爲了保證分片邏輯的一致性，在Java客戶端中實現的分片邏輯也須要在PHP客戶端實現一次。相同的邏輯在不一樣的系統中分別實現，這種設計原本就很是糟糕，並且須要耗費巨大的開發成本保證兩套業務系統分片邏輯的一致性。分佈式

2.Twemproxy

Twemproxy是由Twitter開源的Redis代理，其基本原理是：Redis客戶端把請求發送到Twemproxy，Twemproxy根據路由規則發送到正確的Redis實例，最後Twemproxy把結果聚集返回給客戶端。

Twemproxy經過引入一個代理層，將多個Redis實例進行統一管理，使Redis客戶端只須要在Twemproxy上進行操做，而不須要關心後面有多少個Redis實例，從而實現了Redis集羣。

Twemproxy集羣架構如圖2所示。

圖2Twemproxy集羣架構

Twemproxy的優勢以下。

客戶端像鏈接Redis實例同樣鏈接Twemproxy，不須要改任何的代碼邏輯。
支持無效Redis實例的自動刪除。
Twemproxy與Redis實例保持鏈接，減小了客戶端與Redis實例的鏈接數。

Twemproxy有以下不足。

因爲Redis客戶端的每一個請求都通過Twemproxy代理才能到達Redis服務器，這個過程當中會產生性能損失。
沒有友好的監控管理後臺界面，不利於運維監控。
最大的問題是Twemproxy沒法平滑地增長Redis實例。對於運維人員來講，當由於業務須要增長Redis實例時工做量很是大。

Twemproxy做爲最被普遍使用、最久經考驗、穩定性最高的Redis代理，在業界被普遍使用。

3.Codis

Twemproxy不能平滑增長Redis實例的問題帶來了很大的不便，因而豌豆莢自主研發了Codis，一個支持平滑增長Redis實例的Redis代理軟件，其基於Go和C語言開發，並於2014年11月在GitHub上開源。

Codis包含下面4個部分。

Codis Proxy：Redis客戶端鏈接到Redis實例的代理，實現了Redis的協議，Redis客戶端鏈接到Codis Proxy進行各類操做。Codis Proxy是無狀態的，能夠用Keepalived等負載均衡軟件部署多個Codis Proxy實現高可用。
CodisRedis：Codis項目維護的Redis分支，添加了slot和原子的數據遷移命令。Codis上層的 Codis Proxy和Codisconfig只有與這個版本的Redis通訊才能正常運行。
Codisconfig：Codis管理工具。能夠執行添加刪除CodisRedis節點、添加刪除Codis Proxy、數據遷移等操做。另外，Codisconfig自帶了HTTP server，裏面集成了一個管理界面，方便運維人員觀察Codis集羣的狀態和進行相關的操做，極大提升了運維的方便性，彌補了Twemproxy的缺點。
ZooKeeper：分佈式的、開源的應用程序協調服務，是Hadoop和Hbase的重要組件，其爲分佈式應用提供一致性服務，提供的功能包括：配置維護、名字服務、分佈式同步、組服務等。Codis依賴於ZooKeeper存儲數據路由表的信息和Codis Proxy節點的元信息。另外，Codisconfig發起的命令都會經過ZooKeeper同步到CodisProxy的節點。

Codis的架構如圖3所示。

圖3Codis的架構圖

在圖3的Codis的架構圖中，Codis引入了Redis Server Group，其經過指定一個主CodisRedis和一個或多個從CodisRedis，實現了Redis集羣的高可用。當一個主CodisRedis掛掉時，Codis不會自動把一個從CodisRedis提高爲主CodisRedis，這涉及數據的一致性問題（Redis自己的數據同步是採用主從異步複製，當數據在主CodisRedis寫入成功時，從CodisRedis是否已讀入這個數據是無法保證的），須要管理員在管理界面上手動把從CodisRedis提高爲主CodisRedis。

若是以爲麻煩，豌豆莢也提供了一個工具Codis-ha，這個工具會在檢測到主CodisRedis掛掉的時候將其下線並提高一個從CodisRedis爲主CodisRedis。

Codis中採用預分片的形式，啓動的時候就建立了1024個slot，1個slot至關於1個箱子，每一個箱子有固定的編號，範圍是1~1024。slot這個箱子用做存放Key，至於Key存放到哪一個箱子，能夠經過算法「crc32(key)%1024」得到一個數字，這個數字的範圍必定是1~1024之間，Key就放到這個數字對應的slot。例如，若是某個Key經過算法「crc32(key)%1024」獲得的數字是5，就放到編碼爲5的slot（箱子）。1個slot只能放1個Redis Server Group，不能把1個slot放到多個Redis Server Group中。1個Redis Server Group最少能夠存放1個slot，最大能夠存放1024個slot。所以，Codis中最多能夠指定1024個Redis Server Group。

Codis最大的優點在於支持平滑增長（減小）Redis Server Group（Redis實例），能安全、透明地遷移數據，這也是Codis 有別於Twemproxy等靜態分佈式 Redis 解決方案的地方。Codis增長了Redis Server Group後，就牽涉到slot的遷移問題。例如，系統有兩個Redis Server Group，Redis Server Group和slot的對應關係以下。

Redis Server Group	slot
1	1~500
2	501~1024

當增長了一個Redis Server Group，slot就要從新分配了。Codis分配slot有兩種方法。

第一種：經過Codis管理工具Codisconfig手動從新分配，指定每一個Redis Server Group所對應的slot的範圍，例如能夠指定Redis Server Group和slot的新的對應關係以下。

Redis Server Group	slot
1	1~500
2	501~700
3	701~1024

第二種：經過Codis管理工具Codisconfig的rebalance功能，會自動根據每一個Redis Server Group的內存對slot進行遷移，以實現數據的均衡。

4.Redis 3.0集羣

Redis 3.0集羣採用了P2P的模式，徹底去中心化。Redis把全部的Key分紅了16384個slot，每一個Redis實例負責其中一部分slot。集羣中的全部信息（節點、端口、slot等），都經過節點之間按期的數據交換而更新。

Redis客戶端在任意一個Redis實例發出請求，若是所需數據不在該實例中，經過重定向命令引導客戶端訪問所需的實例。

Redis 3.0集羣的工做流程如圖4所示。

圖4Redis 3.0集羣的工做流程圖

如圖4所示Redis集羣內的機器按期交換數據，工做流程以下。

（1） Redis客戶端在Redis2實例上訪問某個數據。

（2）在Redis2內發現這個數據是在Redis3這個實例中，給Redis客戶端發送一個重定向的命令。

（3） Redis客戶端收到重定向命令後，訪問Redis3實例獲取所需的數據。

Redis 3.0的集羣方案有如下兩個問題。

一個Redis實例具有了「數據存儲」和「路由重定向」，徹底去中心化的設計。這帶來的好處是部署很是簡單，直接部署Redis就行，不像Codis有那麼多的組件和依賴。但帶來的問題是很難對業務進行無痛的升級，若是哪天Redis集羣出了什麼嚴重的Bug，就只能回滾整個Redis集羣。
對協議進行了較大的修改，對應的Redis客戶端也須要升級。升級Redis客戶端後誰能確保沒有Bug？並且對於線上已經大規模運行的業務，升級代碼中的Redis客戶端也是一個很麻煩的事情。

綜合上面所述的兩個問題，Redis 3.0集羣在業界並無被大規模使用。