詳解Redis集群方案

小編這次要給大家分享的是詳解Redis集群方案，文章內容豐富，感興趣的小伙伴可以來了解一下，希望大家閱讀完這篇文章之后能夠有所收獲。

前段時間搞了搞Redis集群，想用做推薦系統的線上存儲，說來挺有趣，這邊基礎架構不太完善，因此需要我們做推薦系統的自己來搭這個存儲環境，就自己折騰了折騰。公司所給機器的單機性能其實挺給力，已經可以滿足目前的業務需求，想做redis集群主要有以下幾點考慮：

    1、擴展性，scale-out，以后數據量變得很大之后，不至于推到重來，redis雖然可以開啟虛擬內存功能，單機也能提供超過物理內存上限的容量，但頻繁在內存和硬盤間swap頁會大大降低其性能，有點兒違背redis的設計初衷。

    2、redis是一個單線程io復用的結構，無法有效利用服務器的多核結構，如果能在一臺多核機器起多個redis進程，共同提供服務，效率會更高一些。

    3、主從，數據備份和容災。。

因此計劃做的redis集群希望可以實現以下功能：

    1、data sharding，支持數據切片。

    2、主從備份，主節點寫數據，主和從都提供讀請求服務，并且支持主從自動切換。

    3、讀請求做負載均衡。

    4、更好地，支持節點failover，數據自動遷移。

下面是前后經歷的一個過程：

【第一步】嘗試官方方案

   肯定想去查看一下redis的官方集群方案，但是很遺憾，官方對cluster的聲明如下：

Unfortunately Redis Cluster is currently not production ready, however you can get more information about it reading the specification or checking the partial implementation in the unstable branch of the Redis GitHub repositoriy.

Once Redis Cluster will be available, and if a Redis Cluster complaint client is available for your language, Redis Cluster will be the de facto standard for Redis partitioning.

Redis Cluster is a mix between query routing and client side partitioning.

  由于這邊想做生產環境部署，unstable branch目前還是不敢用，在官方目前的版本上做提前開發又沒有資源和時間，因此就放棄了。

【第二步】初步設想的方案

   舍棄了官方的方案后，就想能不能自己搭一個，當時初步的想法是：用lvs做讀請求的負載均衡，在客戶端代碼里自己寫一個一致性hash算法做數據切片，配置redis主從，并且配置keepalived做主從自動切換。這個方案應該可以施行的，但當時自己遇到一些細節方面的問題，就在stackoverflow上問了一下，問題如下：

Since the redis cluster is still a work in progress, I want to build a simplied one by myselfin the current stage. The system should support data sharding,load balance and master-slave backup. A preliminary plan is as follows:

1. Master-slave: use multiple master-slave pairs in different locations to enhance the data security. Matsters are responsible for the write operation, while both masters and slaves can provide the read service. Datas are sent to all the masters during one write operation. Use Keepalived between the master and the slave to detect failures and switch master-slave automatically.

2. Data sharding: write a consistant hash on the client side to support data sharding during write/read in case the memory is not enougth in single machine.

3. Load balance: use LVS to redirect the read request to the corresponding server for the load balance.

My question is how to combine the LVS and the data sharding together?

For example, because of data sharding, all keys are splited and stored in server A,B and C without overlap. Considering the slave backup and other master-slave pairs, the system will contain 1(A,B,C), 2(A,B,C) , 3(A,B,C) and so on, where each one has three servers. How to configure the LVS to support the redirection in such a situation when a read request comes? Or is there other approachs in redis to achieve the same goal?

Thanks:)

有個網友給了兩個建議：

You can really close to what you need by using:

twemproxy shard data across multiple redis nodes (it also supports node ejection and connection pooling)

redis slave master/slave replication

redis sentinel to handle master failover

depending on your needs you probably need some script listening to fail overs (see sentinel docs) and clean things up when a master goes down

這位網友的兩個建議挺啟發的，我在看redis的官方doc的時候，對twemproxy有一些印象，但當時沒有太在意，至于后者用redis sentinel做master failover，redis sentinel也是一個redis正在開發中的模塊，我不太敢用。

另外，我舍棄自己的這個初步方案還有兩個原因：

1、自己在寫客戶端data sharding和均衡服務的時候，發現實際需要考慮的問題比開始想的要復雜一些，如果寫完，其實相當于將twemproxy的功能做了一遍，造輪子的事情還是少干。

2、功能做得有些冗余，一次讀請求要經過客戶端的sharding、然后還有經過lvs再到實際的服務器，不做優化的話，會增加不少延遲。

【第三步】最終的方案，如下圖所示

圖中畫的挺明白了，就不再多解釋了。

twemproxy是twitter開源的一個數據庫代理服務，可以用于memcached和redis的sharding，兼容二者的標準接口，但是對于redis的keys，dbsize等命令不支持，這個其實想一下也就明白了，這種pool內跨機做統計的命令proxy一般不會支持的。另外，twemproxy在自身與后臺redis之間使用pipeline發送命令，因此性能損失比較小。但是，twemproxy對于每一個客戶端連接開啟的mbuf有限，最大可以設置為64k，如果在客戶端代理層與twemproxy之間也使用pipeline，這個pipeline不能太深，而且不支持pipeline的原子性（transaction），其實，這個時候，相當于客戶端連接與redis數據庫之間存在兩層pipeline，分別是客戶端到twemproxy的pipeline，和twemproy到后臺redis服務器的pipeline，由于二者buffer深度不一致，因此不支持pipeline的transaction也就好理解了。。在引入了twemproxy，插入大規模數據的時候，有時候確實挺耗時，而且pipeline不保證原子性，丟數據時的恢復問題在客戶端需要進行額外關注。對于非transaction的pipeline總丟數據，或者對于數據量比較大的key一次性取數據失敗等問題，后來經查是twemproxy端timeou值設置過小，按照官方示例設置400ms，會在一次性操作大數據量的時候返回timeout失敗，這個數值需要慎重根據業務（具體的，就是客戶端單次命令操作的數據量）進行設置，一般2000ms差不多就夠用了（可以支持一次操作接近百萬的數據）。

上面的結構，將讀操作的負載均衡放到了客戶端代碼來做，寫操作控制也在客戶端層的代碼里，另外，對于twemproy單點、主從之間可以引入keepalived來消除單點和故障恢復。

看完這篇關于詳解Redis集群方案的文章，如果覺得文章內容寫得不錯的話，可以把它分享出去給更多人看到。