一、Redis哨兵模式
- Redis的哨兵模式(Sentienl)是为了解决复制中的问题:在“Redis复制”架构中,如果主节点出现了故障,那么, 就需要手动将一个从节点晋升变为主节点,这个过程需要人工干预,比较麻烦主节点的写能力受到单机的限制主节点的存储能力受到单机的限制
- Redis哨兵模式的出现是为了解决上面出现的问题,从而提供:Reids的高可用监控各个节点能够实现自动故障转移
- RedisSentinel的功能有:
- 监控:Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否 可达
- 通知:Sentinel节点会将故障转移的结果通知给应用方
- 主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系
- 配置提供者:在Redis Sentinel结构中,客户端在初始化的时候连接的 是Sentinel节点集合,从中获取主节点信息
二、哨兵的工作原理
- Redis Sentinel是一个分布式架构,其中包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线标识
- 如果被标识的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时,它们会选举出一个Sentinel节点来完成自动故障转移的工作,同时会将这个变化实时通知给Redis应用方
- 整个过程完全是自动的,不需要人工来介入,所以这套方案很有效地解决了Redis的高可用问题
三、哨兵模式的部署
- 内容太多了,就不介绍了,详情参阅:https://blog.csdn.net/qq_41453285/article/details/106382660
四、哨兵的实现原理
三个定时监控任务
每隔10秒:每隔10秒,每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构
每隔2秒:每隔2秒,每个Sentinel节点会向Redis数据节点的__sentinel__:hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息 ,同时每个Sentinel节点也会订阅该频道,来了解其他 Sentinel节点以及它们对主节点的判断
每隔1秒:每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测,来确认这些节点当前是否可达
主观下线与客观下线
主观下线:
每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测,当这些节点超过down-after-milliseconds没有进行有效回复,Sentinel节点就会对该节点做失败判定,这个行为叫做主观下线
主观下线是当前Sentinel节点的一家之言,存在误判的可能,因此还需要进行下面的客观下线
客观下线:
当Sentinel主观下线的节点是主节点时,该Sentinel节点会通过sentinel ismaster-down-by-addr命令向其他Sentinel节点询问对主节点的判断,当超过<quorum>个数,Sentinel节点认为主节点确实有问题,这时该Sentinel节点会做出客观下线的决定
这样客观下线的含义是比较明显了,也就是大部分Sentinel节点都对主节点的下线做了统一的判定,那么这个判定就是客观 的
领导者节点选举
当Sentinel节点对于主节点已经做了客观下线,那么就需要进行故障转移了,但是在故障转移之前需要在所有的Sentinel中进行领导者节点的选举,选举出领导者,来让这个领导者进行故障转移
领导者的选举使用了Raft算法
故障转移
领导者选举出的Sentinel节点负责故障转移,具体步骤如下:
1)在从节点列表中选出一个节点作为新的主节点,选择方法如下:
a)过滤:“不健康”(主观下线、断线)、5秒内没有回复过Sentinel节 点ping响应、与主节点失联超过down-after-milliseconds*10秒
b)选择slave-priority(从节点优先级)最高的从节点列表,如果存在则 返回,不存在则继续
c)选择复制偏移量最大的从节点(复制的最完整),如果存在则返回,不存在则继续d)选择runid最小的从节点
2)Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点
3)Sentinel领导者节点会向剩余的从节点发送命令,让它们成为新主节点的从节点,复制规则和parallel-syncs参数有关
4)Sentinel节点集合会将原来的主节点更新为从节点,并保持着对其关注,当其恢复后命令它去复制新的主节点
原文:面试冲刺:47---Redis的哨兵模式是如何实现的呢?_江南、董少-CSDN博客