详解Redis哨兵模式下,主节点掉线而重新选取主节点的流程

⭐最核心的结论:所谓选举的过程不是直接选出新的主节点,而是先在哨兵节点中选出 leader ,再由 leader 负责后续主节点的指定。


假定当前环境:

  • 三个哨兵(sentenal1, sentenal2, sentenal3)
  • 一个主节点(redis-master)
  • 两个从节点(redis-slave1, redis-slave2)

当主节点出现故障,就会触发以下一系列过程:

目录

一、判定主观下线

二、判定客观下线

三、选举出哨兵的 leader

1、每个哨兵节点都给其他所有哨兵节点发起⼀个 “拉票请求”。

2、收到拉票请求的节点会回复⼀个 “投票响应”,响应的结果有两种可能,即投 or 不投。

3、一轮投票完成之后,得票超过半数的哨兵节点将动成为 leader。

***选举leader的流程演示:

4、leader 节点负责挑选一个 slave 成为新的 master。

四、由leader挑选一个从节点作为新的主节点

挑选的规则

*哨兵节点的作用演示 


一、判定主观下线

哨兵节点通过心跳包判定 redis-master 服务器是否正常工作。如果心跳包没有如约而至,那么这个哨兵节点就会认为 redis-master 服务器挂了,这就是主观下线(SDown)。

注意,此时在在某一个哨兵节点的角度,还不能排除网络波动的对心跳包丢失的影响,所以只能是该哨兵节点单方面认为这个 redis-master 节点挂了,是“主观”的。


二、判定客观下线

此时,哨兵 sentenal1,sentenal2,sentenal3 均会对主节点故障这件事情进行投票。当故障得票数 >= 配置的法定票数之后,哨兵们就认为这个主节点确实挂了,即触发客观下线(ODown)。

法定票数可以在哨兵节点的配置文件中查看:

sentinel1.conf是哨兵节点sentinel1的配置文件

有些同学可能会有疑问,是否存在一种情况:出现非常严重的网络波动,导致所有的哨兵都联系不上 redis 主节点从而“误判”成主节点挂了呢?

当然是有的!然而,如果出现这个情况,怕是连用户的客户端也连不上 redis 主节点了,此时这个redis主节点基本也是无法正常工作的。

注意,“挂了”不一定指的就是进程崩了。只要无法正常访问主节点,都可以视为是主节点挂了。


三、选举出哨兵的 leader

接下来需要哨兵把剩余的 slave 中挑选出⼀个新的 master。

这个工作不需要所有的哨兵都参与,只需要选出个代表(称为 leader),由 leader 负责进行 slave 升级到 master 的提拔过程。这个选举的过程涉及到 Raft 算法

假定⼀共三个哨兵节点 S1,S2,S3:

1、每个哨兵节点都给其他所有哨兵节点发起⼀个 “拉票请求”。

即 S1 -> S2,S1 -> S3;S2 -> S1,S2 -> S3;S3 -> S1,S3 -> S2。

2、收到拉票请求的节点会回复⼀个 “投票响应”,响应的结果有两种可能,即投 or 不投。

比如 S1 给 S2 发了投票请求,S2 就会给 S1 返回投票响应。S2 是否要投 S1 ,取决于 S2 是否给别人投过票了. (每个哨兵只有一票). 如果 S2 没有给别人投过票,也就是说 S1 是第一个向 S2 拉票的,那么 S2 就会投 S1,否则则不投。

3、一轮投票完成之后,得票超过半数的哨兵节点将动成为 leader。

如果出现平票的情况 (如 S1 投 S2,S2 投 S3,S3 投 S1,每人一票),就重新再投一次。

这也是一般建议哨兵节点设置成奇数个的原因:如果是偶数个,就增大了平票的概率,从而带来不必要的开销。

***选举leader的流程演示:

leader选举总结:Raft 算法的核心是 “先下手为强”,谁率先发出了拉票请求,谁就有更大的概率成为 leader。这里的决定因素是 “网络延时”,网络延时本身就带有一定的随机性。

4、leader 节点负责挑选一个 slave 成为新的 master。

当其他的 sentenal 发现新的 master 出现了, 就说明选举结束了。


四、由leader挑选一个从节点作为新的主节点

举个栗子:

假设一个情景:学校里有一位任课老师请假不能来给学生上课,需要由别的任课老师从众多助教老师中选择一位来代替他上课。 

  • 任课老师有很多,谁来当负责人来负责挑选合适的助教老师?  ——即众多哨兵节点选举leader的过程。
  • 如何怎样的助教老师是合适的?  ——即由leader哨兵节点从所有redis-slave节点中选择一个作为新的redis-master的过程。(接下来介绍的)

挑选的规则

leader如何挑选新的主节点?按照优先级 > offset > run id的次序依次筛选:

  1. 优先级最高的从节点胜出。每个redis数据节点都会在配置文件中有一个优先级配置(slave-priority,默认情况下都相同)。【某个助教老师是校长钦定的,那就选他代替上课。】

  2. offset最大的从节点胜出。offset代表从节点从主节点这里同步数据的进度。数值越大,说明从节点的数据和主节点就越接近。【哪个助教老师的备课进度更多,哪个助教老师就来代替上课。】

  3. run id值更小的胜出。run id是每个redis节点启动的时候随机生成的一串数字(大小全凭缘分)。此时意味着优先级和offset都一样,那么选谁都可以,其实就是随便挑一个。【看哪个助教老师名字好听,就选谁来代替上课。】

把新的主节点指定好了之后:

  1. leader就会控制这个这个节点执行slave no one,成为 master;
  2. 再控制其他节点执行 slave of,让这些其他节点认新的 master 为主节点。

*哨兵节点的作用演示 

我们知道,哨兵存在的意义是,在redis主从结构出现问题(比如主节点挂了)时,哨兵节点能够自动重选出一个新的主节点来代替之前挂了的主节点,从而保证整个 redis 仍然是可用状态。

以下是在centos7上,采用docker配置了3个redis数据节点(1个redis-master,2个redis-slave)和3个哨兵节点(redis-sentinel)后的演示过程:

1、首先查看正在运行的容器:docker ps -a

可见所有容器都已启动

2、手动停止主节点,模拟主节点掉线:docker stop redis-master

手动停止redis-master后,再次查看docker运行情况,可见redis-master已停止运行

3、 此时主节点已经是退出状态。事实上当主节点挂了后,哨兵节点就已经开始工作了。查看哨兵节点的日志:docker-compose logs

4、此时连接6379(即刚才手动下线了的主节点),发现连不上,证明原来的主节点确实已经下线:

5、改连redis节点6380,连接成功并查询信息发现,6380仍然是一个slave节点,且其主节点IP已经成为了172.18.0.3(而不再是原来的172.18.0.2):

6、6380无法设置值(只读),说明它确实仍然是一个从节点:

7、退出6380,再连接redis节点6381,查看info replication发现,本来是从节点的6381已经变成了主节点:

8、此时也就可以顺利地在6381上进行值的写入操作,进一步证明6381已经具备了主节点的功能:

9、此时如果再把原来挂了的主节点6379恢复正常,虽然6379恢复上线,但它的主节点身份在挂了的时候就失去了,已经变成了一个从节点,即使重新启动也不会变回主节点:

10、查看当前新主节点6381的信息,可见现在有两个从节点(6380和6379)连接在它身上:

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值