Redis哨兵sentinel深入分析

Redis哨兵sentinel深入分析

哨兵sentinel的三大功能监控、选举、故障转移（包含通知）下面来具体分析。

监控

监控其实就是哨兵实例定时向Redis的主从集群发送PING命令，检测主从节点的心跳，一旦主节点的回复时间超过了sentinel.conf配置的down-after-milliseconds值，哨兵实例就会将这个实例主观下线，为避免哨兵节点的误判该哨兵节点向哨兵集群中的其它哨兵节点发送is-master-down-by-addr命令 ，其它哨兵节点根据自身和主节点的连接情况给出判断，==只有判断主观下线数量大于或等于哨兵配置的quorum值==（具体配置如下），才能将主节点实例由主观下线改为客观下线。

-- quorum指同意主节点客观下线的sentinel哨兵个数
sentinel monitor     

哨兵间通信

判断主节点客观下线必须哨兵间互相通信，但哨兵配置文件sentinel.conf中并没有指定其它哨兵的配置，也没有类似主从节点指定的replicaof命令，那么哨兵间如何通信呢？答案是消息订阅发布，新加入的哨兵通过向主节点的__sentinel__:hello频道（主题）发送哨兵IP和端口，集群中所有的哨兵节点会向主节点订阅__sentinel__:hello频道（主题）这样就能实现哨兵间的相互发现和通信，结构图如下所示。

选举

哨兵确定了主节点客观下线后那么哨兵节点需要开启选举流程，选取一个新的主节点，选举主要是分为两步筛选和打分，这个步骤相对简单，筛选过程如下所示

故障迁移

故障迁移就是已经选出新的主库，现在要进行故障转移，故障转移需要一个哨兵完成，这时候又有一次选举，称为Leader选举，选出哨兵中的Leader，==当哨兵客观下线的赞成数量大于哨兵集群的一半同时大于或者等于哨兵配置的quorum数量==，这时就可以由此哨兵节点向哨兵集群其它节点发起Leader投票请求，如下所示。

如果最后哨兵A和哨兵C拿到的赞成票相同那么这轮投票不会有Leader产生，哨兵集群会等待一段时间（为故障转移超时时间的两倍）后重新发起请求，理由很简单哨兵间通信需要依赖网络如果网络故障可能会导致无法正常选举Leader，所以简单等待后再重新尝试可以提高成功率。

选出Leader后通过发布订阅功能，将更新后的主节点配置传播给其它哨兵节点让它们更新配置，其次还需要通知功能。

通知

通知的任务就是哨兵将新主节点的信息通知给从节点让其主从同步，通知给客户端让其后续请求走新的主节点。那么哨兵如何与从节点以及客户端通信呢？

哨兵获取从节点信息

哨兵和从库建立连接不单单只起通知作用，还会检测从节点的心跳等功能，其实在哨兵得到新主库信息后，可以直接向主节点发送INFO命令

哨兵通知客户端

哨兵选取新的主库后，不仅仅需要通知从节点主从同步，还需要和客户端通信，因为客户端发送请求还是在旧的主节点上，现在需要切换新的主节点，这时如何完成呢？这就和哨兵间的通信方式类似，同样通过发布订阅的方式，客户端可以从哨兵订阅消息， 哨兵提供的频道有很多以下列举常用的如下所示

客户端只需要向哨兵定于主库变更事件switch-master即可得到新主库的IP和端口，订阅命令如下

// 只订阅主库变更一个事件
SUBSCRIBE switch-master
// 订阅所有的事件
PSUBSCRIBE *