主页 > IT业界  > 

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

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

文章目录 【学习笔记】Reids的哨兵机制前言什么是哨兵机制?如何判断主库是否挂掉?主从库的切换和消息的通知

前言
什么是哨兵机制?

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

哨兵架构图:

作用:

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

为什么需要哨兵机制?

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

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

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

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

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

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

如何判断主库是否挂掉?

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

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

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

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

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

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

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

我们可以分为以下四步:

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

至此 主从库转移 完毕。

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

第四步:继续监视旧主节点,当这个旧主节点重新上线时,将它设置为新主节点的从节点;

至此 主从库转移 完毕。


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

标签:

【学习笔记】Reids的哨兵机制由讯客互联IT业界栏目发布,感谢您对讯客互联的认可,以及对我们原创作品以及文章的青睐,非常欢迎各位朋友分享到个人网站或者朋友圈,但转载请说明文章出处“【学习笔记】Reids的哨兵机制