大家好，我是小米，31 歲，熱愛技術、熱愛分享、熱愛奶茶（雖然醫生説我應該喝無糖）的大哥哥。
最近又陪朋友刷 Java 社招面試，他一臉生無可戀：“面試官又問我 Redis sentinel 哨兵模式，我記得好像是監控主從的？但細節我又忘了……”
我拍着他的肩膀，遞上一杯奶茶，笑着説：“兄弟，這題我用一杯奶茶講給你聽。聽完包你從懵到精通。”
喝口奶茶，我們開始講故事。
如果 Redis 是一家奶茶店
想象一下：Redis 就像是一家超火爆的奶茶店，排隊排到三公里外那種。
店裏有：
- 一個店長（master）：負責“衝奶茶、點單、打包”，超級忙。
- 幾個店員（slave）：負責“複製店長的手藝”，同步店長製作奶茶的過程，但不接單。
某天，店長幹累了，“啪”地一下暈倒了……
整個奶茶店瞬間癱瘓，顧客全跑了。
這就是：Redis 單點故障，master 掛了，整條服務崩盤。
怎麼辦？讓我們登場——哨兵（Sentinel）！
哨兵模式出現：給奶茶店安排一羣“店長監督員”
“哨兵模式”（Redis Sentinel）就是給 Redis 奶茶店安排一羣“監督員”。
這些監督員整天圍着店長轉：
- 盯着店長有沒有暈倒
- 盯着店員們是不是正常複製數據
- 一旦店長真的倒了，他們會召開“緊急會議”
- 選一個店員當新店長
- 通知所有顧客：‘新店長上任了！繼續喝奶茶吧！’
這就是 Redis 哨兵模式的核心功能，Redis Sentinel 的三大職責：
- 監控（Monitoring）：Sentinel 會持續監控 master 和 slave 是否正常。
- 故障恢復（Failover）：master 掛了，自動選舉一個 slave 為新的 master，建立新的主從結構。
- 通知（Notification）：有變化時通過 API 或腳本通知客户端、其他程序：“master 換人啦！”
是不是，很像一羣專業的店長監督員？
哨兵是怎麼判斷“店長真的掛了”的？
哨兵不會店長一咳嗽就説他掛了，Redis 的 Sentinel 有嚴格的判斷標準。
1. 主觀下線（SDOWN）
某個哨兵認為 master 沒回應，於是説：
“我覺得店長暈了。”
但“我覺得”不能作為證據。
這只是 主觀下線。
2. 客觀下線（ODOWN）
只有當多個哨兵一起投票，説：
“對，我也覺得店長掛了。”
哨兵集羣才會確認：
“OK，店長真的掛了。”
這叫 客觀下線（ODOWN）。只有 ODOWN 狀態，哨兵才會啓動真正的故障轉移流程（failover）。
你以為選新店長很簡單？哨兵的“競選大會”來了！
當 master 被判定 ODOWN 後，哨兵會啓動 failover 流程。流程就像一場嚴格的競選：
1、挑選健康的 slave
- 數據同步最好
- 與主節點延遲最小
- 網絡狀態最好
有點像：誰的手藝最像店長？誰最靠譜？
2、讓候選 slave 執行 slaveof no one
這一步很關鍵！它意味着：“我不是店員了，我現在升職當店長！”
3、重新配置剩餘的 slave
指令：SLAVEOF 新master
意思是：“以後你們都跟着新店長學手藝。”
4、通知所有客户端
以前的客户端都連接舊 master。現在哨兵會告訴客户端：“master 換人了，地址在這裏，去找新店長點單吧！”
整個過程自動完成，無需人工干預。
重點來了：哨兵集羣怎麼工作？
要保證哨兵模式可靠，必須部署多個 Sentinel 節點。為什麼？
因為一個哨兵説 master 感覺掛了，不準。多個哨兵一起説 master 掛了，才會啓動 failover。
就像：
一個人説“店長暈了”，可能是看錯了；三個人都説“店長躺地板上了”，那八成是真的。
哨兵模式的架構：其實是“三層”
為了讓你徹底理解，我用最簡單的方式總結哨兵模式三層架構：
1、數據層：master + slave 結構
負責：
- 處理讀寫（master）
- 複製數據（slave）
2、 哨兵層：多個 Sentinel 組成集羣
負責：
- 監控 master/slave 狀態
- 選新 master
- 通知客户端
哨兵之間會互相通信，投票決定 master 是否宕機。
3、客户端層
客户端不再直接寫死 master 地址，而是：
- 連哨兵
- 哨兵告訴客户端真正的 master 是誰
- master 改變時，哨兵會通知你
這樣客户端自動適應故障恢復，非常穩。
面試問：哨兵模式有什麼缺點？
這是高頻問題，我給你總結成三句話，面試官聽完會很滿意。
1、Redis 哨兵模式仍存在腦裂風險
如果網絡分區，可能出現：
- A 以為 master 掛了，選一個 slave 做新 master
- 但舊 master 實際還活着
就出現兩個 master（腦裂）。
2、不支持水平擴展寫操作
哨兵模式仍然只有一個 master，寫能力受限。
3、可靠性比集羣模式弱
哨兵能解決“高可用”，不能解決“數據分片、擴容”問題。
哨兵和集羣有什麼區別？
如果你在面試現場回答下面這句話，面試官會瘋狂點頭：
Sentinel 負責“高可用”；
Redis Cluster 負責“高可用 + 分片 + 擴展”。
前者是保護 master，不讓它宕機；
後者是讓數據可以橫向擴展。
一句話就區分了。
哨兵模式典型部署方式（面試官超愛問）
最常見的是：
- 1 主 2 從
- 3~5 個 Sentinel
一個參考部署：
master（1台）
slave（2台）
sentinel（3台）
Sentinel 必須是奇數個，因為投票要多數同意才“客觀下線”。
面試官問你為什麼要奇數個，你就説：
因為哨兵是投票機制，必須多數派決定才能 failover，奇數能避免平票。
完美！
哨兵模式的完整工作流程（面試官最喜歡）
我幫你總結成“六步口訣”——面試答題直接背！
Redis 哨兵模式 六步口訣
- sentinel 監控 master
- master 無心跳 → 主觀下線 SDOWN
- 多數 sentinel 投票 → 客觀下線 ODOWN
- 選 slave 當新 master
- 通知所有 slave 重新跟隨新 master
- 通知客户端：新的 master 地址是誰
這套邏輯你能流利描述出來，這道題基本穩了。
我朋友面試最終怎麼樣了？
第二天，我朋友去面試。面試官果然問了：“你講一下 Redis 哨兵模式？”
朋友立刻把奶茶故事搬出來——從監控、選主、投票、failover，一路講得順溜爆炸。
面試官聽得連連點頭：“不錯，講得很清楚。”
最終他也順利拿到了 offer。後來他發消息給我，説：“哨兵模式，我現在講給 HR 聽都能聽懂。”
我笑了半天。
END
如果你需要在簡短面試裏速答，可以用下面這段話，邏輯清晰、要點齊全：
Redis 哨兵模式是一種實現 Redis 高可用的機制。
它由多個 Sentinel 節點組成，負責監控 master 和 slave 的狀態。
一旦 master 進入客觀下線狀態，Sentinel 會通過投票選舉一個最佳 slave 作為新 master，並通知其他 slave 重新複製它，也會把新 master 的信息通知客户端。
Sentinel 的核心功能包括：監控、故障轉移、通知。
它解決了 Redis 單點故障問題，但仍然只有一個 master，不支持分片，因此可用性不如 Redis Cluster。
Sentinel 推薦部署奇數個節點，通過多數派選舉避免誤判。
我是小米，一個喜歡分享技術的31歲程序員。如果你喜歡我的文章，歡迎關注我的微信公眾號“軟件求生”，獲取更多技術乾貨！
