一、介紹

　　上一篇我們已經介紹了Redis的主從復制，傳送門：《Redis高可用之主從復制實踐（四）》，想必大家對redis已經有一個概念了，那麽問題來了，如果redis主從復制的master服務器掛掉了，那麽整體redis就崩潰了，因為master無法進行寫數據，導致slave中無法更新數據。

那麽為了解決這個問題我們就需要有一種方案讓redis宕機後可以自動進行故障轉移，還好redis給我們提供一種高可用解決方案 Redis-Sentinel。Redis-sentinel本身也是一個獨立運行的進程，它能監控多個master-slave集群，發現master宕機後能進行自動切換。Sentinel可以監視任意多個主服務器

以及主服務器屬下的從服務器，並在被監視的主服務器下線時，自動執行故障轉移操作。

　　既然有這麽好的解決方案，那麽我們就來看看如何在我們的服務器上進行配置

二、Sentinel配置啟動與故障轉移

1、環境配置

第一：準備3臺服務器，此處我的sentinel就直接放在原先的服務器上

此處要說明一個問題，我這邊的sentinel采用的是集群部署的方式，而不是單點，想必大家也知道單點會存在很多的問題，比如：

1）：當sentinel進程宕掉後(sentinel本身也有單點問題，single-point-of-failure)整個集群系統將無法按照預期的方式運行；

2）：如果只有一個sentinel進程，如果這個進程運行出錯，或者是網絡堵塞，那麽將無法實現redis集群的主備切換（單點問題）。

如果有多個sentinel，redis的客戶端可以隨意地連接任意一個sentinel來獲得關於redis集群中的信息；即使有一些sentinel進程宕掉了，依然可以進行redis集群的主備切換；

2、創建sentinel配置文件

進入 132 服務器的redis文件夾下，我們創建一個文件名為 sentinel-26379.conf 配置文件，文件內容如下：

port 26379
daemonize yes
logfile "26379.log"
dir "./"
sentinel monitor mymaster 192.168.250.132 7000 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 15000
sentinel auth-pass mymaster 123
bind 192.168.250.132 127.0.0.1

那麽133與134服務器下的redis文件夾中我們也創建相同的sentinel 配置文件，但主要修改一下端口26380/26381以及bin綁定的數據。

看到這裏大家因為會對上面的配置有些疑惑，那我分別介紹一下參數的含義：

像 port、daemonize、logfile、dir、bind 這些我就不介紹了，之前也介紹過了，這邊重點介紹一下sentinel的配置

sentinel monitor <master-name> <ip> <redis-port> <quorum>
告訴sentinel去監聽地址為ip:port的一個master，這裏的master-name可以自定義，quorum是一個數字，指明當有多少個sentinel認為一個master失效時，master才算真正失效

sentinel auth-pass <master-name> <password>
設置連接master和slave時的密碼，註意的是sentinel不能分別為master和slave設置不同的密碼，因此master和slave的密碼應該設置相同。

sentinel down-after-milliseconds <master-name> <milliseconds> 
這個配置項指定了需要多少失效時間，一個master才會被這個sentinel主觀地認為是不可用的。 單位是毫秒，默認為30秒

sentinel parallel-syncs <master-name> <numslaves> 
這個配置項指定了在發生failover主備切換時最多可以有多少個slave同時對新的master進行 同步，這個數字越小，完成failover所需的時間就越長，但是如果這個數字越大，就意味著越 多的slave因為replication而不可用。可以通過將這個值設為 1 來保證每次只有一個slave 處於不能處理命令請求的狀態。

sentinel failover-timeout <master-name> <milliseconds>
failover-timeout 可以用在以下這些方面：     
1. 同一個sentinel對同一個master兩次failover之間的間隔時間。   
2. 當一個slave從一個錯誤的master那裏同步數據開始計算時間。直到slave被糾正為向正確的master那裏同步數據時。    
3.當想要取消一個正在進行的failover所需要的時間。    
4.當進行failover時，配置所有slaves指向新的master所需的最大時間。不過，即使過了這個超時，slaves依然會被正確配置為指向master，但是就不按parallel-syncs所配置的規則來了。

配圖如下：

這樣子大家也能明白，那麽接下來我們就要開始啟動我們的sentinel啦，當然前提大家要先把redis主從復制開啟。

sentinel 運行命令如下：

./src/redis-sentinel sentinel-26379.conf
./src/redis-sentinel sentinel-26380.conf
./src/redis-sentinel sentinel-26381.conf

運行完後我們再來看看sentinel-263779.conf的配置，發現配置文件被重寫了，從內容可以看出有哪些slave和sentinel

內容已經配置完畢，現在我們進行一下故障轉移吧，

3、故障轉移

我們關閉master主節點，當然我演示的項目中master服務器是134，因為我之前有測試過，因此大家在操作的時候可以按照自己機器上的為主。

第一步：我們關閉134的redis，等待一會，我們再查看一下sentinel的日誌。我們通過日誌來分析一下自動故障轉移的流程

=======================134master發現不能用
40325:X 09 Jan 2019 16:46:09.920 # +sdown master mymaster 192.168.250.134 7002

=======================投票後有兩個sentinel發現master不能用
40325:X 09 Jan 2019 16:46:10.005 # +odown master mymaster 192.168.250.134 7002 #quorum 2/2

=======================當前配置版本被更新
40325:X 09 Jan 2019 16:46:10.005 # +new-epoch 2

