Redis源码解析：Redis哨兵机制

手写一个监控程序

我是个苦逼的运维，最近公司的redis主从服务不太稳定，主节点老是无缘无故挂掉，害得我老是半夜起来手动切换主节点，这样下去可不行，我得写个监控脚本帮我干这个活

首先我先连上所有的主从节点，每隔1s发送ping命令

redis-cli -h 10.25.0.0 -p 6379
redis-cli -h 10.25.0.1 -p 6379
redis-cli -h 10.25.0.2 -p 6379
redis-cli -h 10.25.0.3 -p 6379

如果主节点没有响应，我就随便挑一个从节点执行 slaveof no one 命令，就 10.25.0.1 这个节点吧。

10.232.0.3:6379> info
...
role:master

然后执行info命令，当info命令显示这个节点的角色为master时，依次对其他从节点执行 slaveof 10.25.0.1 让其从 10.25.0.1 复制数据

当然挂掉的主节点不能不管不顾，当它复活的时候，也要对其执行 slaveof 10.25.0.1 让其从 10.25.0.1 复制数据，不愧是我

于是这个监控就开始愉快的运行了，终于可以踏实的睡几天觉了。

过了几天，没想到主节点挂了之后没能正常切换，原来是我的监控程序挂了。

又过了几天，服务又不稳定了，监控程序老是频繁的切换主节点，但是主节点并没有问题，原来是我这个监控程序和主节点的网络不太稳定，让监控程序误认为主节点挂了。

面对大家对Redis主从节点自动切换的需求越来越强烈，Redis官方也坐不下去了，索性自己写了一个监控程序，并且把这个监控程序叫做哨兵！

Redis中的哨兵是如何工作的？

作为一个官方的程序，上面我们遇到的问题肯定都会被解决，我们来看看哨兵是如何解决的

监测流程

首先为了解决哨兵宕机不能正常进行切换的问题，我们可以对哨兵搭建一个集群，每个哨兵都监测主从节点，当主节点不可用时，选一个正常的哨兵进行主从切换

master端的info信息

slave端的info信息

故障转移流程

上面我们自己写的监测程序与Redis节点网络不稳定时，会频繁进行切换。为了解决这个问题，Redis引入了2个概念

主观下线：当前哨兵程序认为主节点宕机了，具有很强的主观性，有可能是因为网络的问题

客观下线：大多数哨兵程序认为主节点宕机了，那主节点很大概率宕机了，应该进行主从切换了

当有多个哨兵程序时，应该让哪个哨兵程序来执行主从切换呢？

多个哨兵会根据分布式共识协议，Raft协议，来选出领头哨兵，让其执行主从切换
当选择主节点的时候，并不是随便选择一个从节点让其变成主节点，而是通过一定的策略筛选出来的，筛选策略主要分为2个阶段

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

筛选阶段：在剩下的从节点中先选优先级小的（在redis.conf给每台机器配置了优先级），优先级相同选复制偏移量大的，复制偏移量相同，选runId小的（每个redis实例启动都会分配一个全局唯一的runId）

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

参考博客

[1]https://www.cnblogs.com/flashsun/p/14692643.html
比较好的源码
[2]http://blog.wudan3551.top/2021/12/10/redis_high_availability/
比较详细的一篇文章
[3]https://www.cnblogs.com/kevingrace/p/9004460.html