最全的 Redis 集群方案

這可能是最全的Redis集群方案介紹了由于Redis出眾的性能，其在眾多的移動互聯(lián)網(wǎng)企業(yè)中得到廣泛的應用。Redis在3.0版本前只支持單實例模式，雖然現(xiàn)在的服務器內(nèi)存可以到100GB、200GB的規(guī)模，但是單實例模式限制了Redis沒法滿足業(yè)務的需求（例如新浪微博就曾經(jīng)用Redis存儲了超過1TB的數(shù)據(jù)）。Redis的開發(fā)者Antirez早在博客上就提出在Redis3.0版本中加入集群的功能，但3.0版本等到2015年才發(fā)布正式版。各大企業(yè)在3.0版本還沒發(fā)布前為了解決Redis的存儲瓶頸，紛紛推出了各自的Redis集群方案。這些方案的核心思想是把數(shù)據(jù)分片（sharding）存儲在多個Redis實例中，每一片就是一個Redis實例。下面介紹Redis的集群方案。1.客戶端分片客戶端分片是把分片的邏輯放在Redis客戶端實現(xiàn)，通過Redis客戶端預先定義好的路由規(guī)則，把對Key的訪問轉(zhuǎn)發(fā)到不同的Redis實例中，最后把返回結(jié)果匯集。這種方案的模式如圖1所示。Redis客戶端業(yè)務程序Redis^例2前端通信模塊路由規(guī)則結(jié)果匯集R崩詁實例通信模塊Red姑實例Redis客戶端業(yè)務程序Redis^例2前端通信模塊路由規(guī)則結(jié)果匯集R崩詁實例通信模塊Red姑實例1P也域娜圖1客戶端分片的模式客戶端分片方案有下面這些缺點。?這是一種靜態(tài)的分片方案，需要增加或者減少Redis實例的數(shù)量，需要手工調(diào)整分片的程序。?可運維性差，集群的數(shù)據(jù)出了任何問題都需要運維人員和開發(fā)人員一起合作，減緩了解決問題的速度，增加了跨部門溝通的成本。?在不同的客戶端程序中，維護相同的分片邏輯成本巨大。例如，系統(tǒng)中有兩套業(yè)務系統(tǒng)共用一套Redis集群，一套業(yè)務系統(tǒng)用Java實現(xiàn)，另一套業(yè)務系統(tǒng)用PHP實現(xiàn)。為了保證分片邏輯的一致性，在Java客戶端中實現(xiàn)的分片邏輯也需要在PHP客戶端實現(xiàn)一次。相同的邏輯在不同的系統(tǒng)中分別實現(xiàn)，這種設計本來就非常糟糕，而且需要耗費巨大的開發(fā)成本保證兩套業(yè)務系統(tǒng)分片邏輯的一致性。TwemproxyTwemproxy是由Twitter開源的Redis代理，其基本原理是：Redis客戶端把請求發(fā)送到Twemproxy，Twemproxy根據(jù)路由規(guī)則發(fā)送到正確的Redis實例，最后Twemproxy把結(jié)果匯集返回給客戶端。Twemproxy通過引入一個代理層，將多個Redis實例進行統(tǒng)一管理，使Redis客戶端只需要在Twemproxy上進行操作，而不需要關心后面有多少個Redis實例，從而實現(xiàn)了Redis集群。Twemproxy集群架構(gòu)如圖2所示。

