文章轉(zhuǎn)載自公眾號：小姐姐味道
redis速度快，可靠性高，是互聯(lián)網(wǎng)公司的標配。它有單機、主從、哨兵、Cluster等四種部署模式。
下面，僅從部署模式上，來說明一下它們的優(yōu)缺點。
單機模式
單機模式的redis非常簡單，你只需要啟動一個單一的節(jié)點就可以了，安裝過程不超過5分鐘。
通過redis-benchmark測試簡單的命令，QPS可達到10w以上，不得不說非常的讓人驚艷了。
單機模式的問題也非常明顯。缺乏高可用的機制！
假如redis進程死了，進程就只能夠穿透到底層的數(shù)據(jù)庫中，對業(yè)務(wù)來說非常的危險。如果你把redis當作數(shù)據(jù)存儲來用，情況會更加嚴重，甚至會丟失數(shù)據(jù)。
主從模式
所以最基本的redis部署，都會增加一個或者多個slave（現(xiàn)在叫replication）。
當主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é)點，三主三從。當節(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ī)則，可能會相當復雜，但請求總能夠精確的落在某個小的群組上面。
《現(xiàn)實中的路由規(guī)則，可能比你想象中復雜的多》
對于管理大型集群來說，我倒是傾向于主從模式，然后使用Java或者其他語言開發(fā)一個可以集中管控的哨兵系統(tǒng)，對上千個集群進行管理。
由于Redis是文本協(xié)議，協(xié)議非常簡單，Netty甚至直接內(nèi)置了它的解析器，所以開發(fā)這么一個哨兵系統(tǒng)是非常簡單的。
一些中間層代理軟件，也能分擔一些路由工作，但由于是中間層，涉及到一層網(wǎng)絡(luò)轉(zhuǎn)發(fā)，對Redis這種以速度取勝的服務(wù)來說，就不是很實用。
變種有更多，比如下面這篇文章，使用的是Redis協(xié)議，但后端存儲卻是MySQL，所以你的命令會是被閹割的。
《架構(gòu)秘笈：移花接木。使用mysql模擬redis》
從上面的描述中我們就可以看出，Redis 能用是一回事，用好是另一回事。
你可能花了一天時間搭建了一個單節(jié)點的 Redis ；我可能花了一周時間寫了個 Java 版的哨兵，還有很多BUG。這兩者在不懂技術(shù)的領(lǐng)導眼里，是沒有區(qū)別的--它們都滿足了業(yè)務(wù)的需求。但也不必過分計較，現(xiàn)實一般都比較殘酷，計算機系統(tǒng)也沒有想象中的那么穩(wěn)定，墨菲定律總有一個時間會教會他們做人。
當然，領(lǐng)導每天都在教我做人。
以上就是W3Cschool編程獅關(guān)于Redis集群方案這么多，我該用哪種呢？的相關(guān)介紹了，希望對大家有所幫助。
