Redis 哨兵（Sentinel）底层实现原理的课程笔记进行了重新梳理、排版与精简，形成了一篇结构清晰、重点突出的技术文章。
彻底搞透 Redis 哨兵底层实现原理
本篇笔记将从核心问题、功能作用、底层监控、故障转移与恢复四个维度，带你彻底搞懂 Redis 哨兵模式的底层实现机制。
一、 Redis 哨兵模式概述
1. 解决什么问题？
Redis 哨兵是一个独立运行的进程，用于监控多个主从（Master-Slave）集群。其核心目的是实现自动化监控与故障切换，当 Master 节点宕机时，能够自动将 Slave 节点提升为新的 Master 节点。
2. 核心功能
- 监控（Monitoring）：负责持续监控 Redis Master 和 Slave 进程是否正常工作。
- 通知（Notification）：当 Redis 实例发生故障时，发送报警通知给管理员。
- 自动故障转移（Automatic Failover）：如果 Master 节点挂掉，自动将其转移到 Slave 节点上。
- 配置提供者（Configuration Provider）：当故障转移发生时，通知客户端更新新的 Master 地址。
通俗理解（武当派比喻） ：
Redis 主从架构好比武当派，掌门人就是 Master 。掌门如果挂了，需要从武当七侠（Slave）中选举新掌门。这就需要一个"哨兵部门"来监控生死、通过投票选举能者，最后召开新闻发布会向世界宣布新掌门信息。
二、 Redis 哨兵监控的底层实现
1. 监控实现机制
哨兵通过 PING 命令定时检测 Master 和 Slave 的生命状态。
- 每 10 秒 向主节点和从节点发送
INFO命令，用于获取最新的主从拓扑关系。
2. 询问消息与发布订阅
- 实现原理 ：利用 Sentinel 内置的 Pub/Sub（发布订阅） 机制来实现。
- 解决问题：发现新的 Sentinel 节点，并与其他哨兵节点交换 Master 的状态信息。
- Publish：发布自身掌握的节点状态信息。
- Subscribe：接受其他哨兵节点广播的信息。
三、 Redis 故障转移与下线机制
1. 主观下线（Subjective Down, SDown）
- 检测方式 ：哨兵利用 PING 命令检测 Master/Slave 状态。若收到无效回复，则标记为主观下线（
flags=SRI_S_DOWN）。 - 配置文件参考：
text
sentinel down-after-milliseconds mymaster 30000- 为什么需要集群？
单个哨兵容易受到自身网络拥塞或主库高负载的影响而产生误判。因此，引入多个哨兵实例组成集群，通过多方决策来降低误判率。
2. 客观下线（Objective Down, ODown）
- 实现原理 ：当某个哨兵判定主观下线后，会向其他哨兵节点发送询问请求：
sentinel is-master-down-by-addr。 - 过半机制（Quorum）：当达到指定数量的哨兵都认为 Master 已经下线时，才会最终判定 Master 为「客观下线」，进而触发故障转移流程。
- 法定数量配置示例：
text
sentinel monitor mymaster 127.0.0.1 6379 2sentinel monitor：代表监控指令。mymaster：主节点自定义名称。127.0.0.1 6379：主节点的 IP 与端口。2：法定数量（Quorum）。代表至少需要 2 个 哨兵实例认为主节点不可用，才会触发failover操作。- 标准公式 ：当有 NNN 个哨兵实例时，必须有 N2+1\frac{N}{2} + 12N+1 个实例判断为主观下线，才能最终判定为客观下线。
四、 故障恢复流程与实现
1. 选举领头哨兵
当 Master 被判定为客观下线后，哨兵集群需要选出一个"领头哨兵"来全权负责故障转移工作，这个过程采用 Raft 算法实现领导者选举。
2. 故障转移核心步骤
领头哨兵被选出后，将按以下步骤完成主从切换：
-
选举出新的 Slave 节点：
- 过滤掉掉线、响应慢的节点。
- 选择从节点优先级最高 （
slave-priority）的节点。 - 若优先级相同，选择复制偏移量最大（数据最完整）的节点。
- 若仍相同，选择 Run ID 最小的节点。
-
升级 Slave ：通过
SLAVEOF NO ONE命令将选中的 Slave 升级为主节点。 -
构建新集群结构：让其余的 Slave 节点去复制新的 Master 节点，并通知客户端更新连接地址。