共計 1687 個字符，預(yù)計需要花費 5 分鐘才能閱讀完成。

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

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

主從復(fù)制的問題

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

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

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

2. 存在的問題

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

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

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

Sentinel 實現(xiàn)原理 1. 一些概念主要功能

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

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

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

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

主觀下線和客觀下線

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

主觀下線：適用于所有主節(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)判斷。如果超過 quorum 個數(shù)的節(jié)點判定主節(jié)點不可達(dá)，則該 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 確認(rèn)此主服務(wù)器是否進(jìn)入主觀下線狀態(tài)

如果超過 quorum 個數(shù)的節(jié)點判定主節(jié)點不可達(dá)，則該 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é)點 進(jìn)行 數(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è)置了主庫能進(jìn)行數(shù)據(jù)同步的最少從庫數(shù)量；

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

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

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

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