Redis之哨兵模式

前言

Redis 的 主從復制 模式下，一旦 主節點 由於故障不能提供服務，需要手動將 從節點 晉升為 主節點，同時還要通知 客戶端 更新 主節點地址，這種故障處理方式從一定程度上是無法接受的。Redis 2.8 以后提供了 Redis Sentinel 哨兵機制 來解決這個問題。

正文

1. Redis Sentinel的基本概念

Redis Sentinel 是 Redis 高可用 的實現方案。Sentinel 是一個管理多個 Redis 實例的工具，它可以實現對 Redis 的 監控、通知、自動故障轉移。下面先對 Redis Sentinel 的 基本概念 進行簡單的介紹。

基本名詞說明：

基本名詞	邏輯結構	物理結構
Redis數據節點	主節點和從節點	主節點和從節點的進程
主節點(master)	Redis主數據庫	一個獨立的Redis進程
從節點(slave)	Redis從數據庫	一個獨立的Redis進程
Sentinel節點	監控Redis數據節點	一個獨立的Sentinel進程
Sentinel節點集合	若干Sentinel節點的抽象組合	若干Sentinel節點進程
Redis Sentinel	Redis高可用實現方案	Sentinel節點集合和Redis數據節點進程
應用客戶端	泛指一個或多個客戶端	一個或者多個客戶端進程或者線程

如圖所示，Redis 的 主從復制模式 和 Sentinel 高可用架構 的示意圖：

 

 

 

2. Redis主從復制的問題

Redis 主從復制 可將 主節點 數據同步給 從節點，從節點此時有兩個作用：

1. 一旦 主節點宕機，從節點 作為 主節點 的 備份 可以隨時頂上來擴展 主節點 的 讀能力，分擔主節點讀壓力。

2. 主從復制 同時存在以下幾個問題：

   1. 一旦 主節點宕機，從節點 晉升成 主節點，同時需要修改 應用方 的 主節點地址，還需要命令所有 從節點 去 復制 新的主節點，整個過程需要 人工干預。

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

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

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

   3. Redis Sentinel深入探究3.1. Redis Sentinel的架構

   1. 

      3.2. Redis Sentinel的主要功能

      Sentinel 的主要功能包括 主節點存活檢測、主從運行情況檢測、自動故障轉移 （failover）、主從切換。Redis 的 Sentinel 最小配置是 一主一從。

      Redis 的 Sentinel 系統可以用來管理多個 Redis 服務器，該系統可以執行以下四個任務：

      • 監控

      Sentinel 會不斷的檢查 主服務器 和 從服務器 是否正常運行。

      • 通知

      當被監控的某個 Redis 服務器出現問題，Sentinel 通過 API 腳本 向 管理員 或者其他的 應用程序 發送通知。

      • 自動故障轉移

      當 主節點 不能正常工作時，Sentinel 會開始一次 自動的 故障轉移操作，它會將與 失效主節點 是 主從關系 的其中一個 從節點 升級為新的 主節點，並且將其他的 從節點 指向 新的主節點。

      • 配置提供者

      在 Redis Sentinel 模式下，客戶端應用 在初始化時連接的是 Sentinel 節點集合，從中獲取 主節點 的信息。

      3.3. 主觀下線和客觀下線

      默認情況下，每個 Sentinel 節點會以 每秒一次 的頻率對 Redis 節點和 其它 的 Sentinel 節點發送 PING 命令，並通過節點的 回復 來判斷節點是否在線。

      • 主觀下線

      主觀下線 適用於所有 主節點 和 從節點。如果在 down-after-milliseconds 毫秒內，Sentinel 沒有收到 目標節點 的有效回復，則會判定 該節點 為 主觀下線。

      • 客觀下線

      客觀下線 只適用於 主節點。如果 主節點 出現故障，Sentinel 節點會通過 sentinel is-master-down-by-addr 命令，向其它 Sentinel 節點詢問對該節點的 狀態判斷。如果超過 <quorum> 個數的節點判定 主節點 不可達，則該 Sentinel 節點會判斷 主節點 為 客觀下線。

      3.4. Sentinel的通信命令

      Sentinel 節點連接一個 Redis 實例的時候，會創建 cmd 和 pub/sub 兩個 連接。Sentinel 通過 cmd 連接給 Redis 發送命令，通過 pub/sub 連接到 Redis 實例上的其他 Sentinel 實例。

      Sentinel 與 Redis 主節點 和 從節點 交互的命令，主要包括：

      命令	作 用
      PING	Sentinel 向 Redis 節點發送 PING 命令，檢查節點的狀態
      INFO	Sentinel 向 Redis 節點發送 INFO 命令，獲取它的 從節點信息
      PUBLISH	Sentinel 向其監控的 Redis 節點 __sentinel__:hello 這個 channel 發布 自己的信息 及 主節點 相關的配置
      SUBSCRIBE	Sentinel 通過訂閱 Redis 主節點 和 從節點 的 __sentinel__:hello 這個 channnel，獲取正在監控相同服務的其他 Sentinel 節點

      Sentinel 與 Sentinel 交互的命令，主要包括：

      命令	作 用
      PING	Sentinel 向其他 Sentinel 節點發送 PING 命令，檢查節點的狀態
      SENTINEL:is-master-down-by-addr	和其他 Sentinel 協商 主節點 的狀態，如果 主節點 處於 SDOWN 狀態，則投票自動選出新的 主節點

      3.5. Redis Sentinel的工作原理

      每個 Sentinel 節點都需要 定期執行 以下任務：

      • 每個 Sentinel 以 每秒鍾 一次的頻率，向它所知的 主服務器、從服務器 以及其他 Sentinel 實例 發送一個 PING 命令。
   如果一個 實例（instance）距離 最后一次 有效回復 PING命令的時間超過 down-after-milliseconds所指定的值，那么這個實例會被 Sentinel標記為 主觀下線。    
    

