高可用性（High Availability）：Redis 哨兵是Redis官方的高可用性解決方案

Redis主從複製的問題

Redis 主從複製 可將 主節點 數據同步給 從節點，從節點此時有兩個做用：

1. 一旦 主節點宕機，從節點 做爲 主節點 的 備份 能夠隨時頂上來。
2. 擴展 主節點 的 讀能力，分擔主節點讀壓力。

主從複製 同時存在如下幾個問題：

1. 一旦 主節點宕機，從節點 晉升成 主節點，同時須要修改 應用方 的 主節點地址，還須要命令全部 從節點去 複製 新的主節點，整個過程須要 人工干預。

2. 主節點 的 寫能力 受到 單機的限制。

3. 主節點 的 存儲能力 受到 單機的限制。

4. 原生複製 的弊端在早期的版本中也會比較突出，好比：Redis 複製中斷 後，從節點 會發起 psync。此時若是 同步不成功，則會進行 全量同步，主庫 執行 全量備份 的同時，可能會形成毫秒或秒級的 卡頓。

Redis 的 哨兵（Sentinel）深刻探究

Redis Sentinel的架構

Redis的哨兵機制就是解決咱們以上主從複製存在缺陷（選舉問題），保證咱們的Redis高可用，實現自動化故障發現與故障轉移。

該系統執行如下三個任務：

監控：哨兵會不斷檢查你的主服務器和從服務器是否運做正常。

提醒：當被監控的某個Redis服務器出現問題時，哨兵能夠經過API給程序員發送通知

自動故障轉移：主服務器宕機，哨兵會開始一次自動故障轉移操做，升級一個從服務器爲主服務器，並讓其餘從服務器改成複製新的主服務器.

配置 Sentinel

Redis 源碼中包含了一個名爲 sentinel.conf 的文件， 這個文件是一個帶有詳細註釋的 Sentinel 配置文件示例。

運行一個 Sentinel 所需的最少配置以下所示：

1）sentinel monitor mymaster 192.168.10.202 6379 2

Sentine監聽的maste地址，第一個參數是給master起的名字，第二個參數爲master IP，第三個爲master端口，第四個爲當該master掛了的時候，若想將該master判爲失效，

在Sentine集羣中必須至少2個Sentine贊成才行，只要該數量不達標，則就不會發生故障遷移。

-----------------------------------------------------------------------------------------------

2）sentinel down-after-milliseconds mymaster 30000

表示master被當前sentinel實例認定爲失效的間隔時間，在這段時間內一直沒有給Sentine返回有效信息，則認定該master主觀下線。

只有在足夠數量的 Sentinel 都將一個服務器標記爲主觀下線以後， 服務器纔會被標記爲客觀下線，將服務器標記爲客觀下線所需的 Sentinel 數量由對主服務器的配置決定。

-----------------------------------------------------------------------------------------------

3）sentinel parallel-syncs mymaster 2

當在執行故障轉移時，設置幾個slave同時進行切換master，該值越大，則可能就有越多的slave在切換master時不可用，能夠將該值設置爲1，即一個一個來，這樣在某個

slave進行切換master同步數據時，其他的slave還能正常工做，以此保證每次只有一個從服務器處於不能處理命令請求的狀態。

-----------------------------------------------------------------------------------------------

4）sentinel can-failover mymaster yes

在sentinel檢測到O_DOWN後，是否對這臺redis啓動failover機制

-----------------------------------------------------------------------------------------------

5）sentinel auth-pass mymaster 20180408

設置sentinel鏈接的master和slave的密碼，這個須要和redis.conf文件中設置的密碼同樣

-----------------------------------------------------------------------------------------------

6）sentinel failover-timeout mymaster 180000

failover過時時間，當failover開始後，在此時間內仍然沒有觸發任何failover操做，當前sentinel將會認爲這次failoer失敗。 

執行故障遷移超時時間，即在指定時間內沒有大多數的sentinel 反饋master下線，該故障遷移計劃則失效

-----------------------------------------------------------------------------------------------

7）sentinel config-epoch mymaster 0

選項指定了在執行故障轉移時， 最多能夠有多少個從服務器同時對新的主服務器進行同步。這個數字越小， 完成故障轉移所需的時間就越長。

-----------------------------------------------------------------------------------------------

8）sentinel notification-script mymaster /var/redis/notify.sh

當failover時，能夠指定一個"通知"腳本用來告知當前集羣的狀況。

腳本被容許執行的最大時間爲60秒，若是超時，腳本將會被終止(KILL)

-----------------------------------------------------------------------------------------------

