详解redis sentinel(哨兵模式)的原理和机制

三个定时任务

sentinel在内部有3个定时任务redis

1.每10秒每一个sentinel会对master和slave执行info命令网络

这个任务达到两个目的:spa

1.发现slave节点ip

2.确认主从关系it

2.每2秒每一个sentinel经过master节点的channel交换信息(pub/sub)io

master节点上有一个发布订阅的频道(__sentinel__:hello)。ast

sentinel节点经过__sentinel__:hello频道进行信息交换(对节点的"见解"和自身的信息),达成共识。监控

3.每1秒每一个sentinel对其余sentinel和redis节点执行ping操做(相互监控)配置

这个实际上是一个心跳检测,是失败断定的依据。定时任务

主观下线和客观下线

在redis-sentinel的conf文件里有这么两个配置:

1.sentinel monitor <masterName> <ip> <port> <quorum>

四个参数含义:

masterName这个是对某个master+slave组合的一个区分标识(一套sentinel是能够监听多套master+slave这样的组合的)。

ip 和 port 就是master节点的 ip 和 端口号。

quorum这个参数是进行客观下线的一个依据,意思是至少有 quorum 个sentinel主观的认为这个master有故障,才会对这个master进行下线以及故障转移。由于有的时候,某个sentinel节点可能由于自身网络缘由,致使没法链接master,而此时master并无出现故障,因此这就须要多个sentinel都一致认为该master有问题,才能够进行下一步操做,这就保证了公平性和高可用。

2.sentinel down-after-milliseconds <masterName> <timeout> 

这个配置其实就是进行主观下线的一个依据,masterName这个参数不用说了,timeout是一个毫秒值,表示:若是这台sentinel超过timeout这个时间都没法连通master包括slave(slave不须要客观下线,由于不须要故障转移)的话,就会主观认为该master已经下线(实际下线须要客观下线的判断经过才会下线)

那么,多个sentinel之间是如何达到共识的呢?

这就是依赖于前面说的第二个定时任务,某个sentinel先将master节点进行一个主观下线,而后会将这个断定经过sentinel is-master-down-by-addr这个命令问对应的节点是否也一样认为该addr的master节点要作客观下线。最后当达成这一共识的sentinel个数达到前面说的quorum设置的这个值时,就会对该master节点下线进行故障转移。quorum的值通常设置为sentinel个数的二分之一加1,例如3个sentinel就设置2

领导者选举

为何要选领导者?由于只能有一个sentinel节点去完成故障转移

sentinel is-master-down-by-addr这个命令有两个做用,一是确认下线断定,二是进行领导者选举。

选举过程:

1.每一个作主观下线的sentinel节点向其余sentinel节点发送上面那条命令,要求将它设置为领导者。

2.收到命令的sentinel节点若是尚未赞成过其余的sentinel发送的命令(还未投过票),那么就会赞成,不然拒绝。

3.若是该sentinel节点发现本身的票数已通过半且达到了quorum的值,就会成为领导者

4.若是这个过程出现多个sentinel成为领导者,则会等待一段时间从新选举。

故障转移

所谓故障转移就是当master宕机,选一个合适的slave来晋升为master的操做,redis-sentinel会自动完成这个,不须要咱们手动来实现。

那么,如何选择一个合适的slave呢?顺序以下:

1.选择slave-priority(slave节点优先级配置)最高的slave节点,(默认都是同样的)例如:若是咱们有两台slave在两台机器上,一台配置较高,咱们但愿当master挂掉优先选配置高的,就能够配置该值为slave中最高的。若是存在最高则返回,不存在继续

2.选择复制偏移量最大的节点(复制得最完整,与master节点的数据一致性更高),若是存在则返回,不存在继续

3.若是以上两个条件都不知足,选runId最小的(启动最先的)。

补充一点:还能够向任意sentinel发生sentinel failover <masterName> 进行手动故障转移,这样就不须要通过上述主客观和选举的过程。

相关文章
相关标签/搜索