为什么要有哨兵？

Redis 在 2.8 版本以后提供的哨兵（Sentinel）机制，它的作用是实现主从节点故障转移。它会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。

哨兵机制是如何工作的？

哨兵其实是一个运行在特殊模式下的 Redis 进程，所以它也是一个节点。从“哨兵”这个名字也可以看得出来，它相当于是“观察者节点”，观察的对象是主从节点。

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

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

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

如果主节点或者从节点没有在规定的时间（配置项）内响应哨兵的 PING 命令，哨兵就会将它们标记为「主观下线」。主观下线适用于所有节点，客观下线只适用于主节点。

之所以针对「主节点」设计「主观下线」和「客观下线」两个状态，是因为有可能「主节点」其实并没有故障，可能只是因为主节点的系统压力比较大或者网络发送了拥塞，导致主节点没有在规定时间内响应哨兵的 PING 命令。

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

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

当这个哨兵的赞同票数达到哨兵配置文件中的 quorum 配置项设定的值（一般是哨兵数量的一半+1，防止多个哨兵都满足条件）后，这时主节点就会被该哨兵标记为「客观下线」。

哨兵判断完主节点客观下线后，哨兵就要开始在多个「从节点」中，选出一个从节点来做新主节点。

由哪个哨兵进行主从故障转移？

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

候选者会向其他哨兵发送命令，表明希望成为 Leader 来执行主从切换，并让所有其他哨兵对它进行投票。

每个哨兵只有一次投票机会，如果用完后就不能参与投票了，可以投给自己或投给别人，但是只有候选者才能把票投给自己，且候选者都会投给自己。

任何一个「候选者」拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值就能称为leader。

• 并没有一个很好的文章说明如果多个哨兵都发现主节点下线投给自己导致无法选出有主哨兵要如何做
  • 可以有两种考虑
    • 1、人为介入
    • 2、给哨兵设置优先级，多个哨兵都为候选人选取优先级最高的
  • 同时每个哨兵的ping时间错开，避免同时发现

如果没有满足条件，就需要重新进行选举。

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

步骤一：选出新主节点

首先把已经下线的从节点过滤掉，然后把以往网络连接状态不好的从节点也给过滤掉。（就是多次发生长时间断连的节点）

接下来要对所有从节点进行三轮考察：优先级、复制进度、ID 号。在进行每一轮考察的时候，哪个从节点优先胜出，就选择其作为新主节点。

• 第一轮考察：哨兵首先会根据从节点的优先级来进行排序，优先级越小排名越靠前，

  • Redis的配置项，通常配置时根据设备的硬件条件进行排序

• 第二轮考察：如果优先级相同，则查看复制的下标，哪个从「主节点」接收的复制数据多，哪个就靠前。

• 第三轮考察：如果优先级和下标都相同，就选择从节点 ID 较小的那个。

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

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

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

哨兵 leader 通过向「从节点」发送 SLAVEOF 命令来实现让已下线主节点属下的所有「从节点」（这里不是主节点）指向「新主节点」。

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

主从切换完成后，哨兵就会向 +switch-master 频道发布新主节点的 IP 地址和端口的消息，这个时候客户端就可以收到这条信息，然后用这里面的新主节点的 IP 地址和端口进行通信了。

通过发布者/订阅者机制机制，有了这些事件通知，客户端不仅可以在主从切换后得到新主节点的连接信息，还可以监控到主从节点切换过程中发生的各个重要事件。这样，客户端就可以知道主从切换进行到哪一步了，有助于了解切换进度。

步骤四：将旧主节点变为从节点

故障转移操作最后要做的是，继续监视旧主节点，当旧主节点重新上线时，哨兵集群就会向它发送 SLAVEOF 命令，让它成为新主节点的从节点

至此，整个主从节点的故障转移的工作结束。

哨兵集群是如何组成的？

哨兵节点之间是通过 Redis 的发布者/订阅者机制来相互发现的。

在主从集群中，主节点上有一个名为__sentinel__:hello的频道，不同哨兵就是通过它来相互发现，实现互相通信的。

主节点知道所有「从节点」的信息，所以哨兵会每 10 秒一次的频率向主节点发送 INFO 命令来获取所有「从节点」的信息。

---