本篇內(nèi)容介紹了“怎么理解redis中的哨兵模式”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)專注于網(wǎng)站建設(shè)|成都網(wǎng)站維護|優(yōu)化|托管以及網(wǎng)絡(luò)推廣，積累了大量的網(wǎng)站設(shè)計與制作經(jīng)驗，為許多企業(yè)提供了網(wǎng)站定制設(shè)計服務(wù)，案例作品覆蓋成都除甲醛等行業(yè)。能根據(jù)企業(yè)所處的行業(yè)與銷售的產(chǎn)品，結(jié)合品牌形象的塑造，量身定制品質(zhì)網(wǎng)站。

Redis 主從模式，一旦主節(jié)點發(fā)生故障，可以將從節(jié)點 升為 主節(jié)點，同時還要通知客戶端更新主節(jié)點地址，這樣一般是不可行的。所以，Redis 提供了 Redis Sentinel 哨兵機制來解決這個問題。

主從復(fù)制的問題

1. 主從復(fù)制的好處

• 主節(jié)點發(fā)生故障，從節(jié)點會升級為主節(jié)點

• 擴展主節(jié)點的讀能力，分擔(dān)主節(jié)點壓力

2. 存在的問題

• 從節(jié)點升級主節(jié)點的過程需要人工干預(yù)，同時要更改客戶端Redis服務(wù)地址

• 主節(jié)點寫能力、存儲能力受到單機限制

• 性能的影響：Redis 復(fù)制中斷 后從節(jié)點會發(fā)起 psync。此時如果同步不成功，則會進行全量同步，主庫執(zhí)行全量備份的同時，可能會造成毫秒或秒級的 卡頓

Sentinel 實現(xiàn)原理

1. 一些概念

主要功能

• 監(jiān)控 ：不斷檢查主從服務(wù)器是否正常運行

• 通知 ：一旦某個節(jié)點發(fā)生故障，會通知其他節(jié)點

• 自動故障轉(zhuǎn)移 ：當(dāng)主節(jié)點不能正常工作會自動進行故障轉(zhuǎn)移，從其中一個從節(jié)點升級為主節(jié)點

• 配置提供者 ：客戶端不是配置單個節(jié)點，而是 Sentinel 節(jié)點集合

主觀下線和客觀下線

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

• 主觀下線 ：適用于所有主節(jié)點和從節(jié)點，如果在 down-after-milliseconds 毫秒內(nèi)，Sentinel 沒有收到目標(biāo)節(jié)點的有效回復(fù)，則會判定該節(jié)點為主觀下線。

• 客觀下線 ：只使用于主節(jié)點，如果主節(jié)點發(fā)生故障，Sentinel 節(jié)點會通過 sentinel is-master-down-by-addr 命令，向其它 Sentinel 節(jié)點詢問對該節(jié)點的狀態(tài)判斷。如果超過 個數(shù)的節(jié)點判定主節(jié)點不可達，則該 Sentinel 節(jié)點會判斷主節(jié)點為客觀下線。

2. 工作原理

• 每個 Sentinel 以 1次/s 頻率，向其他 Sentinel 節(jié)點、Redis 主從節(jié)點發(fā)送 PING 指令。

• 如果一個實例，距離最后有效回復(fù) PING 命令超過 down-after-milliseconds，這個實例被 Sentinel 標(biāo)記為 主觀下線。

• 如果一個 主服務(wù)器被標(biāo)記為主觀下線，那么正在監(jiān)視這個主服務(wù)器的所有 Sentinel 節(jié)點，以 1次/s 確認此主服務(wù)器是否進入主觀下線狀態(tài)

• 如果超過 個數(shù)的節(jié)點判定主節(jié)點不可達，則該 Sentinel 節(jié)點會判斷主節(jié)點為 客觀下線。

• 當(dāng)主服務(wù)器被標(biāo)記為客觀下線時，Sentinel 向下線服務(wù)器的所欲服務(wù)器發(fā)送 INFO 命令，會從10次/s 改為 1次/s。

• Sentinel 節(jié)點之間協(xié)商主節(jié)點狀態(tài)，如果主節(jié)點處于 SDOWN 狀態(tài)，則投票自動選出新的 主節(jié)點。將剩余的 從節(jié)點指向 新的主節(jié)點進行 數(shù)據(jù)復(fù)制。

• 當(dāng)沒有足夠數(shù)量的 Sentinel 同意 主服務(wù)器下線時， 主服務(wù)器的 客觀下線狀態(tài)就會被移除。當(dāng) 主服務(wù)器重新向 Sentinel 的 PING 命令返回 有效回復(fù)時，主服務(wù)器的 主觀下線狀態(tài)就會被移除。

3. 消息丟失

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

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

• min-slaves-to-write：這個配置項設(shè)置了主庫能進行數(shù)據(jù)同步的最少從庫數(shù)量；

• min-slaves-max-lag：這個配置項設(shè)置了主從庫間進行數(shù)據(jù)復(fù)制時，從庫給主庫發(fā)送 ACK 消息的最大延遲（以秒為單位）。

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

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

“怎么理解Redis中的哨兵模式”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！