主從模式
Redis 單節點雖然有通過 RDB 和 AOF 持久化機制能將數據持久化到硬盤上，但數據是存儲在一台服務器上的，如果服務器出現硬盤故障等問題，會導致數據不可用，而且讀寫無法分離，讀寫都在同一台服務器上，請求量大時會出現 I/O 瓶頸。
為了避免單點故障 和 讀寫不分離，Redis 提供了復制（replication）功能實現 master 數據庫中的數據更新后，會自動將更新的數據同步到其他 slave 數據庫上。
Redis 主從結構特點：一個 master 可以有多個 slave 節點；slave 節點可以有 slave 節點，從節點是級聯結構。
主從模式優缺點
- 優點: 主從結構具有讀寫分離，提高效率、數據備份，提供多個副本等優點。
- 不足: 最大的不足就是主從模式不具備自動容錯和恢復功能，主節點故障，集群則無法進行工作，可用性比較低，從節點升主節點需要人工手動干預。
普通的主從模式，當主數據庫崩潰時，需要手動切換從數據庫成為主數據庫:
- 在從數據庫中使用
SLAVE NO ONE命令將從數據庫提升成主數據繼續服務。 - 啟動之前崩潰的主數據庫，然后使用
SLAVEOF命令將其設置成新的主數據庫的從數據庫，即可同步數據。
哨兵模式
第一種主從同步/復制的模式，當主服務器宕機后，需要手動把一台從服務器切換為主服務器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用，這時候就需要哨兵模式登場了。哨兵模式是從 Redis 的 2.6 版本開始提供的，但是當時這個版本的模式是不穩定的，直到 Redis 的 2.8 版本以后，這個哨兵模式才穩定下來。
哨兵模式核心還是主從復制，只不過在相對於主從模式在主節點宕機導致不可寫的情況下，多了一個競選機制：從所有的從節點競選出新的主節點。競選機制的實現，是依賴於在系統中啟動一個 sentinel 進程。
哨兵本身也有單點故障的問題，所以在一個一主多從的 Redis 系統中，可以使用多個哨兵進行監控，哨兵不僅會監控主數據庫和從數據庫，哨兵之間也會相互監控。每一個哨兵都是一個獨立的進程，作為進程，它會獨立運行。
哨兵模式的作用：
- 監控所有服務器是否正常運行：通過發送命令返回監控服務器的運行狀態，處理監控主服務器、從服務器外，哨兵之間也相互監控。
- 故障切換：當哨兵監測到 master 宕機，會自動將 slave 切換成 master，然后通過發布訂閱模式通知其他的從服務器，修改配置文件，讓它們切換 master。同時那台有問題的舊主也會變為新主的從，也就是說當舊的主即使恢復時，並不會恢復原來的主身份，而是作為新主的一個從。
哨兵實現原理:
哨兵在啟動進程時，會讀取配置文件的內容，通過如下的配置找出需要監控的主數據庫：
sentinel monitor master-name ip port quorum
# master-name 是主數據庫的名字
# ip 和 port 是當前主數據庫地址和端口號
# quorum 表示在執行故障切換操作前，需要多少哨兵節點同意。
這里之所以只需要連接主節點，是因為通過主節點的 info 命令，獲取從節點信息，從而和從節點也建立連接，同時也能通過主節點的 info 信息知道新增從節點的信息。
一個哨兵節點可以監控多個主節點，但是並不提倡這么做，因為當哨兵節點崩潰時，同時有多個集群切換會發生故障。哨兵啟動后，會與主數據庫建立兩條連接。
- 訂閱主數據庫
_sentinel_:hello頻道以獲取同樣監控該數據庫的哨兵節點信息 - 定期向主數據庫發送
info命令，獲取主數據庫本身的信息。
跟主數據庫建立連接后會定時執行以下三個操作：
- 每隔 10s 向 master 和 slave 發送 info 命令。作用是獲取當前數據庫信息，比如發現新增從節點時，會建立連接，並加入到監控列表中，當主從數據庫的角色發生變化進行信息更新。
- 每隔 2s 向主數據里和從數據庫的
_sentinel_:hello頻道發送自己的信息。作用是將自己的監控數據和哨兵分享。每個哨兵會訂閱數據庫的_sentinel:hello頻道，當其他哨兵收到消息后，會判斷該哨兵是不是新的哨兵，如果是則將其加入哨兵列表，並建立連接。 - 每隔 1s 向所有主從節點和所有哨兵節點發送 ping 命令，作用是監控節點是否存活。
主觀下線和客觀下線
哨兵節點發送 ping 命令時，當超過一定時間(down-after-millisecond)后，如果節點未回復，則哨兵認為主觀下線。主觀下線表示當前哨兵認為該節點已經下線，如果該節點為主數據庫，哨兵會進一步判斷是夠需要對其進行故障切換，這時候就要發送命令(SENTINEL is-master-down-by-addr)詢問其他哨兵節點是否認為該主節點是主觀下線，當達到指定數量(quorum)時，哨兵就會認為是客觀下線。
當主節點客觀下線時就需要進行主從切換，主從切換的步驟為：
- 選出領頭哨兵。
- 領頭哨兵所有的 slave 選出優先級最高的從數據庫。優先級可以通過 slave-priority 選項設置。
- 如果優先級相同，則從復制的命令偏移量越大（即復制同步數據越多，數據越新），越優先。
- 如果以上條件都一樣，則選擇 run ID 較小的從數據庫。
選出一個從數據庫后，哨兵發送 slave no one 命令升級為主數據庫，並發送slaveof 命令將其他從節點的主數據庫設置為新的主數據庫。
哨兵模式的優缺點
優點:哨兵模式是基於主從模式的，解決可主從模式中master故障不可以自動切換故障的問題。
缺點:
- 是一種中心化的集群實現方案：始終只有一個 Redis 主機來接收和處理寫請求，寫操作受單機瓶頸影響。
- 集群里所有節點保存的都是全量數據，浪費內存空間，沒有真正實現分布式存儲。數據量過大時，主從同步嚴重影響 master 的性能。
- Redis 主機宕機后，哨兵模式正在投票選舉的情況之外，因為投票選舉結束之前，誰也不知道主機和從機是誰，此時 Redis 也會開啟保護機制，禁止寫操作，直到選舉出了新的 Redis 主機。
主從模式或哨兵模式每個節點存儲的數據都是全量的數據，數據量過大時，就需要對存儲的數據進行分片后存儲到多個 Redis 實例上。此時就要用到 Redis Sharding 技術。
Redis 集群方案
客戶端分片
客戶端分片是把分片的邏輯放在 Redis 客戶端實現，（比如：jedis 已支持 Redis Sharding 功能，即 ShardedJedis），通過 Redis 客戶端預先定義好的路由規則(使用一致性哈希)，把對 Key 的訪問轉發到不同的 Redis 實例中，查詢數據時把返回結果匯集。
一致性哈希算法:
是分布式系統中常用的算法。比如，一個分布式的存儲系統，要將數據存儲到具體的節點上，如果采用普通的 hash 方法，將數據映射到具體的節點上，如 mod(key,d)，key 是數據的 key，d 是機器節點數，如果有一個機器加入或退出這個集群，則所有的數據映射都無效了。
一致性哈希算法解決了普通余數 Hash 算法伸縮性差的問題，可以保證在上線、下線服務器的情況下盡量有多的請求命中原來路由到的服務器。
一致性哈希算法實現方式：一致性 hash 算法，比如 MURMUR_HASH 散列算法、ketamahash 算法。比如 Jedis 的 Redis Sharding 實現，采用一致性哈希算法(consistent hashing)，將 key 和節點 name 同時 hashing，然后進行映射匹配，采用的算法是 MURMUR_HASH。
采用一致性哈希而不是采用簡單類似哈希求模映射的主要原因是當增加或減少節點時，不會產生由於重新匹配造成的 rehashing。一致性哈希只影響相鄰節點 key 分配，影響量小。
客戶端分片的優缺點：
優點：客戶端 sharding 技術使用 hash 一致性算法分片的好處是所有的邏輯都是可控的，不依賴於第三方分布式中間件。服務端的 Redis 實例彼此獨立，相互無關聯，每個 Redis 實例像單服務器一樣運行，非常容易線性擴展，系統的靈活性很強。開發人員清楚怎么實現分片、路由的規則，不用擔心踩坑。
缺點:
- 這是一種靜態的分片方案，需要增加或者減少 Redis 實例的數量，需要手工調整分片的程序。
- 運維成本比較高，集群的數據出了任何問題都需要運維人員和開發人員一起合作，減緩了解決問題的速度，增加了跨部門溝通的成本。
- 在不同的客戶端程序中，維護相同的路由分片邏輯成本巨大。比如：java 項目、PHP 項目里共用一套 Redis 集群，路由分片邏輯分別需要寫兩套一樣的邏輯，以后維護也是兩套。
客戶端分片有一個最大的問題就是，服務端 Redis 實例群拓撲結構有變化時，每個客戶端都需要更新調整。如果能把客戶端分片模塊單獨拎出來，形成一個單獨的模塊(中間件)，作為客戶端 和 服務端連接的橋梁就能解決這個問題了，此時代理分片就出現了。
代理分片
Redis 代理分片用得最多的就是 Twemproxy，由 Twitter 開源的 Redis 代理，其基本原理是：通過中間件的形式，Redis 客戶端把請求發送到 Twemproxy，Twemproxy 根據路由規則發送到正確的 Redis 實例，最后 Twemproxy 把結果匯集返回給客戶端。
Twemproxy 通過引入一個代理層，將多個 Redis 實例進行統一管理，使 Redis 客戶端只需要在 Twemproxy 上進行操作，而不需要關心后面有多少個 Redis 實例，從而實現了 Redis 集群。
Redis Cluster
Redis 的哨兵模式雖然已經可以實現高可用，讀寫分離 ，但是存在幾個方面的不足：
- 哨兵模式下每台 Redis 服務器都存儲相同的數據，很浪費內存空間；數據量太大，主從同步時嚴重影響了 master 性能。
- 哨兵模式是中心化的集群實現方案，每個從機和主機的耦合度很高，master 宕機到 slave 選舉 master 恢復期間服務不可用。
- 哨兵模式始終只有一個 Redis 主機來接收和處理寫請求，寫操作還是受單機瓶頸影響，沒有實現真正的分布式架構。
Redis 在 3.0 上加入了 Cluster 集群模式，實現了 Redis 的分布式存儲，也就是說每台 Redis 節點上存儲不同的數據。cluster 模式為了解決單機 Redis 容量有限的問題，將數據按一定的規則分配到多台機器，內存/QPS 不受限於單機，可受益於分布式集群高擴展性。Redis Cluster 是一種服務器 Sharding 技術(分片和路由都是在服務端實現)，采用多主多從，每一個分區都是由一個 Redis 主機和多個從機組成，片區和片區之間是相互平行的。Redis Cluster 集群采用了 P2P 的模式，完全去中心化。
官方推薦，集群部署至少要 3 台以上的 master 節點，最好使用 3 主 3 從六個節點的模式。Redis Cluster 集群具有如下幾個特點：
- 集群完全去中心化，采用多主多從；所有的 redis 節點彼此互聯(PING-PONG 機制)，內部使用二進制協議優化傳輸速度和帶寬。
- 客戶端與 Redis 節點直連，不需要中間代理層。客戶端不需要連接集群所有節點，連接集群中任何一個可用節點即可。
- 每一個分區都是由一個 Redis 主機和多個從機組成，分片和分片之間是相互平行的。
- 每一個 master 節點負責維護一部分槽，以及槽所映射的鍵值數據；集群中每個節點都有全量的槽信息，通過槽每個 node 都知道具體數據存儲到哪個 node 上。
Redis cluster 主要是針對海量數據 + 高並發 + 高可用的場景，海量數據，如果你的數據量很大，那么建議就用 Redis cluster，數據量不是很大時，使用 sentinel 就夠了。Redis cluster 的性能和高可用性均優於哨兵模式。
Redis Cluster 采用虛擬哈希槽分區而非一致性 hash 算法，預先分配一些卡槽，所有的鍵根據哈希函數映射到這些槽內，每一個分區內的 master 節點負責維護一部分槽以及槽所映射的鍵值數據。