客戶端Reais實例"圖2Twemproxy集群架構(gòu)Twemproxy的優(yōu)點如下。?客戶端像連接Redis實例一樣連接Twemproxy，不需要改任何的代碼邏輯。?支持無效Redis實例的自動刪除。?Twemproxy與Redis實例保持連接，減少了客戶端與Redis實例的連接數(shù)。Twemproxy有如下不足。?由于Redis客戶端的每個請求都經(jīng)過Twemproxy代理才能到達Redis服務器，這個過程中會產(chǎn)生性能損失。?沒有友好的監(jiān)控管理后臺界面，不利于運維監(jiān)控。?最大的問題是Twemproxy無法平滑地增加Redis實例。對于運維人員來說，當因為業(yè)務需要增加Redis實例時工作量非常大。Twemproxy作為最被廣泛使用、最久經(jīng)考驗、穩(wěn)定性最高的Redis代理，在業(yè)界被廣泛使用。CodisTwemproxy不能平滑增加Redis實例的問題帶來了很大的不便，于是豌豆莢自主研發(fā)了Codis，一個支持平滑增加Redis實例的Redis代理軟件，其基于Go和C語言開發(fā)，并于2014年11月在GitHub上開源。Codis包含下面4個部分。CodisProxy：Redis客戶端連接到Redis實例的代理，實現(xiàn)了Redis的協(xié)議，Redis客戶端連接到CodisProxy進行各種操作。CodisProxy是無狀態(tài)的，可以用Keepalived等負載均衡軟件部署多個CodisProxy實現(xiàn)高可用。CodisRedis：Codis項目維護的Redis分支，添加了slot和原子的數(shù)據(jù)遷移命令。Codis上層的CodisProxy和Codisconfig只有與這個版本的Redis通信才能正常運行。Codisconfig：Codis管理工具。可以執(zhí)行添加刪除CodisRedis節(jié)點、添加刪除CodisProxy、數(shù)據(jù)遷移等操作。另外，Codisconfig自帶了HTTPserver，里面集成了一個管理界面，方便運維人員觀察Codis集群的狀態(tài)和進行相關的操作，極大提高了運維的方便性，彌補了Twemproxy的缺點。ZooKeeper:分布式的、開源的應用程序協(xié)調(diào)服務，是Hadoop和Hbase的重要組件，其為分布式應用提供一致性服務，提供的功能包括：配置維護、名字服務、分布式同步、組服務等。Codis依賴于ZooKeeper存儲數(shù)據(jù)路由表的信息和CodisProxy節(jié)點的元信息。另外，Codisconfig發(fā)起的命令都會通過ZooKeeper同步到CodisProxy的節(jié)點。Codis的架構(gòu)如圖3所示。

CodlsReaisSlaveRedis客戶端RmHs客戶端Redis客戶端ChdisPm叫高可用集新CodisProiylCedisProjy2liedisServer冊叫pHCodisRedisUnsterCodisRedisSlaveCadis3?edisMaster圖3Codis的架構(gòu)圖在圖3的Codis的架構(gòu)圖中，Codis引入了RedisServerGroup,其通過指定一個主CodisRedis和一個或多個從CodlsReaisSlaveRedis客戶端RmHs客戶端Redis客戶端ChdisPm叫高可用集新CodisProiylCedisProjy2liedisServer冊叫pHCodisRedisUnsterCodisRedisSlaveCadis3?edisMaster如果覺得麻煩，豌豆莢也提供了一個工具Codis-ha，這個工具會在檢測到主CodisRedis掛掉的時候?qū)⑵湎戮€并提升一個從CodisRedis為主CodisRedis。Codis中采用預分片的形式，啟動的時候就創(chuàng)建了1024個slot，1個slot相當于1個箱子，每個箱子有固定的編號，范圍是1?1024。slot這個箱子用作存放Key，至于Key存放到哪個箱子，可以通過算法"crc32（key）%1024”獲得一個數(shù)字，這個數(shù)字的范圍一定是1?1024之間，Key就放到這個數(shù)字對應的slot。例如，如果某個Key通過算法“crc32（key）%1024”得到的數(shù)字是5，就放到編碼為5的slot（箱子）。1個slot只能放1個RedisServerGroup，不能把1個slot放到多個RedisServerGroup中。1個RedisServerGroup最少可以存放1個slot，最大可以存放1024個slot。因此，Codis中最多可以指定1024個RedisServerGroup。Codis最大的優(yōu)勢在于支持平滑增加（減少）RedisServerGroup（Redis實例），能安全、透明地遷移數(shù)據(jù)，這也是Codis有別于Twemproxy等靜態(tài)分布式Redis解決方案的地方。Codis增加了RedisServerGroup后，就牽涉到

