一.Redis支持的集群方案
- 主從復制模式
- Sentinel(哨兵)模式
- Cluster集群模式
1.1 主從復制模式
1.1.1 主從復制說明
Redis通過配置持久化，可以保證能夠在服務器重啟的情況下也不會丟失數據，但數據是存儲到一台服務器上的，如果這台服務器出現故障，也會導致數據的丟失。
為了避免出現單點故障的問題，這里是將數據庫復制多個副本部署到不同的服務器上，這樣即使有一台服務器出現故障，其它服務器仍然可以繼續提供服務。
這里引入了Redis的復制(replication)功能，來實現當一台數據庫的數據更新后，自動將更新的數據同步到其它數據庫上。在這種場景下，數據庫分為兩類，一類是主數據庫(master)，一類是從數據庫(slave)。主數據庫可以進行讀寫操作，當寫操作導致數據變化時會自動將數據同步給從數據庫。從數據庫一般是只讀的，接收主數據庫同步過來的數據。一個主數據庫可以擁有多個從數據庫，而一個從數據庫只能擁有一個主數據庫。
1.1.2 架構圖
1.1.3 原理
1）從數據庫啟動成功后，連接主數據庫，發送 SYNC 命令；
2）主數據庫接收到 SYNC 命令后，開始執行 BGSAVE 命令生成 RDB 文件並使用緩沖區記錄此后執行的所有寫命令；
3）主數據庫 BGSAVE 執行完后，向所有從數據庫發送快照文件，並在發送期間繼續記錄被執行的寫命令；
4）從數據庫收到快照文件后丟棄所有舊數據，載入收到的快照；
5）主數據庫快照發送完畢后開始向從數據庫發送緩沖區中的寫命令；
6）從數據庫完成對快照的載入，開始接收命令請求，並執行來自主數據庫緩沖區的寫命令；（從數據庫初始化完成）
7）主數據庫每執行一個寫命令就會向從數據庫發送相同的寫命令，從數據庫接收並執行收到的寫命令（從數據庫初始化完成后的操作）
8）出現斷開重連后，2.8之后的版本會將斷線期間的命令傳給重數據庫，增量復制。
9）主從剛剛連接的時候，進行全量同步；全同步結束后，進行增量同步。當然，如果有需要，slave 在任何時候都可以發起全量同步。Redis 的策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。
1.1.4 主從復制優缺點
優點：
- 支持主從復制，主服務器會自動將數據同步到從服務器，可以進行讀寫分離；
- 為了分載 Master 的讀操作壓力，Slave 服務器可以為客戶端提供只讀操作的服務，寫服務仍然必須由Master來完成；
- Slave 同樣可以接受其它 Slaves 的連接和同步請求，這樣可以有效的分載 Master 的同步壓力；
- Master Server 是以非阻塞的方式為 Slaves 提供服務。所以在 Master-Slave 同步期間，客戶端仍然可以提交查詢或修改請求；
- Slave Server 同樣是以非阻塞的方式完成數據同步。在同步期間，如果有客戶端提交查詢請求，Redis則返回同步之前的數據；
缺點： - Redis不具備自動容錯和恢復功能，主機從機的宕機都會導致前端部分讀寫請求失敗，需要等待機器重啟或者手動切換前端的IP才能恢復（也就是要人工介入）；
- 主機宕機，宕機前有部分數據未能及時同步到從機，切換IP后還會引入數據不一致的問題，降低了系統的可用性；
- 如果多個Slave斷線了，需要重啟的時候，盡量不要在同一時間段進行重啟。因為只要Slave啟動，就會發送sync請求和主機全量同步，當多個Slave重啟的時候，可能會導致Master IO劇增從而宕機。
- Redis 較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜；
1.2 Sentinel(哨兵模式)
1.2.1 哨兵模式說明
上面主從同步/復制的模式，當主服務器宕機后，需要手動把一台從服務器切換為主服務器，這里就需要人工干預，還會造成一段時間內服務不可用。
哨兵是一個獨立的進程，其原理是哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例。
這里哨兵的作用如下：
- 通過發送命令，讓Redis服務器返回其運行狀態，包括主服務器和從服務器。
- 當哨兵監測到master節點宕機，會自動將slave切換為master，然后通過發布訂閱模式通知其它的從服務器，修改配置文件，讓它們切換主機；
注意：一個哨兵進程對Redis服務器進行監控，也可能會出現問題，為此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
1.2.2 架構圖
1.2.3 故障切換的過程
假設主服務器宕機，哨兵1先檢測到這個結果，系統並不會馬上進行 failover 過程，僅僅是哨兵1主觀的認為主服務器不可用，這個現象成為主觀下線。當后面的哨兵也檢測到主服務器不可用，並且數量達到一定值時，那么哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行 failover 操作。切換成功后，就會通過發布訂閱模式，讓各個哨兵把自己監控的從服務器實現切換主機，這個過程稱為客觀下線。這樣對於客戶端而言，一切都是透明的。
1.2.4 哨兵的工作原理
- 每個Sentinel（哨兵）進程以每秒鍾一次的頻率向整個集群中的 Master 主服務器，Slave從服務器以及其他Sentinel（哨兵）進程發送一個 PING 命令。
- 如果一個實例（instance）距離最后一次有效回復PING命令的時間超過down-after-milliseconds選項所指定的值， 則這個實例會被 Sentinel（哨兵）進程標記為主觀下線（SDOWN）
- 如果一個Master主服務器被標記為主觀下線（SDOWN），則正在監視這個Master主服務器的所有Sentinel（哨兵）進程要以每秒一次的頻率確認Master主服務器的確進入了主觀下線狀態
- 當有足夠數量的Sentinel（哨兵）進程（大於等於配置文件指定的值）在指定的時間范圍內確認Master主服務器進入了主觀下線狀態（SDOWN）， 則Master主服務器會被標記為客觀下線（ODOWN）
- 在一般情況下， 每個Sentinel（哨兵）進程會以每10秒一次的頻率向集群中的所有Master主服務器、Slave從服務器發送INFO命令。
- 當Master主服務器被Sentinel（哨兵）進程標記為客觀下線（ODOWN）時，Sentinel（哨兵）進程向下線的Master主服務器的所有 Slave 從服務器發送INFO命令的頻率會從10秒一次改為每秒一次。
- 若沒有足夠數量的 Sentinel（哨兵）進程同意Master主服務器下線，Master主服務器的客觀下線狀態就會被移除。若Master主服務器重新向Sentinel（哨兵）進程發送PING命令返回有效回復，Master主服務器的主觀下線狀態就會被移除。
1.2.5 哨兵模式的優缺點
優點：
- 哨兵模式是基於主從模式的，所有主從的優點，哨兵模式都具有。
- 主從可以自動切換，系統更健壯，可用性更高。
缺點： - Redis較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜。
1.3 Cluster集群模式
Redis 的哨兵模式基本已經可以實現高可用，讀寫分離 ，但是在這種模式下每台 Redis 服務器都存儲相同的數據，很浪費內存，所以在 redis3.0上加入了 Cluster 集群模式，實現了 Redis 的分布式存儲，也就是說每台 Redis 節點上存儲不同的內容。
1.3.1 Cluster集群架構
1.3.2 Cluster集群數據分片說明
Redis集群沒有使用一致性hash，而是引入了哈希槽【hash slot】的概念。
Redis 集群有16384個哈希槽，每個key通過CRC16校驗后對16384取模來決定放置哪個槽。集群的每個節點負責一部分hash槽，舉個例子，比如當前集群有3個節點，那么：
- 節點A包含0到5460號哈希槽
- 節點B包含5461到10922號哈希槽
- 節點C包含10923到16383號哈希槽
這種結構很容易添加或者刪除節點。比如如果我想新添加個節點D，需要從節點A，B，C中分配部分槽到D上。如果我想移除節點A，需要將A中的槽移到B和C節點上，然后將沒有任何槽的A節點從集群中移除即可。由於從一個節點將哈希槽移動到另一個節點並不會停止服務，所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集群不可用的狀態。
在Redis的每一個節點上，都有這么兩個東西，一個是插槽（slot），它的的取值范圍是：0-16383。還有一個就是cluster，可以理解為是一個集群管理的插件。當我們的存取的Key到達的時候，Redis會根據CRC16的算法得出一個結果，然后把結果對16384求余數，這樣每個key都會對應一個編號在0-16383 之間的哈希槽，通過這個值，去找到對應的插槽所對應的節點，然后直接自動跳轉到這個對應的節點上進行存取操作。
1.3.3 Redis Cluster集群的主從復制模型
為了保證高可用，redis-cluster集群引入了主從復制模型，一個主節點對應一個或者多個從節點，當主節點宕機的時候，就會啟用從節點。當其它主節點Ping一個主節點A時，如果半數以上的主節點與A通信超時，那么認為主節點A宕機了。如果主節點A和它的從節點A1都宕機了，那么該集群就無法再提供服務了。
1.3.4 Redis Cluster集群的特點
- 所有的Redis節點彼此互聯(PING-PONG機制)，內部使用二進制協議優化傳輸速度和帶寬。
- 節點的fail是通過集群中超過半數的節點檢測失效時才生效。
- 客戶端與Redis節點直連，不需要中間代理層.客戶端不需要連接集群所有節點，連接集群中任何一個可用節點即可。