大家好，我是小米，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岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号"软件求生"，获取更多技术干货！