前段時間搞了搞Redis集群，想用做推薦系統(tǒng)的線上存儲，說來挺有趣，這邊基礎(chǔ)架構(gòu)不太完善，因此需要我們做推薦系統(tǒng)的自己來搭這個存儲環(huán)境，就自己折騰了折騰。公司所給機器的單機性能其實挺給力，已經(jīng)可以滿足目前的業(yè)務(wù)需求，想做redis集群主要有以下幾點考慮：
1、擴展性，scale-out，以后數(shù)據(jù)量變得很大之后，不至于推到重來，redis雖然可以開啟虛擬內(nèi)存功能，單機也能提供超過物理內(nèi)存上限的容量，但頻繁在內(nèi)存和硬盤間swap頁會大大降低其性能，有點兒違背redis的設(shè)計初衷。
2、redis是一個單線程io復用的結(jié)構(gòu)，無法有效利用服務(wù)器的多核結(jié)構(gòu)，如果能在一臺多核機器起多個redis進程，共同提供服務(wù)，效率會更高一些。
3、主從，數(shù)據(jù)備份和容災(zāi)。。
因此計劃做的redis集群希望可以實現(xiàn)以下功能：
1、data sharding，支持數(shù)據(jù)切片。
2、主從備份，主節(jié)點寫數(shù)據(jù)，主和從都提供讀請求服務(wù)，并且支持主從自動切換。
3、讀請求做負載均衡。
4、更好地，支持節(jié)點failover，數(shù)據(jù)自動遷移。
下面是前后經(jīng)歷的一個過程：
【第一步】嘗試官方方案
肯定想去查看一下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.
由于這邊想做生產(chǎn)環(huán)境部署，unstable branch目前還是不敢用，在官方目前的版本上做提前開發(fā)又沒有資源和時間，因此就放棄了。
【第二步】初步設(shè)想的方案
舍棄了官方的方案后，就想能不能自己搭一個，當時初步的想法是：用lvs做讀請求的負載均衡，在客戶端代碼里自己寫一個一致性hash算法做數(shù)據(jù)切片，配置redis主從，并且配置keepalived做主從自動切換。這個方案應(yīng)該可以施行的，但當時自己遇到一些細節(jié)方面的問題，就在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:
-
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.
-
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.
-
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:)
有個網(wǎng)友給了兩個建議：
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
這位網(wǎng)友的兩個建議挺啟發(fā)的，我在看redis的官方doc的時候，對twemproxy有一些印象，但當時沒有太在意，至于后者用redis sentinel做master failover，redis sentinel也是一個redis正在開發(fā)中的模塊，我不太敢用。
另外，我舍棄自己的這個初步方案還有兩個原因：
1、自己在寫客戶端data sharding和均衡服務(wù)的時候，發(fā)現(xiàn)實際需要考慮的問題比開始想的要復雜一些，如果寫完，其實相當于將twemproxy的功能做了一遍，造輪子的事情還是少干。
2、功能做得有些冗余，一次讀請求要經(jīng)過客戶端的sharding、然后還有經(jīng)過lvs再到實際的服務(wù)器，不做優(yōu)化的話，會增加不少延遲。
【第三步】最終的方案，如下圖所示
圖中畫的挺明白了，就不再多解釋了。
twemproxy是twitter開源的一個數(shù)據(jù)庫代理服務(wù)，可以用于memcached和redis的sharding，兼容二者的標準接口，但是對于redis的keys，dbsize等命令不支持，這個其實想一下也就明白了，這種pool內(nèi)跨機做統(tǒng)計的命令proxy一般不會支持的。另外，twemproxy在自身與后臺redis之間使用pipeline發(fā)送命令，因此性能損失比較小。但是，twemproxy對于每一個客戶端連接開啟的mbuf有限，最大可以設(shè)置為64k，如果在客戶端代理層與twemproxy之間也使用pipeline，這個pipeline不能太深，而且不支持pipeline的原子性（transaction），其實，這個時候，相當于客戶端連接與redis數(shù)據(jù)庫之間存在兩層pipeline，分別是客戶端到twemproxy的pipeline，和twemproy到后臺redis服務(wù)器的pipeline，由于二者buffer深度不一致，因此不支持pipeline的transaction也就好理解了。。在引入了twemproxy，插入大規(guī)模數(shù)據(jù)的時候，有時候確實挺耗時，而且pipeline不保證原子性，丟數(shù)據(jù)時的恢復問題在客戶端需要進行額外關(guān)注。對于非transaction的pipeline總丟數(shù)據(jù)，或者對于數(shù)據(jù)量比較大的key一次性取數(shù)據(jù)失敗等問題，后來經(jīng)查是twemproxy端timeou值設(shè)置過小，按照官方示例設(shè)置400ms，會在一次性操作大數(shù)據(jù)量的時候返回timeout失敗，這個數(shù)值需要慎重根據(jù)業(yè)務(wù)（具體的，就是客戶端單次命令操作的數(shù)據(jù)量）進行設(shè)置，一般2000ms差不多就夠用了（可以支持一次操作接近百萬的數(shù)據(jù)）。
上面的結(jié)構(gòu)，將讀操作的負載均衡放到了客戶端代碼來做，寫操作控制也在客戶端層的代碼里，另外，對于twemproy單點、主從之間可以引入keepalived來消除單點和故障恢復。
