Redis~Sentinel哨兵(哨兵的高可用性、部署技巧、实现原理、领导选举、故障转移、优缺点)

最新推荐文章于 2024-03-29 21:00:01 发布

Listen-Y

最新推荐文章于 2024-03-29 21:00:01 发布

阅读量643

点赞数 4

分类专栏： Redis 文章标签：运维 java redis 分布式

本文链接：https://blog.csdn.net/Shangxingya/article/details/111460894

版权

Redis 专栏收录该内容

21 篇文章 1 订阅

订阅专栏

文章目录

主从复制的问题

在上篇博客中讲到, 主从复制一个很重要的缺陷, 主节点宕机之后, 整个服务写数据服务就会宕机, 主从模式不会自动进行配置和更改主节点, 这就需要哨兵来帮助我们做这些事情
Redis主从复制模式下，一旦主节点出现了故障不可达，需要人工干预进行故障转移，无论对于Redis的应用方还是运维方都带来了很大的不便

Redis Sentinel(哨兵)的高可用性

当主节点出现故障时，Redis Sentinel能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用

工作原理

Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识
如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方
切换成功后就会通过发布订阅模式,让各个哨兵把自己监控的主服务器进行切换(给每个哨兵内部都会使用发布订阅模式进行联系)
整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了Redis的高可用问题

从逻辑架构上看，Sentinel节点集合会定期对所有节点进行监控，特别是对主节点的故障实现自动转移

Redis Sentinel的几个功能

监控：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达
通知：Sentinel节点会将故障转移的结果通知给应用方
主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系
配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息

同时看到，Redis Sentinel包含了若个Sentinel节点，这样做也带来了两个好处：
对于节点的故障判断是由多个Sentinel节点共同完成，这样可以有效地防止误判
Sentinel节点集合是由若干个Sentinel节点组成的，这样即使个别Sentinel节点不可用，整个Sentinel节点集合依然是健壮的

哨兵的安装与部署

Redis安装目录下有一个sentinel.conf，是默认的Sentinel节点配置文件，配置的参数如下所示：

port 26379  
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
#sentinel auth-pass <master-name> <password>
#sentinel notification-script <master-name> <script-path>
#sentinel client-reconfig-script <master-name> <script-path>

port和dir分别代表Sentinel节点的端口和工作目录

sentinel monitor (重点)

sentinel monitor <master-name> <ip> <port> <quorum>

本配置说明此Sentinel节点要监控的是一个名字叫做，ip地址和端口为的主节点

代表要判定主节点最终不可达所需要的票数

参数用于故障发现和判定：例如将quorum配置为2，代表至少有2个Sentinel节点认为主节点不可达，那么这个不可达的判定才是客观的。对于设置的越小，那么达到下线的条件越宽松，反之越严格。一般建议将其设置为Sentinel节点的一半加1

sentinel down-after-milliseconds

每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达，（单位为毫秒）就是超时时间

哨兵实现原理

一套合理的监控机制是Sentinel节点判定节点不可达的重要保证，Redis Sentinel通过三个定时监控任务完成对各个节点发现和监控

三个定时监控任务

每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构

通过向主节点执行info命令，获取从节点的信息，这也是为什么 Sentinel节点不需要显式配置监控从节点
当有新的从节点加入时都可以立刻感知出来
节点不可达或者故障转移后，可以通过info命令实时更新节点拓扑信息

每隔2秒，每个Sentinel节点会向Redis数据节点的__sentinel__：hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他 Sentinel节点以及它们对主节点的判断

发现新的Sentinel节点：通过订阅主节点的__sentinel__：hello了解其他的Sentinel节点信息，如果是新加入的Sentinel节点，将该Sentinel节点信息保存起来，并与该Sentinel节点创建连接
Sentinel节点之间交换主节点的状态，作为后面客观下线以及领导者选举的依据

每隔1秒, 每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达

主观下线和客观下线

上面介绍的第三个定时任务，每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线
当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel ismaster-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过个数（quorum是sentinel配置文件中的sentinel monitor配置选项后指定的值），Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定

领导者哨兵节点选举

假如Sentinel节点对于主节点已经做了客观下线，那么是不是就可以立即进行故障转移了？当然不是，实际上故障转移的工作只需要一个Sentinel 节点来完成即可，所以Sentinel节点之间会做一个领导者选举的工作，选出一个Sentinel节点作为领导者进行故障转移的工作
Redis使用了Raft算法实现领导者选举，进行领导者选举的大致思路：

每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自己设置为领导者
收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令，将同意该请求，否则拒绝
如果该Sentinel节点发现自己的票数已经大于等于所有哨兵数量的一半，那么它将成为领导者
如果此过程没有选举出领导者，将进入下一次选举