一文了解Redis中的哨兵模式

本篇文章帶大家了解一下redis中的哨兵模式，希望對大家有所幫助！

redis 主從模式，一旦主節點發生故障，可以將從節點 升為 主節點，同時還要通知客戶端更新主節點地址，這樣一般是不可行的。所以，Redis 提供了 Redis sentinel 哨兵機制 來解決這個問題。【相關推薦：Redis視頻教程】

主從復制的問題

1. 主從復制的好處

• 主節點發生故障，從節點會升級為主節點
• 擴展主節點的讀能力，分擔主節點壓力

2. 存在的問題

• 從節點升級主節點的過程需要人工干預，同時要更改客戶端Redis服務地址
• 主節點寫能力、存儲能力受到單機限制
• 性能的影響：Redis 復制中斷 后從節點會發起 psync。此時如果同步不成功，則會進行全量同步，主庫執行全量備份的同時，可能會造成毫秒或秒級的 卡頓

Sentinel 實現原理

1. 一些概念

主要功能

• 監控 ： 不斷檢查主從服務器是否正常運行
• 通知 ： 一旦某個節點發生故障，會通知其他節點
• 自動故障轉移 ： 當主節點不能正常工作會自動進行故障轉移，從其中一個從節點升級為主節點
• 配置提供者 ： 客戶端不是配置單個節點，而是 Sentinel 節點集合

主觀下線和客觀下線

一般來說，每個 Sentinel 節點會不斷的 對其他 Sentinel 節點和 Redis 節點發送 PING，通過是否回復來確認是否在線

• 主觀下線 ： 適用于所有主節點和從節點，如果在 down-after-milliseconds 毫秒內，Sentinel 沒有收到目標節點的有效回復，則會判定該節點為主觀下線。
• 客觀下線 ： 只使用于主節點，如果主節點發生故障，Sentinel 節點會通過 sentinel is-master-down-by-addr 命令，向其它 Sentinel 節點詢問對該節點的狀態判斷。如果超過 個數的節點判定主節點不可達，則該 Sentinel 節點會判斷主節點為客觀下線。

2. 工作原理

• 每個 Sentinel 以 1次/s 頻率，向其他 Sentinel 節點、Redis 主從節點發送 PING 指令。
• 如果一個實例，距離最后有效回復 PING 命令超過 down-after-milliseconds，這個實例被 Sentinel 標記為 主觀下線。
• 如果一個 主服務器 被標記為主觀下線，那么正在監視這個主服務器的所有 Sentinel 節點，以 1次/s 確認此主服務器是否進入主觀下線狀態
• 如果超過 個數的節點判定主節點不可達，則該 Sentinel 節點會判斷主節點為 客觀下線。
• 當主服務器被標記為客觀下線時，Sentinel 向下線服務器的所欲服務器發送 INFO 命令，會從10次/s 改為 1次/s。
• Sentinel 節點之間協商主節點狀態，如果主節點處于 SDOWN 狀態，則投票自動選出新的 主節點。將剩余的 從節點 指向 新的主節點 進行 數據復制。
• 當沒有足夠數量的 Sentinel 同意 主服務器 下線時， 主服務器 的 客觀下線狀態 就會被移除。當 主服務器 重新向 Sentinel 的 PING 命令返回 有效回復 時，主服務器 的 主觀下線狀態 就會被移除。

3. 消息丟失

Redis 采用主從復制的模式，一旦主節點掛掉，從節點正在同步的數據可能會丟失，延遲越大，丟失的越多。

Redis 提供了兩個配置項來限制主庫的請求處理，分別是 min-slaves-to-write 和 min-slaves-max-lag。

• min-slaves-to-write：這個配置項設置了主庫能進行數據同步的最少從庫數量；
• min-slaves-max-lag：這個配置項設置了主從庫間進行數據復制時，從庫給主庫發送 ACK 消息的最大延遲（以秒為單位）。

這兩個配置項組合后的要求是，主庫連接的從庫中至少有 N 個從庫，和主庫進行數據復制時的 ACK 消息延遲不能超過 T 秒，否則，主庫就不會再接收客戶端的請求了。

所以，Sentine 無法保證消息完全不丟失，但是也能盡量保證消息少丟失。

小結

Sentinel 解決了高可用，沒有解決主節點單節點擴容的問題。

更多編程相關知識，請訪問：Redis視頻教程！！