【学习笔记】Reids的哨兵机制

前言

---

什么是哨兵机制？

哨兵机制（sentinel） 是Redis解决高可用的一种解决方案：它是由一个或者多个sentinel 实例组成的一个sentinel 系统。

哨兵架构图：

作用：

• 监控：Sentinel 会不断检查您的master和slave是否按预期工作。
• 选主：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主。
• 通知： Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端，比如告诉客户端master节点变更了，这样客户端写数据的时候才不会找错节点。

为什么需要哨兵机制？

在上节的 Redis的主从复制（此处跳转文章链接） 我们讲到过一个 主库 可以对应多个 从库 ，如果挂掉一个 从库 的话客户端可以访问其他 从库。这并不影响客户端的体验。但是如果是 主库 挂掉呢？ 那么客户端的 写命令 又该如何执行呢？

当 主库 挂掉我们就需要选择一个 从库 来当主库。那么就需要解决一下三个问题：

• 主库 是否真的挂掉？
• 切换哪个 从库 比较好呢？
• 如何通知把这个消息通知给其他 从库 和 客户端 呢？

其实我们可以把 主库 比作 皇帝 ，当一个皇帝驾崩当然需要由他的很多个儿子中选择继承人的嘛。

第一件事情就是要确认 老皇帝 是否真的驾崩？第二要选择下一任接班人是谁呢？是帅气逼人的太子，还是能文能武的八阿哥呢？第三如果 新皇 登基 ，如何去通知 合作的国家（客户端） 和 远在外地的 其他皇子（其他从库） 呢？

听过上述那接下来我们就一一解释上述问题。

如何判断主库是否挂掉？

一般情况 哨兵 会向 主库和从库 每个1秒发送 ping 。如果 主库和从库 正常，则就会给哨兵一个 回应 。那么 哨兵 就能判断是否 主库和从库 是否正常了。

当 主库 在规定的时间内没有回复 哨兵 ，则会被认为是主观下线。如果是网络拥堵造成 主库 不能及时返回响应，那么是不是就会出现误判呢？所以我们就需要多个 哨兵 （三个起步） 来进行判断。

当然也会有客观下线。那怎么让 主库 客观下线呢？我们可以看下图：

也就是 哨兵之间的投票制 ，上图中的 三大于二，也就会导致 主库 客观下线，然后重新选取 主库 。

注意： 在哨兵集群中也是有一个 leader，而这个leader也是决定着主库和从库之间的切换问题。

主从库的切换和消息的通知

当 哨兵集群 认为原来的 主库 下线时，则就会进行一个 主从库的切换 。

我们可以分为以下四步：

• 第一步：在已下线主节点（旧主节点）属下的所有「从节点」里面，挑选出一个从节点，并将其转换为主节点，选择的规则：
  • 过滤掉已经离线的从节点；
  • 过滤掉历史网络连接状态不好的从节点；
  • 将剩下的从节点，进行三轮考察：优先级、复制进度、ID 号。在每一轮考察过程中，如果找到了一个胜出的从节点，就将其作为新主节点。
• 第二步：让已下线主节点属下的所有「从节点」修改复制目标，修改为复制「新主节点」；
• 第三步：将新主节点的 IP 地址和信息，通过「发布者/订阅者机制」通知给客户端；
• 第四步：继续监视旧主节点，当这个旧主节点重新上线时，将它设置为新主节点的从节点；

至此 主从库转移 完毕。

发布者/订阅者机制」通知给客户端；

• 第四步：继续监视旧主节点，当这个旧主节点重新上线时，将它设置为新主节点的从节点；

至此 主从库转移 完毕。

---

题外话：
突然在自己的草稿中发现自己好久之前写的文章，然后又完善了一下嘿嘿，所以就发出来吧。在这里也非常感谢 小林 大佬，本文也是借鉴该大佬的文章嗷。