redis主要有幾種模式：
- 主從模式
- 哨兵模式
- 集羣模式
1、 主從模式
基於主從複製的特性，一般有一個主節點，多個從節點，默認是我們可以從主節點寫，寫入的數據會自動備份到從節點，可以從從節點讀取數據。
這樣做的好處是，解決單臺redis的讀請求的瓶頸，可以橫向擴容讀請求，相當於做到了讀請求的負載均衡。
從節點也是可以支持寫的，但是不會複製到其他節點，所以我們基本不這麼幹。
這樣做的缺陷是什麼：
1.redis的主節點很重要，掛了就沒有了，一掛整個集羣都有問題。
2.redis寫請求很多怎麼辦？我還不想用消息隊列，就想在redis上實現（實際上寫請求很多的時候可以適當用消息隊列）
2、 哨兵模式
哨兵模式，和主從模式不是互斥的，反而他們一般是同時存在的，爲了提高redis的高可用性存在的。如果是單獨的主從架構，那麼主節點掛了，問題就很大了。一般服務器宕機，停電或者硬件有問題，主節點可能會有問題。有問題的時候，哨兵模式能夠幫我們快速地糾正。
哨兵一般是依靠主從模式的，也就是在主從結構上，加上了哨兵模式，一旦主節點宕機，就可以通過幾個哨兵選舉，產生新的主節點，自動調整過來。哨兵本質上也是redis，但是它不做數據存儲，只負責監控，通知，故障轉移等工作，一般部署的端口和redis是不一樣的，可以選擇部署在同一個機器上。
哨兵主要有以下功能：
- 監控：不斷檢測主從服務器是否正常在工作中
- 通知：可以通過api來通知管理員或者其他應用程序，告知我們redis出現了問題。
- 自動故障轉移：如果sentinel系統判斷出master down掉了，就是不可用了，就會執行故障轉移過程，通過投票選舉把slave節點提升成爲master節點，其他slave節點成爲新master節點的從節點。
- 提供配置：客戶端連接sentinels，查詢主節點的時候，提供最新的master的地址。
這樣一來算是很大程度上解決了單機的高可用問題。
3、 Redis集羣（cluster）模式
哨兵只是解決了高可用的問題，但是上面的主從結構還有一個問題，就是寫請求只能一臺機器，那麼如果寫請求的併發很大呢？這樣的結構明顯是不能滿足需求的，所以就有了redis cluster結構。
redis cluster可以有很多個mster node，而且每一個master都可以多個slave node。這樣的結構可以做讀寫分離，但是一般不這麼幹，一般只在master上讀，在master上寫，slave只是作爲數據備份。可以做讀寫分離，但是一般不這麼做而已。，Jedis對cluster的讀寫分離支持不是很好。
這樣也可以滿足高可用，因爲每個master都有salve節點，那麼如果mater掛掉，redis cluster這套機制，就會自動將某個slave切換成master。
我們只要基於redis cluster去搭建redis集羣即可，不需要手工去搭建replication複製+主從架構+讀寫分離+哨兵集羣+高可用。cluster已經集成了這些能力。
至於能不能讀寫都在同一個機器上呢？如何保障呢？
其實這就是redis的hash算法啦，可以做到的，這就是redis的hash槽。Redis 集羣有16384個哈希槽,每個key通過CRC16校驗後對16384取模來決定放置哪個槽。每個master節點會負責一部分hash槽，比如三個節點A,B,C。
- A持有0 到 5500號哈希槽
- B持有5501 到 11000 號哈希槽
- C持有11001 到 16384號哈希槽
每個key就會hash後，根據hash值打到對應的機器上，如果刪除節點A，那麼A的槽就會移動到B，C上，如果添加一個D的話，那麼會把A,B，C的部分槽移動到D上面，這樣拓展就比較方便了。
4、選擇redis cluster 還是 replication + sentinal？
1.如果你的數據量很少，主要是承載高併發高性能的場景，比如你的緩存一般就幾個G，單機足夠了。
-
replication，一個mater，多個slave，要幾個slave跟你的要求的讀吞吐量有關係，然後自己搭建一個sentinal集羣，去保證redis主從架構的高可用性，就可以了，業務類型主要是讀請求比較大，但是寫請求比較少。
-
redis cluster，主要是針對海量數據+高併發+高可用的場景，海量數據，如果你的數據量很大，或者讀寫請求都較大，那麼建議就用redis cluster。