一文了解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 節點詢問對該節點的狀態判斷。如果超過 <quorum></quorum> 個數的節點判定主節點不可達，則 Sentinel 節點會判斷主節點為客觀下線。

2. 工作原理

#

• 每個Sentinel 以1次/s 頻率，向其他Sentinel 節點、Redis 主從節點發送PING 指令。
• 如果一個實例，距離最後有效回應PING 指令超過down-after-milliseconds，這個實例被Sentinel 標記為主觀下線。
• 如果一個主伺服器 被標記為主觀下線，那麼正在監視這個主伺服器的所有Sentinel 節點，以1次/s 確認此主伺服器是否進入主觀下線狀態
• 如果超過<quorum></quorum> 個數的節點判定主節點不可達，則該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中的哨兵模式的詳細內容。更多資訊請關注PHP中文網其他相關文章！