Redis-哨兵选取主节点流程

1.主观下线:

哨兵节点通过心跳包,判定redis服务器是否正常工作,若心跳包没有按时到达,说明redis服务器出现故障了. 此时还需要再进行判定,不能排除是网络波动的影响,认为redis节点的出现故障.

2.客观下线:

当多个哨兵节点都认为主节点出现故障了(认为主节点出现故障的哨兵节点数目达到法定票数),就认为该主节点确实是下线了.

3.选取leader哨兵节点:

当主节点出现故障后,哨兵节点就要采取措施补救,先从哨兵节点集合中选出一个leader哨兵节点,由这个leader哨兵节点后续的主节点替换和后续工作.

选取leader流程:

每个哨兵节点只有一票的选举权,最先判断到主节点确实出故障的哨兵节点会先给自己投一票,然后,别的哨兵节点发现有哨兵节点已经获得了票,就会将票投给他,也就是延迟性最小的节点最可能会成为leader节点.

这里也是为什么强调要将哨兵节点个数设成单数个的原因,减少了两个节点都获取到相同的票数的情况.

4.选取新主节点:

leader选取完后,就要开始选取一个从节点作为主节点,选取依据:

1>.优先级: 每个redis节点都会在配置文件中有一个优先级的设置 slave-priority,优先级高的节点更会被选取为主节点.

2>.offset: offset大的更会被选取;offset越大.说明从节点和主节点同步的进度越相近,数据越相近.

3>.runId: 每个redis节点启动的时候都会随机生成一个数字串runId,当从节点的优先级和offset都相同时,就会随机选取一个,指定为主节点了.

5.执行主从替换:

1>. leader会控制选取的新的主节点执行slaveof no one命令,让自己成为主节点;

2>. 让剩余从节点执行slaveof  ip  port命令.进行主节点切换;

3>. 再通知客户端程序,告知新的主节点,后续读写操作在新的主节点上执行.

哨兵节点并不存储数据,只是监控作用,并且在实际开发中,必须将其部署在不同的机器上,否则当机器出故障时,所有的哨兵节点就会全军覆膜了.是无法发挥作用的.