文章目录
- 哨兵节点作用演示
- 模拟
- 哨兵重选主节点流程
- 1 . **主观下线**
- 2 . **客观下线**
- 3 . **投出 `leader`**
- 4 . **leader 挑选主节点**
哨兵节点作用演示
哨兵存在的意义:能够在 redis
主从结构出现问题的时候(比如主节点挂了),此时哨兵节点就能帮我们选出一个主节点,来代替之前挂了的节点,保证整个 redis
仍然是可用状态
查看各节点状态 docker ps -a
模拟
我们模拟一下主节点挂了的情况。手动干掉主节点 docker stop redis-master
- 当主节点挂了之后,哨兵节点就开始工作了
- 我们看一下哨兵节点的日志
- 哨兵发现当前
redis-master
是一个sdown
状态,于是开始投票sdown
:主观下线,本哨兵认为,主节点挂了(单方面)
- 出现
+odown
状态+odown
:客观下线,好几个哨兵都认为,主节点挂了,达成一致(法定票数)- 此时,这个主节点挂了的事情就石锤了
- 此时就需要哨兵节点选出一个从节点,作为新的主节点,此处就要提拔出一个新的主节点
switch
:进行切换,从0.2
切换到了0.4
我们尝试练一下原来的主节点,端口号为:6379
- 我们发现连接不上去(因为挂了)
再连一下 6380
- 连上去后发现这个节点就是被提拔的主节点
再连一下 6381
我们重启原来的主节点 redis-master
之后
- 此时还是从节点,他已经失去了主节点这个身份
哨兵重选主节点流程
#高频面试
1 . 主观下线
哨兵节点通过心跳包,判定 redis
服务器是否正常工作。如果心跳包没有如约而至,就说明 redis
服务器挂了
此时还不能排除网络波动的影响,因此就只能是单方面认为这个 redis
节点挂了
2 . 客观下线
多个哨兵都认为主节点挂了。认为挂了的哨兵数目达到法定票数,哨兵们就认为这个主节点是客观下线
是否可能出现非常严重的网络波动,导致所有的哨兵都联系不上
redis
主节点,误判成挂了呢?
- 当然是有的。如果出现这个情况,怕是用户的客户端也连不上
redis
主节点了- 此时这个主节点基本也就无法正常工作了
“挂了”不一定是进程崩了,只要是无法正常访问,都可以视为是挂了
3 . 投出 leader
让多个哨兵节点,选出一个 leader
节点,由这个 leader
负责选出一个从节点作为新的主节点
- 后面的编号,就是
sentinel1
的编号(在conf
配置文件里面可以看到) - 1 号哨兵立即给自己投了一票,推举自己成为
leader
- 三个哨兵都投给了哨兵 1
- 成为
leader
是要为大家服务的,当 1 号哨兵说他想为大家服务的时候,2 和 3 可能是纷纷举手赞成的(谁发现客观下线,谁就先给自己投) - 每个哨兵手里只有一票,当哨兵 1 第一个发现当前是客观下线之后,就立即给自己投一票,并且告诉了 2 和 3(2 和 3 当他们没有投出这个票的时候,收到拉票请求,就会投出去。如果有多个拉票请求,就回投给最先到达的),我来负责。2 和 3 反应慢了半拍,才发现是客观下线,一看 1 乐意负责这个事情,就立即投了赞成票
- 如果总的票数超过哨兵总数的一般,选举就完成了。哨兵个数设为奇数节点,就是为了方便投票
- 成为
上面投票过程,就是看谁反应快(网络延时小)
4 . leader 挑选主节点
此时 leader
选举完毕,leader
就要挑选一个从节点,作为新的主节点
-
优先级:每个
redis
数据节点,都会在配置文件中,有一个优先级的设置slave-priority
,不去改就都是一样的- 优先级高的从节点就会胜出
-
offset
:优先级一样,谁的offset
更大,就胜出- 从节点从主节点这边同步数据的进度。数值越大,就说明从节点的数据和主节点就越接近
-
run id
:优先级和offset
都一样,选run id
更小的(随机)- 每个
redis
节点启动的时候随机生成的一串数字,大小全凭缘分
- 每个
把新的主节点指定好之后,leader
就会控制这个节点,执行 slave no one
,成为 master
,再控制其他节点,执行 slave of
,让这些其他节点,以新的 master
作为主节点了