【redis】哨兵节点作用演示和重选主节点详细流程

哨兵节点作用演示

哨兵存在的意义：能够在 redis 主从结构出现问题的时候（比如主节点挂了），此时哨兵节点就能帮我们选出一个主节点，来代替之前挂了的节点，保证整个 redis 仍然是可用状态

查看各节点状态 docker ps -a

image.png

模拟

我们模拟一下主节点挂了的情况。手动干掉主节点 docker stop redis-master

image.png

• 当主节点挂了之后，哨兵节点就开始工作了
• 我们看一下哨兵节点的日志

image.png

1. 哨兵发现当前 redis-master 是一个 sdown 状态，于是开始投票
   • sdown：主观下线，本哨兵认为，主节点挂了（单方面）
2. 出现 +odown 状态
   • +odown：客观下线，好几个哨兵都认为，主节点挂了，达成一致（法定票数）
   • 此时，这个主节点挂了的事情就石锤了
3. 此时就需要哨兵节点选出一个从节点，作为新的主节点，此处就要提拔出一个新的主节点
   • switch：进行切换，从 0.2 切换到了 0.4

我们尝试练一下原来的主节点，端口号为：6379

image.png

• 我们发现连接不上去（因为挂了）

再连一下 6380

image.png|418

• 连上去后发现这个节点就是被提拔的主节点

再连一下 6381

image.png|325

我们重启原来的主节点 redis-master 之后

image.png

• 此时还是从节点，他已经失去了主节点这个身份

哨兵重选主节点流程

#高频面试

1 . 主观下线

哨兵节点通过心跳包，判定 redis 服务器是否正常工作。如果心跳包没有如约而至，就说明 redis 服务器挂了

此时还不能排除网络波动的影响，因此就只能是单方面认为这个 redis 节点挂了

2 . 客观下线

多个哨兵都认为主节点挂了。认为挂了的哨兵数目达到法定票数，哨兵们就认为这个主节点是客观下线

是否可能出现非常严重的网络波动，导致所有的哨兵都联系不上 redis 主节点，误判成挂了呢？

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

“挂了”不一定是进程崩了，只要是无法正常访问，都可以视为是挂了

3 . 投出 leader

让多个哨兵节点，选出一个 leader 节点，由这个 leader 负责选出一个从节点作为新的主节点

image.png

• 后面的编号，就是 sentinel1 的编号（在 conf 配置文件里面可以看到）
• 1 号哨兵立即给自己投了一票，推举自己成为 leader
• 三个哨兵都投给了哨兵 1

image.png

• 成为 leader 是要为大家服务的，当 1 号哨兵说他想为大家服务的时候，2 和 3 可能是纷纷举手赞成的（谁发现客观下线，谁就先给自己投）
• 每个哨兵手里只有一票，当哨兵 1 第一个发现当前是客观下线之后，就立即给自己投一票，并且告诉了 2 和 3（2 和 3 当他们没有投出这个票的时候，收到拉票请求，就会投出去。如果有多个拉票请求，就回投给最先到达的），我来负责。2 和 3 反应慢了半拍，才发现是客观下线，一看 1 乐意负责这个事情，就立即投了赞成票
• 如果总的票数超过哨兵总数的一般，选举就完成了。哨兵个数设为奇数节点，就是为了方便投票

上面投票过程，就是看谁反应快（网络延时小）

4 . leader 挑选主节点

此时 leader 选举完毕，leader 就要挑选一个从节点，作为新的主节点

1. 优先级：每个 redis 数据节点，都会在配置文件中，有一个优先级的设置
   • slave-priority，不去改就都是一样的
   • 优先级高的从节点就会胜出
2. offset：优先级一样，谁的 offset 更大，就胜出
   • 从节点从主节点这边同步数据的进度。数值越大，就说明从节点的数据和主节点就越接近
3. run id：优先级和 offset 都一样，选 run id 更小的（随机）
   • 每个 redis 节点启动的时候随机生成的一串数字，大小全凭缘分

把新的主节点指定好之后，leader 就会控制这个节点，执行 slave no one，成为 master，再控制其他节点，执行 slave of，让这些其他节点，以新的 master 作为主节点了