前段時(shí)間搞了搞Redis集群，想用做推薦系統(tǒng)的線(xiàn)上存儲(chǔ)，說(shuō)來(lái)挺有趣，這邊基礎(chǔ)架構(gòu)不太完善，因此需要我們做推薦系統(tǒng)的自己來(lái)搭這個(gè)存儲(chǔ)環(huán)境，就自己折騰了折騰。公司所給機(jī)器的單機(jī)性能其實(shí)挺給力，已經(jīng)可以滿(mǎn)足目前的業(yè)務(wù)需求，想做redis集群主要有以下幾點(diǎn)考慮：

    1、擴(kuò)展性，scale-out，以后數(shù)據(jù)量變得很大之后，不至于推到重來(lái)，redis雖然可以開(kāi)啟虛擬內(nèi)存功能，單機(jī)也能提供超過(guò)物理內(nèi)存上限的容量，但頻繁在內(nèi)存和硬盤(pán)間swap頁(yè)會(huì)大大降低其性能，有點(diǎn)兒違背redis的設(shè)計(jì)初衷。

    2、redis是一個(gè)單線(xiàn)程io復(fù)用的結(jié)構(gòu)，無(wú)法有效利用服務(wù)器的多核結(jié)構(gòu)，如果能在一臺(tái)多核機(jī)器起多個(gè)redis進(jìn)程，共同提供服務(wù)，效率會(huì)更高一些。

    3、主從，數(shù)據(jù)備份和容災(zāi)。。

因此計(jì)劃做的redis集群希望可以實(shí)現(xiàn)以下功能：

    1、data sharding，支持?jǐn)?shù)據(jù)切片。

    2、主從備份，主節(jié)點(diǎn)寫(xiě)數(shù)據(jù)，主和從都提供讀請(qǐng)求服務(wù)，并且支持主從自動(dòng)切換。

    3、讀請(qǐng)求做負(fù)載均衡。

    4、更好地，支持節(jié)點(diǎn)failover，數(shù)據(jù)自動(dòng)遷移。

下面是前后經(jīng)歷的一個(gè)過(guò)程：

【第一步】嘗試官方方案

   肯定想去查看一下redis的官方集群方案，但是很遺憾，官方對(duì)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目前還是不敢用，在官方目前的版本上做提前開(kāi)發(fā)又沒(méi)有資源和時(shí)間，因此就放棄了。

【第二步】初步設(shè)想的方案

   舍棄了官方的方案后，就想能不能自己搭一個(gè)，當(dāng)時(shí)初步的想法是：用lvs做讀請(qǐng)求的負(fù)載均衡，在客戶(hù)端代碼里自己寫(xiě)一個(gè)一致性hash算法做數(shù)據(jù)切片，配置redis主從，并且配置keepalived做主從自動(dòng)切換。這個(gè)方案應(yīng)該可以施行的，但當(dāng)時(shí)自己遇到一些細(xì)節(jié)方面的問(wèn)題，就在stackoverflow上問(wèn)了一下，問(wèn)題如下：

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:)

有個(gè)網(wǎng)友給了兩個(gè)建議：

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)友的兩個(gè)建議挺啟發(fā)的，我在看redis的官方doc的時(shí)候，對(duì)twemproxy有一些印象，但當(dāng)時(shí)沒(méi)有太在意，至于后者用redis sentinel做master failover，redis sentinel也是一個(gè)redis正在開(kāi)發(fā)中的模塊，我不太敢用。

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

1、自己在寫(xiě)客戶(hù)端data sharding和均衡服務(wù)的時(shí)候，發(fā)現(xiàn)實(shí)際需要考慮的問(wèn)題比開(kāi)始想的要復(fù)雜一些，如果寫(xiě)完，其實(shí)相當(dāng)于將twemproxy的功能做了一遍，造輪子的事情還是少干。

2、功能做得有些冗余，一次讀請(qǐng)求要經(jīng)過(guò)客戶(hù)端的sharding、然后還有經(jīng)過(guò)lvs再到實(shí)際的服務(wù)器，不做優(yōu)化的話(huà)，會(huì)增加不少延遲。

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

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

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

上面的結(jié)構(gòu)，將讀操作的負(fù)載均衡放到了客戶(hù)端代碼來(lái)做，寫(xiě)操作控制也在客戶(hù)端層的代碼里，另外，對(duì)于twemproy單點(diǎn)、主從之間可以引入keepalived來(lái)消除單點(diǎn)和故障恢復(fù)。

最新評(píng)論