Redis实战：Redis哨兵机制

Redis哨兵

简单来说，Redis 哨兵（Sentinel）机制就是 Redis 的“自动维稳团队”

在普通的主从复制（Master-Slave）架构中，如果主节点（Master）挂了，系统是不会自动恢复的，需要运维人员半夜爬起来手动把一个从节点（Slave）切换为主节点。而哨兵机制，就是把这个“手动切换”的过程完全自动化

哨兵的核心职责

监控： 哨兵会不断地给主节点和从节点发送 PING 命令，看看它们是不是还活着。

通知： 如果发现某个节点出问题了，哨兵可以通过 API 通知管理员或者其他应用程序。

自动故障转移： （最核心的功能） 当主节点真的挂了，哨兵们会开会投票，从未节点里选出一个优秀的“提拔”为新主节点。

配置提供者： 客户端（你的业务代码）不再直接连接固定的 Redis 主节点 IP，而是先连接哨兵。哨兵会告诉客户端：“当前谁是主节点，你们往哪读写。”

故障转移是怎么发生的？

这个过程非常严谨，为了防止“误判”（比如某个哨兵自己网络卡了一下，误以为主节点挂了），哨兵采用了“民主投票制”，主要分为三个步骤：

第一步：主观下线 vs 客观下线

主观下线： 单个哨兵发现主节点 PING 不通了，它自己认为主节点挂了。

客观下线： 发现主节点挂了的哨兵会去询问其他哨兵。如果有足够数量（这个数量叫 Quorum，通常配置为哨兵总数的一半以上）的哨兵都认为主节点挂了，这时候主节点才被判定为“客观下线”。

第二步：选出“班长”（Leader 选举）

主节点确定挂了后，哨兵们要开始干活了。但不能大家都去指挥，容易乱套。所以它们会通过 Raft 协议 类似的机制，在内部选出一个“领头哨兵”（Leader）来具体执行换主节点的任务

第三步：挑选新主节点（Failover）

当选择主节点的时候，并不是随便选择一个从节点让其变成主节点，而是通过一定的策略筛选出来的，筛选策略主要分为2个阶段

淘汰阶段：去掉网络状况不好的从节点，例如断开连接，上一次正常回复ping距当前时间超过5s等

筛选阶段：剩下的节点中选优先级高的（slave-priority 数值越小，优先级越高），优先级相同选复制偏移量大的，复制偏移量相同，选runId小的（每个redis实例启动都会分配一个全局唯一的runId）

具体筛选淘汰策略参见sentinel.c/sentinelSelectSlave

选出新主节点后，哨兵会向它发送 SLAVEOF NO ONE 让其自立门户，并通知其他从节点向新主节点“拜码头”同步数据

流程演示