如果一個 主服務器 被標記為 主觀下線，那么正在 監視 這個 主服務器 的所有 Sentinel節點，要以 每秒一次 的頻率確認 主服務器 的確進入了 主觀下線 狀態。

 

 

 

如果一個 主服務器 被標記為 主觀下線，並且有 足夠數量 的 Sentinel（至少要達到 配置文件 指定的數量）在指定的 時間范圍 內同意這一判斷，那么這個 主服務器 被標記為 客觀下線。

 

 

在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率，向它已知的所有 主服務器 和 從服務器 發送 INFO 命令。當一個 主服務器 被 Sentinel 標記為 客觀下線 時，Sentinel 向 下線主服務器 的所有 從服務器 發送 INFO 命令的頻率，會從 10 秒一次改為 每秒一次。

 

 

 

 Sentinel 和其他 Sentinel 協商 主節點 的狀態，如果 主節點 處於 SDOWN 狀態，則投票自動選出新的 主節點。將剩余的 從節點 指向 新的主節點 進行 數據復制。

自動選舉三個層級：

第一輪：比較從庫的優先級

你可以手動設置從庫的優先級，通過 slave-priority 進行設置，數字越小，級別越高。如果這個層次，有優先級級別最高的出現，那么就選此從庫做為Master，選舉就結束了，如果優先級相同，那么進入下一輪打分。

第二輪：與主庫的同步進度越接近

肯定是從庫的數據越新，那么選擇它作為新的Master，才最有意義了。那怎么才能知道哪個從庫才是最新的呢？

我們之前上一篇redis主從原理，從庫會記錄自己同步主庫的進度，這個參數為slave_repl_offset , 是累加的，也就是這個值越大，那么它們誰同步的數據就是最新的，得分就是最高的，選舉就結束了，如果復制進度相同，那么還需要進入下一輪，比較ID。

第三輪：ID號越小，得分越高

比較自己的ID【redis在啟動的時候，會給自己分配一個ID】，ID越小，自己得分就越高。

最多經歷三輪打分，主庫就會被重新選出，那么哨兵就會通知其他從庫執行replicaof 指向新的主庫，進行主從切換。

 

 

當沒有足夠數量的 Sentinel 同意 主服務器 下線時， 主服務器 的 客觀下線狀態 就會被移除。當 主服務器 重新向 Sentinel 的 PING 命令返回 有效回復 時，主服務器 的 主觀下線狀態 就會被移除。

 

 

注意：一個有效的 PING 回復可以是：+PONG、-LOADING 或者 -MASTERDOWN。如果 服務器 返回除以上三種回復之外的其他回復，又或者在 指定時間 內沒有回復 PING 命令， 
那么 Sentinel 認為服務器返回的回復 無效（non-valid）。

 

 

4. Redis Sentinel局限性

1. 需要另外部署一套哨兵集群，部署麻煩、原理復雜、浪費資源，從節點作為備份節點不提供服務。
2. 不支持讀寫分離，實現起來相對復雜。
3. 只支持對主節點的故障轉移，不支持對從節點的故障轉移。
4. 所有主節點和從節點都包含了 Redis 全量的數據，數據冗余，導致數據存儲的數據量有限。

 

 

騰訊三面：哨兵掛了，Redis還能正常工作嗎？ https://www.163.com/dy/article/GO9O52GM0552OQCF.html

 

版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。

本文鏈接： https://blog.csdn.net/qq_24313635/article/details/102767793