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 状态。若收到无效回复则标记为主观下线flagsSRI_S_DOWN。配置文件参考sentinel down-after-milliseconds mymaster 30000为什么需要集群单个哨兵容易受到自身网络拥塞或主库高负载的影响而产生误判。因此引入多个哨兵实例组成集群通过多方决策来降低误判率。2. 客观下线Objective Down, ODown实现原理当某个哨兵判定主观下线后会向其他哨兵节点发送询问请求sentinel is-master-down-by-addr。过半机制Quorum当达到指定数量的哨兵都认为 Master 已经下线时才会最终判定 Master 为「客观下线」进而触发故障转移流程。法定数量配置示例sentinel monitor mymaster 127.0.0.1 6379 2sentinel monitor代表监控指令。mymaster主节点自定义名称。127.0.0.1 6379主节点的 IP 与端口。2法定数量Quorum。代表至少需要2 个哨兵实例认为主节点不可用才会触发failover操作。标准公式当有NNN个哨兵实例时必须有N21\frac{N}{2} 12N​1个实例判断为主观下线才能最终判定为客观下线。四、 故障恢复流程与实现1. 选举领头哨兵当 Master 被判定为客观下线后哨兵集群需要选出一个“领头哨兵”来全权负责故障转移工作这个过程采用Raft 算法实现领导者选举。2. 故障转移核心步骤领头哨兵被选出后将按以下步骤完成主从切换选举出新的 Slave 节点过滤掉掉线、响应慢的节点。选择从节点优先级最高slave-priority的节点。若优先级相同选择复制偏移量最大数据最完整的节点。若仍相同选择Run ID 最小的节点。升级 Slave通过SLAVEOF NO ONE命令将选中的 Slave 升级为主节点。构建新集群结构让其余的 Slave 节点去复制新的 Master 节点并通知客户端更新连接地址。