好慌，Redis這麼多叢集方案，要用哪種？
redis速度快，可靠性高，是網際網路公司的標配。它有單機、主從、哨兵、Cluster等四種部署模式。
下面，僅從部署模式上，來說明一下它們的優缺點。
單機模式
福利 福利 福利 免費領取Java架構技能地圖 注意了是免費送
免費領取 要的+V 領取
單機模式的redis非常簡單，你只需要啟動一個單一的節點就可以了，安裝過程不超過5分鐘。
通過redis-benchmark測試簡單的命令，QPS可達到10w以上，不得不說非常的讓人驚豔了。
單機模式的問題也非常明顯。缺乏高可用的機制！
假如redis程序死了，程序就只能夠穿透到底層的資料庫中，對業務來說非常的危險。如果你把redis當作資料儲存來用，情況會更加嚴重，甚至會丟失資料。
主從模式
所以最基本的redis部署，都會增加一個或者多個slave（現在叫replication）。
當主redis發生問題的時候，能夠選取一個slave頂上去。
非常可惜的是，這種模式和傳統的MySQL主從一樣，切換起來比較蛋疼，需要藉助外部的工具，比如keepalived等輔助進行切換，部署和維護難度直接飆升。
keepalived 是一個基於VRRP協議來實現的高可用方案，通過IP漂移實現高可用。從描述上就可以看出它需要網路管理員的參與，和我們輕量級的redis背道而馳。
哨兵模式
哨兵模式就是使用額外的程序來替換keepalived的功能，對redis程序的存活性進行判斷。在哨兵模式下，一旦主節點宕機，從節點作為主節點的備份可以隨時頂上來。
但哨兵模式一個最大的問題，就是哨兵的數量太多，至少需要3個節點。
對redis進行仲裁的時候，需要n/2+1個節點投票才能確認，這也是分散式系統的一般做法 (quorum)。和Zookeeper類似，哨兵節點做成奇數個，是非常合適的。
哨兵模式可以通過sentinel monitor配置同時檢測多套叢集，在叢集數量適中的時候，還是比較好用的。
但哨兵模式有很多隱藏的坑，比如哨兵的啟動，必須在master存活的情況下才能正常執行；另外，如果你的redis配置檔案中使用RENAME遮蔽了一些危險命令時，哨兵也不能夠啟動。
客戶端在連線redis的時候，就不能再直接連線redis的例項，它需要從哨兵轉上一圈，以便獲取一些變更資訊。
叢集模式
叢集模式可以說是這裡面最優雅的方式了。你只需要部署多個對等的redis節點，然後使用客戶端命令進行組群就可以了。
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
複製程式碼它對節點的要求也是比較多的，一般是採用6個節點，三主三從。當節點超過10個，它的協調性就不那麼靈活了，所以單叢集的儲存和效能上限也很快能到達。
叢集模式的一些缺點很隱蔽。它的服務端節點倒是非常穩定了，但有些命令會嚴重影響效能。比如mget,pipeline等。它們需要把請求分散到多個節點執行、再聚合。節點越多，效能越低。
在下面這篇文章中，我們詳細的描述了一些比較通用的redis使用規範，有些就是為了規避cluster模式引起的一些問題。
其他方案
可以看到redis的這些叢集模式，都不是完美的。應對小型的服務可能沒有問題，如果是大型的叢集和服務，這些部署方式對運維上，使用上來說，都有非常大的挑戰。
使用客戶端hash的方法，是大型網際網路中常用的方式。參考下面的文章，現實中的路由規則，可能會相當複雜，但請求總能夠精確的落在某個小的群組上面。
對於管理大型叢集來說，我倒是傾向於主從模式，然後使用Java或者其他語言開發一個可以集中管控的哨兵系統，對上千個叢集進行管理。
由於Redis是文字協議，協議非常簡單，Netty甚至直接內建了它的解析器，所以開發這麼一個哨兵系統是非常簡單的。
一些中間層代理軟體，也能分擔一些路由工作，但由於是中間層，涉及到一層網路轉發，對Redis這種以速度取勝的服務來說，就不是很實用。
變種有更多，比如下面這篇文章，使用的是Redis協議，但後端儲存卻是MySQL，所以你的命令會是被閹割的。
從上面的描述中我們就可以看出，Redis能用是一回事，用好是另一回事。
你可能花了一天時間搭建了一個單節點的Redis；我可能花了一週時間寫了個Java版的哨兵，還有很多BUG。這兩者在不懂技術的領導眼裡，是沒有區別的--它們都滿足了業務的需求。但也不必過分計較，現實一般都比較殘酷，計算機系統也沒有想象中的那麼穩定，墨菲定律總有一個時間會教會他們做人。