[[339887]]

本文轉(zhuǎn)載自微信公眾號「小姐姐味道」，作者小姐姐養(yǎng)的狗。轉(zhuǎn)載本文請聯(lián)系小姐姐味道公眾號。    

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

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

單機模式

單機模式的redis非常簡單，你只需要啟動一個單一的節(jié)點就可以了，安裝過程不超過5分鐘。

通過redis-benchmark測試簡單的命令，QPS可達到10w以上，不得不說非常的讓人驚艷了。

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

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

主從模式

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

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

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

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

哨兵模式

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

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

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

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

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

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

集群模式

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

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é)點的要求也是比較多的，一般是采用6個節(jié)點，三主三從。當(dāng)節(jié)點超過10個，它的協(xié)調(diào)性就不那么靈活了，所以單集群的存儲和性能上限也很快能到達。

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

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

其他方案

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

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

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

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

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

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

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

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

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

作者簡介：小姐姐味道  (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。