Redis集群方案這么多，我該用哪種呢？

文章轉(zhuǎn)載自公眾號(hào)：小姐姐味道

redis速度快，可靠性高，是互聯(lián)網(wǎng)公司的標(biāo)配。它有單機(jī)、主從、哨兵、Cluster等四種部署模式。

下面，僅從部署模式上，來說明一下它們的優(yōu)缺點(diǎn)。

單機(jī)模式

單機(jī)模式的redis非常簡(jiǎn)單，你只需要啟動(dòng)一個(gè)單一的節(jié)點(diǎn)就可以了，安裝過程不超過5分鐘。

通過redis-benchmark測(cè)試簡(jiǎn)單的命令，QPS可達(dá)到10w以上，不得不說非常的讓人驚艷了。

單機(jī)模式的問題也非常明顯。缺乏高可用的機(jī)制！

假如redis進(jìn)程死了，進(jìn)程就只能夠穿透到底層的數(shù)據(jù)庫(kù)中，對(duì)業(yè)務(wù)來說非常的危險(xiǎn)。如果你把redis當(dāng)作數(shù)據(jù)存儲(chǔ)來用，情況會(huì)更加嚴(yán)重，甚至?xí)G失數(shù)據(jù)。

主從模式

所以最基本的redis部署，都會(huì)增加一個(gè)或者多個(gè)slave（現(xiàn)在叫replication）。

當(dāng)主redis發(fā)生問題的時(shí)候，能夠選取一個(gè)slave頂上去。

非常可惜的是，這種模式和傳統(tǒng)的MySQL主從一樣，切換起來比較蛋疼，需要借助外部的工具，比如keepalived等輔助進(jìn)行切換，部署和維護(hù)難度直接飆升。

keepalived是一個(gè)基于VRRP協(xié)議來實(shí)現(xiàn)的高可用方案，通過 IP 漂移實(shí)現(xiàn)高可用。從描述上就可以看出它需要網(wǎng)絡(luò)管理員的參與，和我們輕量級(jí)的redis背道而馳。

哨兵模式

哨兵模式就是使用額外的進(jìn)程來替換keepalived的功能，對(duì)redis進(jìn)程的存活性進(jìn)行判斷。在哨兵模式下，一旦主節(jié)點(diǎn)宕機(jī)，從節(jié)點(diǎn)作為主節(jié)點(diǎn)的備份可以隨時(shí)頂上來。

但哨兵模式一個(gè)最大的問題，就是哨兵的數(shù)量太多，至少需要3個(gè)節(jié)點(diǎn)。

對(duì)redis進(jìn)行仲裁的時(shí)候，需要n/2+1個(gè)節(jié)點(diǎn)投票才能確認(rèn)，這也是分布式系統(tǒng)的一般做法 (quorum)。和Zookeeper類似，哨兵節(jié)點(diǎn)做成奇數(shù)個(gè)，是非常合適的。

哨兵模式可以通過sentinel monitor配置同時(shí)檢測(cè)多套集群，在集群數(shù)量適中的時(shí)候，還是比較好用的。

但哨兵模式有很多隱藏的坑，比如哨兵的啟動(dòng)，必須在master存活的情況下才能正常運(yùn)行；另外，如果你的redis配置文件中使用RENAME屏蔽了一些危險(xiǎn)命令時(shí)，哨兵也不能夠啟動(dòng)。

客戶端在連接redis的時(shí)候，就不能再直接連接redis的實(shí)例，它需要從哨兵轉(zhuǎn)上一圈，以便獲取一些變更信息。

集群模式

《與親生的Redis Cluster，來一次靈魂交流》

集群模式可以說是這里面最優(yōu)雅的方式了。你只需要部署多個(gè)對(duì)等的redis節(jié)點(diǎn)，然后使用客戶端命令進(jìn)行組群就可以了。

ip=192.169.0.23
./bin/redis-cli --cluster create  $ip:7001 $ip:7002 $ip:7003 $ip:7004 $ip:7005 $ip:7006 --cluster-replicas 1

它對(duì)節(jié)點(diǎn)的要求也是比較多的，一般是采用6個(gè)節(jié)點(diǎn)，三主三從。當(dāng)節(jié)點(diǎn)超過10個(gè)，它的協(xié)調(diào)性就不那么靈活了，所以單集群的存儲(chǔ)和性能上限也很快能到達(dá)。

集群模式的一些缺點(diǎn)很隱蔽。它的服務(wù)端節(jié)點(diǎn)倒是非常穩(wěn)定了，但有些命令會(huì)嚴(yán)重影響性能。比如mget,pipeline等。它們需要把請(qǐng)求分散到多個(gè)節(jié)點(diǎn)執(zhí)行、再聚合。節(jié)點(diǎn)越多，性能越低。

在下面這篇文章中，我們?cè)敿?xì)的描述了一些比較通用的redis使用規(guī)范，有些就是為了規(guī)避cluster模式引起的一些問題。

《Redis規(guī)范，這可能是最中肯的了》

其他方案

可以看到redis的這些集群模式，都不是完美的。應(yīng)對(duì)小型的服務(wù)可能沒有問題，如果是大型的集群和服務(wù)，這些部署方式對(duì)運(yùn)維上，使用上來說，都有非常大的挑戰(zhàn)。

使用客戶端hash的方法，是大型互聯(lián)網(wǎng)中常用的方式。參考下面的文章，現(xiàn)實(shí)中的路由規(guī)則，可能會(huì)相當(dāng)復(fù)雜，但請(qǐng)求總能夠精確的落在某個(gè)小的群組上面。

《現(xiàn)實(shí)中的路由規(guī)則，可能比你想象中復(fù)雜的多》

對(duì)于管理大型集群來說，我倒是傾向于主從模式，然后使用Java或者其他語言開發(fā)一個(gè)可以集中管控的哨兵系統(tǒng)，對(duì)上千個(gè)集群進(jìn)行管理。

由于Redis是文本協(xié)議，協(xié)議非常簡(jiǎn)單，Netty甚至直接內(nèi)置了它的解析器，所以開發(fā)這么一個(gè)哨兵系統(tǒng)是非常簡(jiǎn)單的。

一些中間層代理軟件，也能分擔(dān)一些路由工作，但由于是中間層，涉及到一層網(wǎng)絡(luò)轉(zhuǎn)發(fā)，對(duì)Redis這種以速度取勝的服務(wù)來說，就不是很實(shí)用。

變種有更多，比如下面這篇文章，使用的是Redis協(xié)議，但后端存儲(chǔ)卻是MySQL，所以你的命令會(huì)是被閹割的。

《架構(gòu)秘笈：移花接木。使用mysql模擬redis》

從上面的描述中我們就可以看出，Redis 能用是一回事，用好是另一回事。

你可能花了一天時(shí)間搭建了一個(gè)單節(jié)點(diǎn)的 Redis ；我可能花了一周時(shí)間寫了個(gè) Java 版的哨兵，還有很多BUG。這兩者在不懂技術(shù)的領(lǐng)導(dǎo)眼里，是沒有區(qū)別的--它們都滿足了業(yè)務(wù)的需求。但也不必過分計(jì)較，現(xiàn)實(shí)一般都比較殘酷，計(jì)算機(jī)系統(tǒng)也沒有想象中的那么穩(wěn)定，墨菲定律總有一個(gè)時(shí)間會(huì)教會(huì)他們做人。

當(dāng)然，領(lǐng)導(dǎo)每天都在教我做人。

以上就是W3Cschool編程獅關(guān)于Redis集群方案這么多，我該用哪種呢？的相關(guān)介紹了，希望對(duì)大家有所幫助。