开发工作中对于分布式缓存高可用方案(搭建Redis缓存高可用方案),Redis主从架构下是如何保证高可用的呢?
我们知道是应用了哨兵机制来实现。那Redis 服务部署的哨兵模式主要是什么,又解决了什么问题呢,于是利用周末时间整理了下,相信看完这篇文章,你也可以去给别人做技术分享了。O(∩_∩)O哈哈~
在讨论哨兵模式之前,我们先来看一个应用问题:Redis服务主机宕机
实际使用过程中,会出现master宕机的情况(这样会导致没有写服务,只有读服务)。那我们要保证服务的可用,就需要从其他salve节点中选取一个来作为master节点,来继续提供服务能力。
那主要的动作抽象下:
其中存在几个问题:
其实引入哨兵机制,就可以很好的解决上述问题。
Sentinel(哨兵)是Redis 的高可用性解决方案:由一个或多个Sentinel 实例组成的Sentinel 系统可以监视任意多个主服务,以及这些主服务器属下的所有从服务,并在被监视的主服务进入下线(不可服务)状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器。
不断的检查master和slave是否正常运行(master存活检测、master与slave运行情况检测)
当被监控的服务器出现问题时,向其他哨兵、客户端发送通知
断开故障master与slave的连接,选取一个slave作为新master,将其他slave连接到新的master并告知客户端新的服务器地址。
注意:哨兵也是一台Redis服务器,只是不提供数据服务;通常哨兵配置的数量为单数。
下面主要针对哨兵在进行主从切换过程中经历的三个阶段分别进行阐述。
1)Sentinel节点会通过master/slave 节点建立的cmd连接获取其工作状态
2)Sentinel收到反馈结果之后,会在哨兵内部进行信息的互通
关于故障转移,严格来讲可划分两个步骤:故障判定、故障转移。
直到主节点故障,哨兵报出 sdown,同时此哨兵还会向其他哨兵发布消息说这个主节点挂了。发送的指令是 sentinel is-master-down-by-address-port。
其余的哨兵也会发送他们收到的信息并且发送指令 sentinel is-master-down-by-address-port 到自己的内网,确认一下第一个发送 sentinel is-master-down-by-address-port 的哨兵说你说的对,这个家伙确实挂了。
当一个哨兵认为主节点挂了标记的是 sdown,当半数哨兵都认为挂了其标记的状态是 odown。
一个哨兵认为master节点挂了称为主观下线(sdown),超半数哨兵认为master节点挂了则称为客观下线(odown)。
1)首先,哨兵选举出哨兵Leader去处理故障转移
此时选举方式应用的是Raft协议,这个之前有过介绍,感兴趣的同学可以移步了解:
2)其次,哨兵Leader从所有的slave节点找出一个作为master节点
主要的规则:
假如以上优先级均一致,会考虑其他优先原则:
假如说 slave1 的 offset 为 50,slave2 偏移量为 55,则哨兵就会选择 slave2 为新的主节点。
这点类似于职场中的论资排辈,也就说根据 runid 的创建时间来判断,时间早的先上位。
3)数据转移
回到开篇问题中提及的几个问题,在经过哨兵及工作原理的介绍之后,是不是清晰了很多呢?相信大家都已经有自己的答案了。
Redis 主从复制的作用中有这么一句话“主从复制是高可用的基石”,那实现高可用必不可少的就是哨兵和集群。
对于本文重点内容,强调介绍下哨兵的作用和工作方式。
不断的检查master和slave是否正常运行(master存活检测、master与slave运行情况检测)
当被监控的服务器出现问题时,向其他哨兵、客户端发送通知
断开故障master与slave的连接,选取一个slave作为新master,将其他slave连接到新的master并告知客户端新的服务器地址。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复, Master 的主观下线状态就会被移除。
若没有足够数量的 Sentinel 同意 Master 已经下线, Master 的客观下线状态就会被移除。
【技术创作101训练营】
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。