=======================達到故障轉移failover條件，正等待其他sentinel的選舉
40325:X 09 Jan 2019 16:46:10.005 # +try-failover master mymaster 192.168.250.134 7002

=======================進行投票選舉slave服務器
40325:X 09 Jan 2019 16:46:10.006 # +vote-for-leader 7985977d2db7df47bce251c06d50f77c3917d184 2
40325:X 09 Jan 2019 16:46:10.007 # f53245a5100693311aeaf090b903de8587b3743a voted for 7985977d2db7df47bce251c06d50f77c3917d184 2
40325:X 09 Jan 2019 16:46:10.008 # c8e067032a78eafcdca9636cb4d9777b492daea6 voted for 7985977d2db7df47bce251c06d50f77c3917d184 2
40325:X 09 Jan 2019 16:46:10.077 # +elected-leader master mymaster 192.168.250.134 7002
40325:X 09 Jan 2019 16:46:10.077 # +failover-state-select-slave master mymaster 192.168.250.134 7002

=======================選擇一個slave當選新的master
40325:X 09 Jan 2019 16:46:10.178 # +selected-slave slave 192.168.250.132:7000 192.168.250.132 7000 @ mymaster 192.168.250.134 7002

=======================把選舉出來的slave進行身份master切換
40325:X 09 Jan 2019 16:46:10.178 * +failover-state-send-slaveof-noone slave 192.168.250.132:7000 192.168.250.132 7000 @ mymaster 192.168.250.134 7002
40325:X 09 Jan 2019 16:46:10.241 * +failover-state-wait-promotion slave 192.168.250.132:7000 192.168.250.132 7000 @ mymaster 192.168.250.134 7002
40325:X 09 Jan 2019 16:46:10.393 # +promoted-slave slave 192.168.250.132:7000 192.168.250.132 7000 @ mymaster 192.168.250.134 7002

=======================把故障轉移failover改變reconf-slaves
40325:X 09 Jan 2019 16:46:10.393 # +failover-state-reconf-slaves master mymaster 192.168.250.134 7002

=======================sentinel發送slaveof命令把133重新同步132master
40325:X 09 Jan 2019 16:46:10.448 * +slave-reconf-sent slave 192.168.250.133:7001 192.168.250.133 7001 @ mymaster 192.168.250.134 7002

=======================重寫rewrite master地址到sentinel配置文件中 
40325:X 09 Jan 2019 16:46:10.738 * +sentinel-address-switch master mymaster 192.168.250.134 7002 ip 192.168.250.132 port 26379 for c8e067032a78eafcdca9636cb4d9777b492daea6
40325:X 09 Jan 2019 16:46:10.907 * +sentinel-address-switch master mymaster 192.168.250.134 7002 ip 192.168.250.138 port 26379 for c8e067032a78eafcdca9636cb4d9777b492daea6

=======================離開不可用的master
40325:X 09 Jan 2019 16:46:11.135 # -odown master mymaster 192.168.250.134 7002

=======================slave被重新配置為另外一個master的slave，但數據還未發生
40325:X 09 Jan 2019 16:46:11.407 * +slave-reconf-inprog slave 192.168.250.133:7001 192.168.250.133 7001 @ mymaster 192.168.250.134 7002

=======================與master進行數據同步
40325:X 09 Jan 2019 16:46:11.407 * +slave-reconf-done slave 192.168.250.133:7001 192.168.250.133 7001 @ mymaster 192.168.250.134 7002

=======================故障轉移完成
40325:X 09 Jan 2019 16:46:11.508 # +failover-end master mymaster 192.168.250.134 7002

=======================master地址發生改變
40325:X 09 Jan 2019 16:46:11.508 # +switch-master mymaster 192.168.250.134 7002 192.168.250.132 7000

=======================檢測slave並添加到slave列表
40325:X 09 Jan 2019 16:46:11.508 * +slave slave 192.168.250.133:7001 192.168.250.133 7001 @ mymaster 192.168.250.132 7000
40325:X 09 Jan 2019 16:46:11.508 * +slave slave 192.168.250.134:7002 192.168.250.134 7002 @ mymaster 192.168.250.132 7000
40325:X 09 Jan 2019 16:46:12.475 * +sentinel-address-switch master mymaster 192.168.250.132 7000 ip 192.168.250.132 port 26379 for c8e067032a78eafcdca9636cb4d9777b492daea

自此故障轉移完成，我們查看一下132，現在132已經變成master了，並且 133和134變為了slave。

我們再來對比一下 sentinel-26379.conf的配置文件數據，發現已經修改了。自此failover完成。

三、總結

redis的高可用已經講解了兩大部分了，剩余的集群部署將是我們的最後的步驟，也是關鍵的。下一篇將會開啟集群的配置。

如果上述有問題，歡迎大家指教。

參考文章：

《Redis及其Sentinel配置項詳細說明》：https://blog.csdn.net/a1282379904/article/details/52335051

《Redis 復制、Sentinel的搭建和原理說明》：https://www.cnblogs.com/zhoujinyi/p/5570024.html

《Redis Sentinel高可用架構》：https://www.cnblogs.com/gomysql/p/5040847.html

asp.net core 交流群：787464275 歡迎加群交流
如果您認為這篇文章還不錯或者有所收獲，您可以點擊右下角的【推薦】按鈕精神支持，因為這種支持是我繼續寫作，分享的最大動力！

微信公眾號：歡迎關註 QQ技術交流群： 歡迎加群

Redis之哨兵模式Sentinel配置與啟動（五）