文章轉(zhuǎn)載自公眾號:小姐姐味道
redis速度快,可靠性高,是互聯(lián)網(wǎng)公司的標(biāo)配。它有單機(jī)、主從、哨兵、Cluster等四種部署模式。
下面,僅從部署模式上,來說明一下它們的優(yōu)缺點(diǎn)。
單機(jī)模式
單機(jī)模式的redis
非常簡單,你只需要啟動一個單一的節(jié)點(diǎn)就可以了,安裝過程不超過5分鐘。
通過redis-benchmark
測試簡單的命令,QPS
可達(dá)到10w
以上,不得不說非常的讓人驚艷了。
單機(jī)模式的問題也非常明顯。缺乏高可用的機(jī)制!
假如redis
進(jìn)程死了,進(jìn)程就只能夠穿透到底層的數(shù)據(jù)庫中,對業(yè)務(wù)來說非常的危險。如果你把redis
當(dāng)作數(shù)據(jù)存儲來用,情況會更加嚴(yán)重,甚至?xí)G失數(shù)據(jù)。
主從模式
所以最基本的redis
部署,都會增加一個或者多個slave
(現(xiàn)在叫replication
)。
當(dāng)主redis
發(fā)生問題的時候,能夠選取一個slave
頂上去。
非??上У氖?,這種模式和傳統(tǒng)的MySQL
主從一樣,切換起來比較蛋疼,需要借助外部的工具,比如keepalived
等輔助進(jìn)行切換,部署和維護(hù)難度直接飆升。
keepalived
是一個基于VRRP
協(xié)議來實(shí)現(xiàn)的高可用方案,通過 IP 漂移實(shí)現(xiàn)高可用。從描述上就可以看出它需要網(wǎng)絡(luò)管理員的參與,和我們輕量級的redis
背道而馳。
哨兵模式
哨兵模式就是使用額外的進(jìn)程來替換keepalived
的功能,對redis
進(jìn)程的存活性進(jìn)行判斷。在哨兵模式下,一旦主節(jié)點(diǎn)宕機(jī),從節(jié)點(diǎn)作為主節(jié)點(diǎn)的備份可以隨時頂上來。
但哨兵模式一個最大的問題,就是哨兵的數(shù)量太多,至少需要3個節(jié)點(diǎn)。
對redis
進(jìn)行仲裁的時候,需要n/2+1
個節(jié)點(diǎn)投票才能確認(rèn),這也是分布式系統(tǒng)的一般做法 (quorum)。和Zookeeper
類似,哨兵節(jié)點(diǎn)做成奇數(shù)個,是非常合適的。
哨兵模式可以通過sentinel monitor
配置同時檢測多套集群,在集群數(shù)量適中的時候,還是比較好用的。
但哨兵模式有很多隱藏的坑,比如哨兵的啟動,必須在master
存活的情況下才能正常運(yùn)行;另外,如果你的redis
配置文件中使用RENAME
屏蔽了一些危險命令時,哨兵也不能夠啟動。
客戶端在連接redis
的時候,就不能再直接連接redis
的實(shí)例,它需要從哨兵轉(zhuǎn)上一圈,以便獲取一些變更信息。
集群模式
集群模式可以說是這里面最優(yōu)雅的方式了。你只需要部署多個對等的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
它對節(jié)點(diǎn)的要求也是比較多的,一般是采用6個節(jié)點(diǎn),三主三從。當(dāng)節(jié)點(diǎn)超過10個,它的協(xié)調(diào)性就不那么靈活了,所以單集群的存儲和性能上限也很快能到達(dá)。
集群模式的一些缺點(diǎn)很隱蔽。它的服務(wù)端節(jié)點(diǎn)倒是非常穩(wěn)定了,但有些命令會嚴(yán)重影響性能。比如mget
,pipeline
等。它們需要把請求分散到多個節(jié)點(diǎn)執(zhí)行、再聚合。節(jié)點(diǎn)越多,性能越低。
在下面這篇文章中,我們詳細(xì)的描述了一些比較通用的redis
使用規(guī)范,有些就是為了規(guī)避cluster
模式引起的一些問題。
其他方案
可以看到redis
的這些集群模式,都不是完美的。應(yīng)對小型的服務(wù)可能沒有問題,如果是大型的集群和服務(wù),這些部署方式對運(yùn)維上,使用上來說,都有非常大的挑戰(zhàn)。
使用客戶端hash
的方法,是大型互聯(lián)網(wǎng)中常用的方式。參考下面的文章,現(xiàn)實(shí)中的路由規(guī)則,可能會相當(dāng)復(fù)雜,但請求總能夠精確的落在某個小的群組上面。
《現(xiàn)實(shí)中的路由規(guī)則,可能比你想象中復(fù)雜的多》
對于管理大型集群來說,我倒是傾向于主從模式,然后使用Java
或者其他語言開發(fā)一個可以集中管控的哨兵系統(tǒng),對上千個集群進(jìn)行管理。
由于Redis
是文本協(xié)議,協(xié)議非常簡單,Netty
甚至直接內(nèi)置了它的解析器,所以開發(fā)這么一個哨兵系統(tǒng)是非常簡單的。
一些中間層代理軟件,也能分擔(dān)一些路由工作,但由于是中間層,涉及到一層網(wǎng)絡(luò)轉(zhuǎn)發(fā),對Redis
這種以速度取勝的服務(wù)來說,就不是很實(shí)用。
變種有更多,比如下面這篇文章,使用的是Redis
協(xié)議,但后端存儲卻是MySQL
,所以你的命令會是被閹割的。
《架構(gòu)秘笈:移花接木。使用mysql模擬redis》
從上面的描述中我們就可以看出,Redis 能用是一回事,用好是另一回事。
你可能花了一天時間搭建了一個單節(jié)點(diǎn)的 Redis ;我可能花了一周時間寫了個 Java 版的哨兵,還有很多BUG
。這兩者在不懂技術(shù)的領(lǐng)導(dǎo)眼里,是沒有區(qū)別的--它們都滿足了業(yè)務(wù)的需求。但也不必過分計(jì)較,現(xiàn)實(shí)一般都比較殘酷,計(jì)算機(jī)系統(tǒng)也沒有想象中的那么穩(wěn)定,墨菲定律總有一個時間會教會他們做人。
當(dāng)然,領(lǐng)導(dǎo)每天都在教我做人。
以上就是W3Cschool編程獅
關(guān)于Redis集群方案這么多,我該用哪種呢?的相關(guān)介紹了,希望對大家有所幫助。