Redis如何实现故障自动恢复?
这篇文章,我们来看Redis是如何实现故障自动恢复的,它的实现正是要基于之前所讲的数据持久化和数据多副本而做的。
Redis作为非常火热的内存数据库,其除了具有非常高的性能之外,还需要保证高可用,在故障发生时,尽可能地降低故障带来的影响,Redis也提供了完善的故障恢复机制:哨兵。
下面就来具体来看看Redis的故障恢复是如何做的,以及其中的原理。
部署模式
Redis在部署时,可以采用多种方式部署,每种部署方式对应不同的可用级别。
单节点部署:只有一个节点提供服务,读写均在此节点,此节点宕机则数据全部丢失,直接影响业务
master-slave方式部署:两个节点组成master-slave模式,在master上写入,slave上读取,读写分离提高访问性能,master宕机后,需要手动把slave提升为master,业务影响程度取决于手动提升master的延迟
master-slave+哨兵方式部署:master-slave与上述相同,不同的是增加一组哨兵节点,用于实时检查master的健康状态,在master宕机后自动提升slave为新的master,最大程度降低不可用的时间,对业务影响时间较短
从上面几种部署模式可以看出,提高Redis可用性的关键是:多副本部署 + 自动故障恢复,而多副本正是依赖主从复制。
高可用做法
Redis原生提供master-slave数据复制,保证slave永远与master数据保持一致。
在master发生问题时,我们需要把slave提升为master,继续提供服务。而这个提升新master的操作,如果是人工处理,必然无法保证及时性,所以Redis提供了哨兵节点,用来管理master-slave节点,并在master发生问题时,能够自动进行故障恢复操作。
整个故障恢复的工作,正是Redis哨兵自动完成的。
哨兵介绍
哨兵是Redis高可用的解决方案,它是一个管理多个Redis实例的服务工具,可以实现对Redis实例的监控、通知、自动故障转移。
在部署哨兵时,我们只需要在配置文件中配置需要管理的master节点,哨兵节点就可以根据配置,对Redis节点进行管理,实现高可用。
一般我们需要部署多个哨兵节点,这是因为在分布式场景下,要想确定某个机器的某个节点上否发生故障,只用一台机器去检测可能是不准确的,很有可能这两台机器的网络发生了故障,而节点本身并没有问题。
所以对于节点健康检测的场景,一般都会采用多个节点同时去检测,且多个节点分布在不同机器上,节点数量为奇数个,避免因为网络分区导致哨兵决策错误。这样多个哨兵节点互相交换检测信息,最终决策才能确认某个节点上否真正发生了问题。
哨兵节点部署并配置完成后,哨兵就会自动地对配置的master-slave进行管理,在master发生故障时,及时地提升slave为新的master,保证可用性。
那么它的工作原理上怎样的呢?
哨兵工作原理
哨兵的工作流程主要分为以下几个阶段:
状态感知
心跳检测
选举哨兵领导者
选择新的master
故障恢复
客户端感知新master
下面对这些阶段进行详细的介绍。
状态感知
哨兵启动后只指定了master的地址,哨兵要想在master故障时进行故障恢复,就需要知道每个master对应的slave信息。关注公众号互联网架构师可以获取更多Redis系列教程。
每个master可能不止一个slave,因此哨兵需要知道整个集群中完整的的拓扑关系,如何拿到这些信息?
哨兵每隔10秒会向每个master节点发送info
命令,info
命令返回的信息中,包含了主从拓扑关系,其中包括每个slave的地址和端口号。有了这些信息后,哨兵就会记住这些节点的拓扑信息,在后续发生故障时,选择合适的slave节点进行故障恢复。
哨兵除了向master发送info
之外,还会向每个master节点特殊的pubsub
中发送master当前的状态信息和哨兵自身的信息,其他哨兵节点通过订阅这个pubsub
,就可以拿到每个哨兵发来的信息。
这么做的目的主要有2个:
哨兵节点可以发现其他哨兵的加入,进而方便多个哨兵节点通信,为后续共同协商提供基础
与其他哨兵节点交换master的状态信息,为后续判断master是否故障提供依据
心跳检测
在故障发生时,需要立即启动故障恢复机制,那么如何保证及时性呢?
每个哨兵节点每隔1秒向master、slave、其他哨兵节点发送ping
命令,如果对方能在指定时间内响应,说明节点健康存活。如果未在规定时间内(可配置)响应,那么该哨兵节点认为此节点主观下线。
为什么叫做主观下线?
因为当前哨兵节点探测对方没有得到响应,很有可能这两个机器之间的网络发生了故障,而master节点本身没有任何问题,此时就认为master故障是不正确的。
要想确认master节点是否真正发生故障,就需要多个哨兵节点共同确认才行。
每个哨兵节点通过向其他哨兵节点询问此master的状态,来共同确认此节点上否真正故障。
如果超过指定数量(可配置)的哨兵节点都认为此节点主观下线,那么才会把这个节点标记为客观下线。
选举哨兵领导者
确认这个节点真正故障后,就需要进入到故障恢复阶段。如何进行故障恢复,也需要经历一系列流程。
首先需要选举出一个哨兵领导者,由这个专门的哨兵领导者来进行故障恢复操作,不用多个哨兵都参与故障恢复。选举哨兵领导者的过程,需要多个哨兵节点共同协商来选出。
这个选举协商的过程,在分布式领域中叫做达成共识,协商的算法叫做共识算法。
共识算法主要为了解决在分布式场景下,多个节点如何针对某一个场景达成一致的结果。
共识算法包括很多种,例如Paxos、Raft、Gossip算法等,感兴趣的同学可以自行搜索相关资料,这里不再展开来讲。
哨兵选举领导者的过程类似于Raft算法,它的算法足够简单易理解。
简单来讲流程如下:
每个哨兵都设置一个随机超时时间,超时后向其他哨兵发送申请成为领导者的请求
其他哨兵只能对收到的第一个请求进行回复确认
首先达到多数确认选票的哨兵节点,成为领导者
如果在确认回复后,所有哨兵都无法达到多数选票的结果,那么进行重新选举,直到选出领导者为止
选择出哨兵领导者后,之后的故障恢复操作都由这个哨兵领导者进行操作。
选择新的master
哨兵领导者针对发生故障的master节点,需要在它的slave节点中,选择一个节点来代替其工作。
这个选择新master过程也是有优先级的,在多个slave的场景下,优先级按照:slave-priority配置 > 数据完整性 > runid较小者进行选择。
也就是说优先选择slave-priority最小值的slave节点,如果所有slave此配置相同,那么选择数据最完整的slave节点,如果数据也一样,最后选择runid较小的slave节点。
提升新的master
经过优先级选择,选出了备选的master节点后,下一步就是要进行真正的主从切换了。
哨兵领导者给备选的master节点发送slaveof no one
命令,让该节点成为master。
之后,哨兵领导者会给故障节点的所有slave发送slaveof $newmaster
命令,让这些slave成为新master的从节点,开始从新的master上同步数据。
最后哨兵领导者把故障节点降级为slave,并写入到自己的配置文件中,待这个故障节点恢复后,则自动成为新master节点的slave。
至此,整个故障切换完成。
客户端感知新master
最后,客户端如何拿到最新的master地址呢?
哨兵在故障切换完成之后,会向自身节点的指定pubsub
中写入一条信息,客户端可以订阅这个pubsub
来感知master的变化通知。我们的客户端也可以通过在哨兵节点主动查询当前最新的master,来拿到最新的master地址。
另外,哨兵还提供了“钩子”机制,我们也可以在哨兵配置文件中配置一些脚本逻辑,在故障切换完成时,触发“钩子”逻辑,通知客户端发生了切换,让客户端重新在哨兵上获取最新的master地址。
一般来说,推荐采用第一种方式进行处理,很多客户端SDK中已经集成好了从哨兵节点获取最新master的方法,我们直接使用即可。
总结
可见,为了保证Redis的高可用,哨兵节点要准确无误地判断故障的发生,并且快速的选出新的节点来代替其提供服务,这中间的流程还是比较复杂的。
中间涉及到了分布式共识、分布式协商等知识,目的都是为了保证故障切换的准确性。
我们有必要了解Redis高可用的工作原理,这样我们在使用Redis时能更准确地使用它。
作者:Kaito
链接:kaito-kidd.com/2020/07/02/redis-sentinel/
关微信公众号:互联网架构师,在后台回复:2T,可以获取我整理的教程,都是干货。
猜你喜欢
1、GitHub 标星 3.2w!史上最全技术人员面试手册!FackBook发起和总结
2、如何才能成为优秀的架构师?
3、从零开始搭建创业公司后台技术栈
4、程序员一般可以从什么平台接私活?
5、37岁程序员被裁,120天没找到工作,无奈去小公司,结果懵了...
6、滴滴业务中台构建实践,首次曝光
7、不认命,从10年流水线工人,到谷歌上班的程序媛,一位湖南妹子的励志故事
8、15张图看懂瞎忙和高效的区别
9、2T架构师学习资料干货分享
Redis如何实现故障自动恢复?相关推荐
- Redis学习总结(23)——Redis如何实现故障自动恢复?浅析哨兵的工作原理
前言 Redis是如何实现故障自动恢复的,它的实现正是要基于之前所讲的数据持久化和数据多副本而做的.Redis作为非常火热的内存数据库,其除了具有非常高的性能之外,还需要保证高可用,在故障发生时,尽可 ...
- zabbix监控vsftp服务,发生故障并自动恢复
最近老大有个需求,就是想把一些服务监控起来,发生故障并能够自动重启,这里我就拿ftp练了一下手 1.修改zabbix系统自带的模板 注意:key 这里可以使用监控服务的方式,也可以使用监控端口的方式n ...
- PHP+Redis实现游戏体力值加减及自动恢复的操作
在开发小游戏项目时,有时需要服务端来操作用户的体力.如果使用数据库来保存略显冗余,性能也稍有不足,所有使用Redis的过期机制可以更好更快的快速实现需求. 示例中的Redis经过了多例的封装 参照 多 ...
- redis专题:redis的持久化方式有哪些?redis数据的备份和恢复策略
文章目录 1. 为什么要做redis持久化? 2. 持久化方式之---RDB快照(snapshot) 3. 持久化方式之---AOF(append-only file) 4. 持久化方式之---混合持 ...
- oracle自动还原,什么是oracle自动恢复操作
这是由系统进行的恢复.无需人的管理和操作.一般当系统由于突然掉电而出现故障时用这种方法.当再次启动数据库就会进行自动恢复. 不像简单的DOS系统,oracle系统在运行时有许多事务要处理,并且存在许多 ...
- netsh命令恢复网络_实例的状态检查和自动恢复
关注微信公众号:AWS爱好者(iloveaws) Hello大家好,欢迎来到<AWS解决方案架构师认证 Professional(SAP)中文视频培训课程>,我们今天的课程讨论实例的状态检 ...
- 技术分享 | InnoDB Cluster+GreatSQL快速部署MGR集群,并实现读写分离和故障自动转移(超详细)...
本文来源:原创投稿 * GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源. 0. 内容提纲 1. 部署环境及初始化 2. 利用MySQL Shell构建MGR集群 3. 对在 ...
- 新一代-亚马逊自动恢复EC2系统
构造高可用性和高可靠性系统的一项重要原则是假定失效(Design forfailure).换言之,你的设计模型应具有正如亚马逊的首席技术官(CTO)沃纳•威格尔(Werner Vogels)曾说的&q ...
- YMatrix 5.0 故障自动转移功能新实现,运维更方便!
前言 分布式数据库一般都实现了数据多副本的存储以保证数据的高可用性.在多副本存储的基础上,通过切换活跃的存储副本来实现故障转移,是常见的做法. YMatrix 5.0 实现了在数据库集群所有数据分片上 ...
- 自动恢复保险丝/开关(RXE375)的原理和在开关稳压电源中的作用
自恢复保险丝是一种过流电子保护元件,采用高分子有机聚合物在高压.高温,硫化反应的条件下,掺加导电粒子材料后,经过特殊的工艺加工而成.传统保险丝过流保护,仅能保护一次,烧断了需更换,而自恢复保险丝具有过 ...
最新文章
- CCBPM高级开发之类设计与数据库设计命名规则
- ubuntu12.04 更新内核
- 本地通过域名访问虚拟机的网站部署方法(Nginx)
- 0 重新学习Ubuntu -- 这一段没怎么学习
- 雷军:电视机越大才越舒服!
- 博弈论与逻辑思维(传教士与妻子忠贞的问题)
- SOTA级发丝抠图模型PP-Matting重磅开源,支持多场景精细化分割!
- NXP与STM32单片机程序架构
- 微信Wifi物联架构---机智云/云智易如何接入微信硬件平台
- 2022第十一届PMO大会日程已定,将于8月13-14日和20-21日线上召开
- 24位行业精英:2018,区块链教会我最重要的一件事 |链捕手
- 小米红米全系列官方原厂预装系统
- 5-1 N个数求和 (20分)
- R-ggplot2 标准中国地图制作
- Greenplum upgrade from 4.3.4.1 to 4.3.30.0 准备工作
- android播放mp3功能,Android编程实现播放MP3功能示例
- matlab阻抗测量模块,基于matlab技术实现频谱分析仪测量阻抗
- H3C交换机和华为交换机对接聚合组,爬深坑
- 第14届 二期 Python
- 西南大学计算机学院推免,2020西南大学计算机与信息科学学院推免夏令营通知...