slot的遷移問題。例如，系統(tǒng)有兩個RedisServerGroup,RedisServerGroup和slot的對應關系如下。RedisServerGroupslot1~500501~1024當增加了一個RedisServerGroup，slot就要重新分配了。Codis分配slot有兩種方法。第一種：通過Codis管理工具Codisconfig手動重新分配，指定每個RedisServerGroup所對應的slot的范圍，例如可以指定RedisServerGroup和slot的新的對應關系如下。RedisServerGroupslot11~5002501~700701~1024第二種：通過Codis管理工具Codisconfig的rebalance功能，會自動根據(jù)每個RedisServerGroup的內(nèi)存對slot進行遷移，以實現(xiàn)數(shù)據(jù)的均衡。

Redis3.0集群采用了P2P的模式，完全去中心化。Redis把所有的Key分成了16384個slot，每個Redis實例負責其中一部分slot。集群中的所有信息（節(jié)點、端口、slot等），都通過節(jié)點之間定期的數(shù)據(jù)交換而更新。Redis客戶端在任意一個Redis實例發(fā)出請求，如果所需數(shù)據(jù)不在該實例中，通過重定向命令引導客戶端訪問所需的實例。Redis3.0集群的工作流程如圖4所示。3,訕問Redis1發(fā)指令重定向客戶Redis3.0的集群;3,訕問Redis1發(fā)指令重定向客戶Redis3.0的集群;Redib1L發(fā)清求到Redis2Redis2圖4Redis3.0集群的工作流程圖如圖4所示Redis集群內(nèi)的機器定期交換數(shù)據(jù)，工作流程如下。（1）Redis客戶端在Redis2實例上訪問某個數(shù)據(jù)。（2）在Redis2內(nèi)發(fā)現(xiàn)這個數(shù)據(jù)是在Redis3這個實例中，給Redis客戶端發(fā)送一個重定向的命令。（3）Redis客戶端收到重定向命令后，訪問Redis3實例獲取所需的數(shù)據(jù)。Redis3.0的集群方案有以下兩個問題。?一個Redis實例具備了“數(shù)據(jù)存儲”和“路由重定向”，完全去中心化的設計。這帶來的好處是部署非常簡單，直接部署Redis就行，不像Codis有那么多的組件和依賴。但帶來的問題是很難對業(yè)務進行無痛的升級，如果哪天Redis集群出了什么嚴重的Bug，就只能回滾整個Redis集群。?對協(xié)議進行了較大的修改，對應的Redis客戶端也需要升級。升級Redis客戶端后誰能確保沒有Bug？而且對于線上已經(jīng)大規(guī)模運行的業(yè)務，升級代碼中的Redis客戶端也是一個很麻煩的事情。綜合上面所述的兩個問題，Redis3.0集群在業(yè)界并沒有被大規(guī)模使用。5.云服務器上的集群服務國內(nèi)的云服務器提供商阿里云、UCloud等均推出了基于Redis的云存儲服務。這個服務的特性如下。（1）動態(tài)擴容用戶可以通過控制面板升級所需的Redis存儲空間，擴容的過程中服務部不需要中斷或停止，整個擴容過程對用戶透明、無感知，這點是非常實用的，在前面介紹的方案中，解決Redis平滑擴容是個很煩瑣的任務，現(xiàn)在按幾下鼠標就能搞定，大大減少了運維的負擔。（2）數(shù)據(jù)多備數(shù)據(jù)保存在一主一備兩臺機器中，其中一臺機器宕機了，數(shù)據(jù)還在另外一臺機器上有備份。（3）自動容災主機宕機后系