面试官：说说 Redis 哨兵机制？

大家好，我是鸭鸭！

此答案节选自鸭鸭最近弄的面试鸭小程序面试鸭 ，更多大厂常问面试题，可以点击下面的小程序进行阅读哈！

目前这个面试刷题小程序刚出，详细可以看这篇文章！这次，终于不用再被八股文吊打了！

回归面试题！

主从架构中，如果采用读写分离的模式，即主节点负责写请求，从节点负责读请求。假设这个时候主节点宕机了，没有新的主节点顶替上来的话，就会出现很长一段时间写请求没响应的情况。

针对这个情况，便出现了哨兵这个机制。它主要进行监控作用，如果主节点挂了，将从节点切换成主节点，从而最大限度地减少停机时间和数据丢失。

哨兵机制对应的架构图如下所示：

• 哨兵节点（Sentinel）: 主要作用是对 Redis 的主从服务节点进行监控，当主节点发生故障的时候，哨兵节点会选择一个合适的从节点升级为主节点，并通知其他从节点和客户端进行更新操作。
• Redis 节点：主要包括 master 以及 slave 节点，就是 Redis 提供服务的实例。

一般哨兵需要集群部署，至少三台哨兵组成哨兵集群。

哨兵是如何判断 Redis 中主节点挂了的呢？主要涉及到了两个机制：主观下线以及客观下线。

1）主观下线

Sentinel 每隔 1s 会发送 ping 命令给所有的节点。如果 Sentinel 超过一段时间还未收到对应节点的 pong 回复，就会认为这个节点主观下线。

“一段时间”是配置项 down-after-milliseconds 设定的。

2）客观下线

注意，只有主节点才有客观下线，从节点没有。

假设目前有个主节点被一个 sentinel 的判断主观下线了，但可能主节点并没问题，只是因为网络抖动导致了一台哨兵的误判。所以此时哨兵需要问问它的队友，来确定这个主节点是不是真的出了问题！

因此，它会向其他哨兵发起投票，其他哨兵会判断主节点的状态进行投票，可以投赞成或反对。

如果认为下线的总投票数大于 quorum（一般为集群总数/2 + 1，假设哨兵集群有 3 台实例，那么 3 / 2 + 1 = 2），则判定该主节点客观下线，此时就需要进行主从切换，而只有哨兵的 leader 才能操作主从切换。

Sentinel leader 是如何选举出来的？

Sentinel leader 节点的选举实际上涉及到分布式算法 raft，感兴趣的同学可以深入去了解一下，这里主要简单说一下哨兵集群选择 leader 的方式：

判断主节点主观下线的 sentinel 就是候选者，此时它想成为 leader。如果同时有两个 sentinel 判断主观下线，那么它们都是候选人，一起竞争成为 leader。

候选者们会先投自己一票，然后向其他 sentinel 发送命令让它们给自己投票。每个哨兵手里只有一票，投了一个之后就不能投别人了。

最后，如果某个候选者拿到哨兵集群半数及以上的赞成票，就会成为 leader。这里有一个注意的点，为了保证 sentinel 选举的时候尽量避免出现平票的情况，sentinel 的节点个数一般都会是奇数，比如 3,5,7 这样。

Redis 主节点选举

选出哨兵 leader 之后，需要选出 Redis 主从集群中的新 master 节点。

首先需要把一些已经下线的节点全部剔除，然后从正常的从节点中选择主节点，其主要经过以下三个流程:

1. 根据从节点的优先级进行选择，优先选择优先级的值比较小的节点（优先级的值越小优先级越高，优先级可通过 slave-priority 配置）。
2. 如果节点的优先级相同，则查看进行主从复制的 offset 的值，即复制的偏移量，偏移量越大则表示其同步的数据越多，优先级越高。
3. 如果 offset 也相同了，那只能比较 ID 号，选择 ID 号比较小的那个作为主节点（每个实例 ID 不同）。

选好主节点之后，哨兵 leader 会让其他从节点全部成为新 master 节点的 slave 节点。

最后利用 redis 的发布/订阅机制，把新主节点的 IP 和端口信息推送给客户端，此时主从切换就结束了。

可能还有同学关心旧主节点恢复了怎么办？实际上哨兵会继续监视旧的主节点，如果它上线了，哨兵集群会向它发送 slaveof 命令，让它成为新主节点的从节点。

最后

最后再推荐下鸭鸭目前努力在做面试小程序神器面试鸭 ，已经有 1600 多道面试题目啦，欢迎大家来阅读！如果大家有不会的面试题，也可以在小程序内反馈！鸭鸭会第一时间为大家解答！

我是鸭鸭，我们下期见~