2五、如何實現redis集羣?

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

下面介紹Redis的集羣方案。

一、客戶端分片

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

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

客戶端分片方案有下面這些缺點：

　　●這是一種靜態的分片方案，須要增長或者減小Redis實例的數量，須要手工調整分片的程序。

　　●可運維性差，集羣的數據出了任何問題都須要運維人員和開發人員一塊兒合做，減緩了解決問題的速度，增長了跨部門溝通的成本。

　　●在不一樣的客戶端程序中，維護相同的分片邏輯成本巨大。例如，系統中有兩套業務系統共用一套Redis集羣，一套業務系統用Java實現，另外一套業務系統用PHP實現。爲了保證分片邏輯的一致性，在Java客戶端中實現的分片邏輯也須要在PHP客戶端實現一次。相同的邏輯在不一樣的系統中分別實現，這種設計原本就很是糟糕，並且須要耗費巨大的開發成本保證兩套業務系統分片邏輯的一致性。

二、Twemproxy

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

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

 Twemproxy集羣架構以下圖所示：

Twemproxy的優勢以下：

　　●客戶端像鏈接Redis實例同樣鏈接Twemproxy，不須要改任何的代碼邏輯。

　　●支持無效Redis實例的自動刪除。

　　●Twemproxy與Redis實例保持鏈接，減小了客戶端與Redis實例的鏈接數。

Twemproxy的缺點以下：

　　●因爲Redis客戶端的每一個請求都通過Twemproxy代理才能到達Redis服務器，這個過程當中會產生性能損失。

　　●沒有友好的監控管理後臺界面，不利於運維監控。

　　●最大的問題是Twemproxy沒法平滑地增長Redis實例。對於運維人員來講，當由於業務須要增長Redis實例時工做量很是大。

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

 三、Redis 3.0集羣

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

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

Redis 3.0集羣的工做流程以下圖所示：

如圖所示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集羣在業界並無被大規模使用。

四、雲服務器上的集羣服務

國內的雲服務器提供商阿里雲、UCloud等均推出了基於Redis的雲存儲服務。

　　這個服務的特性以下。

　　（1）動態擴容

　　用戶能夠經過控制面板升級所需的Redis存儲空間，擴容的過程當中服務部不須要中斷或中止，整個擴容過程對用戶透明、無感知，這點是很是實用的，在前面介紹的方案中，解決Redis平滑擴容是個很煩瑣的任務，如今按幾下鼠標就能搞定，大大減小了運維的負擔。

　　（2）數據多備

　　數據保存在一主一備兩臺機器中，其中一臺機器宕機了，數據還在另一臺機器上有備份。

　　（3）自動容災

　　主機宕機後系統能自動檢測並切換到備機上，實現服務的高可用。

　　（4）實惠

　　不少狀況下爲了使Redis的性能更高，須要購買一臺專門的服務器用於Redis的存儲服務，但這樣子CPU、內存等資源就浪費了，購買Redis雲存儲服務就很好地解決了這個問題。

　　有了Redis雲存儲服務，能使App後臺開發人員從煩瑣運維中解放出來。App後臺要搭建一個高可用、高性能的Redis服務，須要投入至關的運維成本和精力。若是使用雲存儲服務，就不必投入這些成本和精力，可讓App後臺開發人員更專一於業務。