上個文章已經實現了 Redis 的讀寫分離，一主多從的結構已經搭建起來了，主節點負責寫數據，從節點負責讀數據，那么現在有個問題：如果主節點掛了，怎么辦呢？
Redis 提供了一種解決方案：Sentinel 哨兵模式。通過它可以實現：當主節點掛了以后，多個從節點會選出一個節點當主節點。
以 Windows 系統為例，現在有三個一樣的程序，首先實現讀寫分離，參照上一篇文章實現即可：https://www.cnblogs.com/jwen1994/p/12257958.html
然后每個 Redis 目錄下都新建一個：sentinel.conf 文件
主節點下的文件內容如下：
#當前Sentinel服務運行的端口 port 26379 #master #Sentinel去監視一個名為mymaster的主redis實例，這個主實例的IP地址為本機地址127.0.0.1，端口號為6379， #而將這個主實例判斷為失效至少需要2個 Sentinel進程的同意，只要同意Sentinel的數量不達標，自動failover就不會執行 sentinel monitor mymaster 127.0.0.1 6379 1 #指定了Sentinel認為Redis實例已經失效所需的毫秒數。當 實例超過該時間沒有返回PING，或者直接返回錯誤，那么Sentinel將這個實例標記為主觀下線。 #只有一個 Sentinel進程將實例標記為主觀下線並不一定會引起實例的自動故障遷移：只有在足夠數量的Sentinel都將一個實例標記為主觀下線之后，實例才會被標記為客觀下線，這時自動故障遷移才會執行 sentinel down-after-milliseconds mymaster 5000 #指定了在執行故障轉移時，最多可以有多少個從Redis實例在同步新的主實例，在從Redis實例較多的情況下這個數字越小，同步的時間越長，完成故障轉移所需的時間就越長 sentinel config-epoch mymaster 12 #如果在該時間（ms）內未能完成failover操作，則認為該failover失敗 sentinel leader-epoch mymaster 13
從節點下的文件內容如下：
#當前Sentine2服務運行的端口 port 26479 #slave1 sentinel monitor mymaster 127.0.0.1 6379 1 sentinel down-after-milliseconds mymaster 5000 sentinel config-epoch mymaster 12 sentinel leader-epoch mymaster 13
我們通過兩個命令，去啟動 Redis 和 Sentinel （每個 Redis 節點都去使用命令去啟動）
F:\redis>redis-server.exe redis.windows.conf
F:\redis>redis-server.exe sentinel.conf --sentinel
這樣就成功了，如果主節點掛了，多個從節點會選出一個節點當主節點。
參考文章：https://blog.csdn.net/ITLTX1024/article/details/100665452
如果認為干預該怎么實現從節點變主節點呢？通過以下兩個命令
slaveof no one # 取消主備，變更為主節點
slaveof 新host 新節點 # 將其他節點設置為新主節點的備份節點
sentinel 還有其他配置：
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
命令講解
- sentinel monitor mymaster 127.0.0.1 6379 1 名稱為 mymaster 的主節點名，1表示將這個主服務器判斷為失效至少需要 1個 Sentinel 同意 （只要同意 Sentinel 的數量不達標，自動故障遷移就不會執行）。
- down-after-milliseconds 選項指定了 Sentinel 認為服務器已經斷線所需的毫秒數。
- failover 過期時間，當 failover 開始后，在此時間內仍然沒有觸發任何 failover 操作，當前 sentinel 將會認為此次 failover 失敗
- parallel-syncs 選項指定了在執行故障轉移時， 最多可以有多少個從服務器同時對新的主服務器進行同步， 這個數字越小， 完成故障轉移所需的時間就越長。
如果從服務器被設置為允許使用過期數據集， 那么你可能不希望所有從服務器都在同一時間向新的主服務器發送同步請求， 因為盡管復制過程的絕大部分步驟都不會阻塞從服務器， 但從服務器在載入主服務器發來的 RDB 文件時， 仍然會造成從服務器在一段時間內不能處理命令請求： 如果全部從服務器一起對新的主服務器進行同步， 那么就可能會造成所有從服務器在短時間內全部不可用的情況出現
Sentinel 三大工作任務
- 監控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
- 提醒（Notification）： 當被監控的某個 Redis 服務器出現問題時，Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
- 自動故障遷移（Automatic failover）： 當一個主服務器不能正常工作時，Sentinel 會開始一次自動故障遷移操作， 它會將失效主服務器的其中一個從服務器升級為新的主服務器， 並讓失效主服務器的其他從服務器改為復制新的主服務器； 當客戶端試圖連接失效的主服務器時， 集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。
互聯網冷備和熱備講解，冷備和熱備的特點分析
冷備
1）概念：冷備份發生在數據庫已經正常關閉的情況下，當正常關閉時會提供給我們一個完整的數據庫
2）優點：
- 是非常快速的備份方法（只需拷文件）
- 低度維護，高度安全
3）缺點：
- 單獨使用時，只能提供到“某一時間點上”的恢復
- 再實施備份的全過程中，數據庫必須要作備份而不能作其他工作。也就是說，在冷備份過程中，數據庫必須是關閉狀態
熱備
1）概念：熱備份是在數據庫運行的情況下，采用archivelog mode方式備份數據庫的方法
2）優點：
- 備份的時間短
- 備份時數據庫仍可使用
- 可達到秒級恢復
3）缺點
- 若熱備份不成功，所得結果不可用於時間點的恢復
- 因難於維護，所以要非凡仔細小心
Sentinel 是怎么工作的？
主觀下線：
1）概念
主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 實例對服務器做出的下線判斷
2）主管下線特點：
如果一個服務器沒有在 master-down-after-milliseconds 選項所指定的時間內，對向它發送 PING 命令的 Sentinel 返回一個有效回復（valid reply）， 那么 Sentinel 就會將這個服務器標記為主觀下線。服務器對 PING 命令的有效回復可以是以下三種回復的其中一種：
- 返回 +PONG 。
- 返回 -LOADING 錯誤。
- 返回 -MASTERDOWN 錯誤。
客觀下線
1）概念：
指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷， 並且通過 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服務器下線判斷。 （一個 Sentinel 可以通過向另一個 Sentinel 發送 SENTINEL is-master-down-by-addr 命令來詢問對方是否認為給定的服務器已下線。）
2）客觀下線特點：
從主觀下線狀態切換到客觀下線狀態並沒有使用嚴格的法定人數算法（strong quorum algorithm）， 而是使用了流言協議： 如果 Sentinel 在給定的時間范圍內， 從其他 Sentinel 那里接收到了足夠數量的主服務器下線報告， 那么 Sentinel 就會將主服務器的狀態從主觀下線改變為客觀下線。 如果之后其他 Sentinel 不再報告主服務器已下線，那么客觀下線狀態就會被移除。
3）客觀下線注意點：
客觀下線條件只適用於主服務器：對於任何其他類型的 Redis 實例， Sentinel 在將它們判斷為下線前不需要進行協商，所以從服務器或者其他 Sentinel 永遠不會達到客觀下線條件。 只要一個 Sentinel 發現某個主服務器進入了客觀下線狀態， 這個 Sentinel 就可能會被其他 Sentinel 推選出， 並對失效的主服務器執行自動故障遷移操作。
Spring Boot 整合 Sentinel 的步驟
步驟一：引入依賴
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>
步驟二：引入 yml 配置
redis:
sentinel:
master: redis_master_group1 #mymaster
nodes: 172.16.244.133:26379
步驟三：啟動 Spring Boot 服務，發送請求看配置是否有效