在 Redis 高可用架构中，哨兵（Sentinel） 扮演着至关重要的角色。它不仅能自动监控主从节点状态，还能在主节点故障时完成自动切换，保障服务持续可用。本文将系统梳理 Sentinel 的核心机制。
一、哨兵的作用
Redis Sentinel 主要提供以下三大能力：
- 状态监控：持续检查 master/slave 健康状态
- 自动故障转移：master 宕机时，自动选举新 master 并重配置集群
- 服务发现：客户端可通过哨兵查询当前 master 地址
💡 注意：Sentinel 不负责数据存储，仅用于管理与协调。
二、状态监控与故障判定
Sentinel 是怎么知道 Redis 节点宕机的？
Sentinel 通过一套严谨的心跳 + 投票机制判断节点是否真正失效：
-
心跳检测
默认每 1 秒向所有 Redis 节点发送
PING命令。若在down-after-milliseconds（默认 30 秒）内未收到有效响应，则该哨兵将节点标记为 主观下线（SDOWN）。 -
主观下线（SDOWN）
单个哨兵认为节点不可用，但不足以触发故障转移。
-
客观下线（ODOWN）
当 ≥
quorum个哨兵 都报告 SDOWN 时，Sentinel 集群将该 master 标记为 客观下线（ODOWN），正式进入故障恢复流程。
✅ 关键提示 ：
quorum仅用于判定 ODOWN，Leader 选举仍需获得多数派支持（> N/2） 。例如 3 个哨兵，quorum=2可触发 ODOWN，但选 Leader 仍需至少 2 票。
三、故障恢复：选举新主
一旦 master 被标记为 ODOWN，Sentinel 就会在 slave 中选举新的主节点。
选主前过滤
并非所有 slave 都有资格参选，首先排除以下两类：
replica-priority = 0的 slave（明确禁止晋升）- 与原 master 断连时间过长的 slave（数据太旧，可能丢失大量写入）
选主标准（按优先级排序）
满足基本条件后，按以下顺序择优：
replica-priority越小越优（默认 100，0 表示不参选）- 复制偏移量（offset）越大越优（代表数据最新）
run_id字典序越小越优（作为随机兜底，避免平票）
四、哨兵 Leader 选举
故障转移操作只能由一个哨兵执行，因此需要先选出 Leader。
成为 Leader 的条件
- 获得 超过半数 哨兵的投票
- 得票数 不少于
quorum
投票原则
- 优先投票给当前得票最多的候选者
- 若无人领先，则投给自己
⚠️ 常见误解：
"谁先发现 master 下线，谁就当 Leader" ------ 这是错误的！
实际采用类似 Raft 的共识机制，需经过一轮正式投票，不是"先到先得"。
五、状态通知与重配置
Leader 选出后，开始执行故障转移的重配置流程：
-
向新 master 发送命令：
Redis 4.0 及以下
SLAVEOF no oneRedis 5.0 及以上
REPLICAOF no one -
向其他 slave 发送命令：
Redis 4.0 及以下
SLAVEOF<new_master_ip> <port>Redis 5.0 及以上
REPLICAOF <new_master_ip> <port> -
原 master 重启后 ：
Sentinel 会主动连接它，并发送
REPLICAOF <new_master>，将其降级为 slave。🔒 重要 ：不会修改其
redis.conf配置文件，角色切换完全通过运行时指令完成。 -
通知客户端：
-
通过 Pub/Sub 发布
+switch-master事件 -
客户端可调用 API 查询：
bashSENTINEL get-master-addr-by-name mymaster
-
六、最佳实践建议
为确保 Sentinel 稳定可靠，推荐遵循以下原则：
- 部署 ≥ 3 个哨兵（奇数），避免脑裂
- 合理设置
down-after-milliseconds（如 10s~30s）和quorum - 客户端必须通过 Sentinel 获取 master 地址，禁止直连 Redis 节点
- 监控哨兵日志，关注
+switch-master、+sdown等关键事件
✅ 总结 ：
Redis Sentinel 通过"监控 → 判定 → 选举 → 通知"四步闭环，实现了 Redis 主从架构的自动高可用。理解其原理，是构建稳定缓存系统的基石。
作者：不会写程序的未来程序员
首发于 CSDN 欢迎点赞、收藏、评论交流！
版权声明：本文为原创文章，转载请注明出处。