一.主從模式（master/slaver）
Redis雖然讀取寫入的速度都特別快，但是也會產生讀壓力特別大的情況。爲了分擔讀壓力，Redis支持主從複製，Redis的主從結構可以採用一主多從或者級聯結構。
對主從模式的理解：
- 一個Master可以有多個Slaves
- 默認配置下，master節點可以進行讀和寫，slave節點只能進行讀操作，寫操作被禁止
- 不要修改配置讓slave節點支持寫操作，沒有意義，原因一，寫入的數據不會被同步到其他節點；原因二，當master節點修改同一條數據後，slave節點的數據會被覆蓋掉
- slave節點掛了不影響其他slave節點的讀和master節點的讀和寫，重新啓動後會將數據從master節點同步過來
- master節點掛了以後，不影響slave節點的讀，Redis將不再提供寫服務，master節點啓動後Redis將重新對外提供寫服務。
- master節點掛了以後，slave節點不會再選一個master
優點：
- 數據備份
- 負載均衡，所有客戶端都訪問一個節點肯定會影響Redis工作效率，有了主從以後，查詢操作就可以通過查詢從節點來完成寫入操作可以通過主節點來完成
- 做到讀寫分離（master 寫入，slave 讀取），提高服務器性能
缺點：
- master節點掛了以後，redis就不能對外提供寫服務了，因爲剩下的slave不能成爲master
這個缺點影響是很大的，尤其是對生產環境來說，是一刻都不能停止服務的，所以一般的生產壞境是不會單單隻有主從模式的。所以有了下面的sentinel模式。
二.哨兵(sentinel)
sentinel的中文含義是哨兵、守衛。也就是說既然主從模式中，當master節點掛了以後，slave節點不能主動選舉一個master節點出來，那麼我就安排一個或多個sentinel來做這件事，當sentinel發現master節點掛了以後，sentinel就會從slave中重新選舉一個master。
Sentinel（哨兵）是Redis的高可用性解決方案：由一個或多個Sentinel實例組成的Sentinel系統可以監視任意多個主服務器，以及這些主服務器屬下的所有從服務器，並在被監視的主服務器進入下線狀態時，自動將下線主服務器屬下的某個從服務器升級爲新的主服務器。
例如：
在service1 掉線後：
升級Server2 爲新的主服務器：
對sentinel的理解：
- sentinel模式是建立在主從模式的基礎上，如果只有一個Redis節點，sentinel就沒有任何意義
- 當master節點掛了以後，sentinel會在slave中選擇一個做爲master，並修改它們的配置文件，其他slave的配置文件也會被修改，比如slaveof屬性會指向新的master
- 當master節點重新啓動後，它將不再是master而是做爲slave接收新的master節點的同步數據
- sentinel因爲也是一個進程有掛掉的可能，所以sentinel也會啓動多個形成一個sentinel集羣
- 當主從模式配置密碼時，sentinel也會同步將配置信息修改到配置文件中，不許要擔心。
- 一個sentinel或sentinel集羣可以管理多個主從Redis。
- sentinel最好不要和Redis部署在同一臺機器，不然Redis的服務器掛了以後，sentinel也掛了
- sentinel監控的Redis集羣都會定義一個master名字，這個名字代表Redis集羣的master Redis。
優點
- Master 狀態監測
- 如果Master 異常，則會進行Master-slave 轉換，將其中一個Slave作爲Master，將之前的Master作爲Slave
缺點：
-
如果是從節點下線了，sentinel是不會對其進行故障轉移的，連接從節點的客戶端也無法獲取到新的可用從節點
-
無法實現動態擴容
當使用sentinel模式的時候，客戶端就不要直接連接Redis，而是連接sentinel的ip和port，由sentinel來提供具體的可提供服務的Redis實現，這樣當master節點掛掉以後，sentinel就會感知並將新的master節點提供給使用者。
sentinel模式基本可以滿足一般生產的需求，具備高可用性。但是當數據量過大到一臺服務器存放不下的情況時，主從模式或sentinel模式就不能滿足需求了，這個時候需要對存儲的數據進行分片，將數據存儲到多個Redis實例中，就是下面要講的。
三.Cluster
3.1 cluster的出現是爲了解決單機Redis容量有限的問題，將Redis的數據根據一定的規則分配到多臺機器。cluster可以說是sentinel和主從模式的結合體
3.2 先來一張redis 集羣的架構圖：
在這個圖中，每一個藍色的圈都代表着一個redis的服務器節點。它們任何兩個節點之間都是相互連通的。客戶端可以與任何一個節點相連接，然後就可以訪問集羣中的任何一個節點。對其進行存取和其他操作。
一般集羣建議搭建三主三從架構，三主提供服務，三從提供備份功能。
每一個節點都存有這個集羣所有主節點以及從節點的信息。
3.3 cluster工作原理圖：
- 它們之間通過互相的ping-pong判斷是否節點可以連接上。
- 如果有一半以上的節點去ping一個節點的時候沒有迴應，集羣就認爲這個節點宕機了，然後去連接它的備用節點。
- 如果某個節點和所有從節點全部掛掉，我們集羣就進入faill狀態。還有就是如果有一半以上的主節點宕機，那麼我們集羣同樣進入fail狀態。
- 這就是我們的redis的投票機制
3.4 其結構特點：
- 所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬。
- 節點的fail是通過集羣中超過半數的節點檢測失效時才生效。
- 客戶端與redis節點直連,不需要中間proxy層。客戶端不需要連接集羣所有節點,連接集羣中任何一個可用節點即可。
- **redis-cluster把所有的redis節點映射到[0-16383]slot上（不一定是平均分配）,**當需要在 Redis 集羣中放置一個 key-value 時，根據 CRC16(key) mod 16384的值，決定將一個key放到redis節點裏。
這種模式適合數據量巨大的緩存要求，當數據量不是很大使用sentinel即可。