9）sentinel leader-epoch mymaster 0

同時一時間最多0個slave可同時更新配置,建議數字不要太大,以避免影響正常對外提供服務。

主觀下線和客觀下線

• 主觀下線：指的是單個 Sentinel 實例對服務器作出的下線判斷。
• 客觀下線：指的是多個 Sentinel 實例在對同一個服務器作出 SDOWN主觀下線 判斷。

Redis Sentinel的工做原理​​​​​​​

1.每一個 Sentinel 以每秒一次的頻率向它所知的主服務器、從服務器以及其餘 Sentinel 實例發送一個 PING 命令。

2.若是一個實例距離最後一次有效回覆 PING 命令的時間超過指定的值， 那麼這個實例會被 Sentinel 標記爲主觀下線。 

3.正在監視這個主服務器的全部 Sentinel 要以每秒一次的頻率確認主服務器的確進入了主觀下線狀態。

4.有足夠數量的 Sentinel 在指定的時間範圍內贊成這一判斷， 那麼這個主服務器被標記爲客觀下線。

5.每一個 Sentinel 會以每 10 秒一次的頻率向它已知的全部主服務器和從服務器發送 INFO 命令。 當一個主服務器被 Sentinel 標記爲客觀下線時， Sentinel 向下線主服務器的全部從服務器發送 INFO 命令的頻率會從 10 秒一次改成每秒一次。

6.Sentinel 和其餘 Sentinel 協商 主節點 的狀態，若是 主節點 處於 SDOWN 狀態，則投票自動選出新的 主節點。將剩餘的 從節點 指向 新的主節點 進行 數據複製。

7.當沒有足夠數量的 Sentinel 贊成 主服務器 下線時， 主服務器 的 客觀下線狀態 就會被移除。當 主服務器 從新向 Sentinel 的 PING 命令返回 有效回覆 時，主服務器 的 主觀下線狀態 就會被移除。

​​​​​​​自動發現 Sentinel 和從服務器

一個 Sentinel 能夠與其餘多個 Sentinel 進行鏈接， 各個 Sentinel 之間能夠互相檢查對方的可用性， 並進行信息交換。

你無須爲運行的每一個 Sentinel 分別設置其餘 Sentinel 的地址， 由於 Sentinel 能夠經過發佈與訂閱功能來自動發現正在監視相同主服務器的其餘 Sentinel。

• 每一個 Sentinel 會以每兩秒一次的頻率， 經過發佈與訂閱功能， 向被它監視的全部主服務器和從服務器的頻道發送一條信息， 信息中包含了 Sentinel 的 IP 地址、端口號和運行 ID （runid）。
• 每一個 Sentinel 都訂閱了被它監視的全部主服務器和從服務器的頻道， 查找以前未出現過的 sentinel 。 當一個 Sentinel 發現一個新的 Sentinel 時， 它會將新的 Sentinel 添加到一個列表中。
• Sentinel 發送的信息中還包括完整的主服務器當前配置。 若是一個 Sentinel 包含的主服務器配置比另外一個 Sentinel 發送的配置要舊， 那麼這個 Sentinel 會當即升級到新配置上。
• 在將一個新 Sentinel 添加到監視主服務器的列表上面以前， Sentinel 會先檢查列表中是否已經包含了和要添加的 Sentinel 擁有相同運行 ID 或者相同地址（包括 IP 地址和端口號）的 Sentinel ， 若是是的話， Sentinel 會先移除列表中已有的那些擁有相同運行 ID 或者相同地址的 Sentinel ， 而後再添加新 Sentinel 

 故障轉移

一次故障轉移操做由如下步驟組成：

• 發現主服務器已經進入客觀下線狀態。
• 對咱們的當前紀元進行自增， 並嘗試在這個紀元中當選。
• 若是當選失敗， 那麼在設定的故障遷移超時時間的兩倍以後， 從新嘗試當選。 若是當選成功， 那麼執行如下步驟。
• 選出一個從服務器，並將它升級爲主服務器。
• 向被選中的從服務器發送 SLAVEOF NO ONE 命令，讓它轉變爲主服務器。
• 經過發佈與訂閱功能， 將更新後的配置傳播給全部其餘 Sentinel ， 其餘 Sentinel 對它們本身的配置進行更新。
• 向已下線主服務器的從服務器發送 SLAVEOF 命令， 讓它們去複製新的主服務器。
• 當全部從服務器都已經開始複製新的主服務器時， 領頭 Sentinel 終止此次故障遷移操做。

參考：

https://redis.io/

https://www.cnblogs.com/bingshu/p/9776610.html