這篇文章主要介紹Redis中的哨兵模式如何實現，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！
Redis Sentinel哨兵模式 是一個分布式系統， 你可以在一個架構中運行多個 Sentinel 進程（progress）， 這些進程使用流言協議（gossip protocols)來接收關于主服務器是否下線的信息， 并使用投票協議（agreement protocols）來決定是否執行自動故障遷移， 以及選擇哪個從服務器作為新的主服務器?！鞠嚓P推薦：Redis視頻教程】
Redis 的 Sentinel 系統用于管理多個 Redis 服務器（instance）， 系統執行以下三個任務：
監控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
提醒（Notification）： 當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
自動故障遷移（Automatic failover）： 當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主服務器的其中一個從服務器升級為新的主服務器， 并讓失效主服務器的其他從服務器改為復制新的主服務器； 當客戶端試圖連接失效的主服務器時， 集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。
每個sentinel以每秒鐘一次的頻率向它所知的master，slave以及其他sentinel實例發送一個 PING 命令
如果一個實例距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被sentinel標記為主觀下線。
如果一個master被標記為主觀下線，則正在監視這個master的所有sentinel要以每秒一次的頻率確認master的確進入了主觀下線狀態
當有足夠數量的sentinel（大于等于配置文件指定的值）在指定的時間范圍內確認master的確進入了主觀下線狀態， 則master會被標記為客觀下線
在一般情況下， 每個sentinel會以每 10 秒一次的頻率向它已知的所有master，slave發送 INFO 命令
當master被sentinel標記為客觀下線時，sentinel向下線的master的所有slave發送 INFO 命令的頻率會從 10 秒一次改為 1 秒一次
若沒有足夠數量的sentinel同意master已經下線，master的客觀下線狀態就會被移除； 若master重新向sentinel的 PING 命令返回有效回復，master的主觀下線狀態就會被移除
環境
master：127.0.0.1:6379 【初始化master】 slave：127.0.0.1:6380 127.0.0.1:6381 sentinel：127.0.0.1:26379 127.0.0.1:26380 127.0.0.1:26381
修改配置：
這里省略安裝了redis，直接修改sentinel配置文件。對應文件夾Redis6379-Redis6381
# 監控節點，且超過2個sentinel 任務故障，方可執行故障轉移 sentinel monitor mymaster 127.0.0.1 6379 2 # 如果節點在 30000毫秒內未回應，就認為故障 sentinel down-after-milliseconds mymaster 30000 # 如果故障轉移后，同時進行主從復制數為 1 sentinel parallel-syncs mymaster 1 # 故障轉移的超時時間 sentinel failover-timeout mymaster 180000 sentinel deny-scripts-reconfig yes
啟動命令
./src/redis-sentinel ./config/redis-sentinel-6379.conf（同樣啟動6380 6381）
以上是“Redis中的哨兵模式如何實現”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
