4.2--Redis总结之高可用篇（关于哨兵机制）---（温故而知新篇）--加油呀

本文链接：https://blog.csdn.net/qq_51711443/article/details/129855371

1.为什么要有哨兵机制？

在 Redis 的主从架构中，由于主从模式是读写分离的，如果主节点挂了，那么将没有主节点来服务客户端的写操作请求，也没有主节点给从节点进行数据同步了

哨兵机制，它的作用是实现主从节点故障转移。

它会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。

2.哨兵机制是如何工作的？

哨兵是一个运行在特殊模式下的 Redis 进程，它也是一个节点。

从“哨兵”这个名字也可以看得出来，它相当于是“观察者节点”，观察的对象是主从节点。

哨兵节点主要负责三件事情：监控、选主、通知。

3.如何判断主节点真的故障了？

哨兵会每隔 1 秒给所有主从节点发送 PING 命令，当主从节点收到 PING 命令后，会发送一个响应命令给哨兵，这样就可以判断它们是否在正常运行。

如果主节点或者从节点没有在规定的时间内响应哨兵的 PING 命令，哨兵就会将它们标记为「主观下线」。这个「规定的时间」是配置项 down-after-milliseconds 参数设定的，单位是毫秒。

客观下线只适用于主节点，因为有可能「主节点」其实并没有故障，可能只是因为主节点的系统压力比较大或者网络发送了拥塞，导致主节点没有在规定时间内响应哨兵的 PING 命令。

为了减少误判的情况，用多个节点部署成哨兵集群（最少需要三台机器来部署哨兵集群），通过多个哨兵节点一起判断，就可以就可以避免单个哨兵因为自身网络状况不好，而误判主节点下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。

怎么判定主节点为「客观下线」的呢？

当一个哨兵判断主节点为「主观下线」后，就会向其他哨兵发起命令，其他哨兵收到这个命令后，就会根据自身和主节点的网络状况，做出赞成投票或者拒绝投票的响应。

当这个哨兵的赞同票数达到哨兵配置文件中的 quorum （法定人数）配置项设定的值后，这时主节点就会被该哨兵标记为「客观下线」。

PS：quorum 的值一般设置为哨兵个数的二分之一加1，例如 3 个哨兵就设置 2

4.由哪个哨兵进行主从故障转移？
需要在哨兵集群中选出一个 leader，让 leader 来执行主从切换

哪个哨兵节点判断主节点为「客观下线」，这个哨兵节点就是候选者，所谓的候选者就是想当 Leader 的哨兵。

在投票过程中，任何一个「候选者」，要满足两个条件：

第一，拿到半数以上的赞成票；
第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。

5.主从故障转移的过程是怎样的？

主从故障转移操作包含以下四个步骤：

第一步：在已下线主节点（旧主节点）属下的所有「从节点」里面，挑选出一个从节点，并将其转换为主节点。
第二步：让已下线主节点属下的所有「从节点」修改复制目标，修改为复制「新主节点」；
第三步：将新主节点的 IP地址和信息，通过「发布者/订阅者机制」通知给客户端；
第四步：继续监视旧主节点，当这个旧主节点重新上线时，将它设置为新主节点的从节点；

步骤一：选出新主节点
首先把网络状态不好的从节点过滤掉
接下来要对所有从节点进行三轮考察：优先级、复制进度、ID 号

第一轮考察：优先级最高的从节点胜出
第二轮考察：复制进度最靠前的从节点胜出
第三轮考察：ID 号小的从节点胜出

在选举出从节点后，哨兵 leader 向被选中的从节点发送 SLAVEOF no one 命令，让这个从节点解除从节点的身份，将其变为新主节点。

在发送 SLAVEOF no one 命令之后，哨兵 leader 会以每秒一次的频率向被升级的从节点发送 INFO 命令，并观察命令回复中的角色信息，当被升级节点的角色信息从原来的 slave 变为 master 时，哨兵 leader 就知道被选中的从节点已经顺利升级为主节点了。

步骤二：将从节点指向新主节点

哨兵 leader 向所有从节点（server3和server4）发送 SLAVEOF ，让它们成为新主节点的从节点。

步骤三：通知客户的主节点已更换

通过 Redis 的发布者/订阅者机制来实现的。
每个哨兵节点提供发布者/订阅者机制，客户端可以从哨兵订阅消息。
在这里插入图片描述
主从切换完成后，哨兵就会向 +switch-master 频道发布新主节点的 IP 地址和端口的消息，这个时候客户端就可以收到这条信息，然后用这里面的新主节点的 IP 地址和端口进行通信了。