單機模式的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集群模式有哪些及有什麼優點的詳細內容。更多資訊請關注PHP中文網其他相關文章！
