【总结】Redis哨兵

该文章为知识总结的文章,如果是初学者,建议先从专栏学习:Redis专栏

一、哨兵的介绍

sentinal,中文名是哨兵,是启动Redis后一个额外的进程,哨兵是redis集群架构中非常重要的一个组件,主要功能如下:

  • 集群监控,负责监控redis master和slave进程是否正常工作
  • 消息通知,如果某个redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员
  • 故障转移,如果master node挂掉了,会自动转移到slave node上
  • 配置中心,如果故障转移发生了,通知client客户端新的master地址

哨兵本身也是分布式的,作为一个哨兵集群去运行,互相协同工作

  • 故障转移时,判断一个master node是宕机了,需要大部分的哨兵都同意才行,涉及到了分布式选举的问题
  • 即使部分哨兵节点挂掉了,哨兵集群还是能正常工作的,因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的,那就很坑爹了

目前采用的是sentinal 2版本,sentinal 2相对于sentinal 1来说,重写了很多代码,主要是让故障转移的机制和算法变得更加健壮和简单

二、 哨兵的核心知识

  • 哨兵至少需要3个实例,来保证自己的健壮性
  • 哨兵 + redis主从的部署架构,是不会保证数据零丢失的,只能保证redis集群的高可用性
  • 对于哨兵 + redis主从这种复杂的部署架构,尽量在测试环境和生产环境,都进行充足的测试和演练

三、为什么redis哨兵集群只有2个节点无法正常工作?

哨兵集群必须部署2个以上节点

如果哨兵集群仅仅部署了个2个哨兵实例,quorum=1

+----+         +----+
| M1 |---------| R1 |
| S1 |         | S2 |
+----+         +----+

Configuration: quorum = 1

master宕机,s1和s2中只要有1个哨兵认为master宕机就可以还行切换,同时s1和s2中会选举出一个哨兵来执行故障转移

同时这个时候,需要majority,也就是大多数哨兵都是运行的,2个哨兵的majority就是2(2的majority=2,3的majority=2,5的majority=3,4的majority=2),2个哨兵都运行着,就可以允许执行故障转移

但是如果整个M1和S1运行的机器宕机了,那么哨兵只有1个了,此时就没有majority来允许执行故障转移,虽然另外一台机器还有一个R1,但是故障转移不会执行

四、经典的3节点哨兵集群

       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+

Configuration: quorum = 2,majority

如果M1所在机器宕机了,那么三个哨兵还剩下2个,S2和S3可以一致认为master宕机,然后选举出一个来执行故障转移

同时3个哨兵的majority是2,所以还剩下的2个哨兵运行着,就可以允许执行故障转移

五、两种数据丢失的情况

主备切换的过程,可能会导致数据丢失

1. 异步复制导致的数据丢失

因为master -> slave的复制是异步的,所以可能有部分数据还没复制到slave,master就宕机了,此时这些部分数据就丢失了

2. 脑裂导致的数据丢失

  • 脑裂,也就是说,某个master所在机器突然脱离了正常的网络,跟其他slave机器不能连接,但是实际上master还运行着

此时哨兵可能就会认为master宕机了,然后开启选举,将其他slave切换成了master

这个时候,集群里就会有两个master,也就是所谓的脑裂

此时虽然某个slave被切换成了master,但是可能client还没来得及切换到新的master,还继续写向旧master的数据可能也丢失了

因此旧master再次恢复的时候,会被作为一个slave挂到新的master上去,自己的数据会清空,重新从新的master复制数据,网络分区写入的数据就会丢失

3. 解决

  1. 配置Redis的主节点,要求只少有n台机器同步时间小于m秒,如果不满足情况,Redis会拒绝写入,这样最多丢失m秒的数据

  2. 客户端通过降级和限流,控制请求,同时可以把数据写入本地磁盘或者消息队列,等待Redis重启

六、sdown和odown转换机制

sdown和odown两种失败状态

  • sdown是主观宕机,就一个哨兵如果自己觉得一个master宕机了,那么就是主观宕机

  • odown是客观宕机,如果quorum数量的哨兵都觉得一个master宕机了,那么就是客观宕机

sdown达成的条件很简单,如果一个哨兵ping一个master,超过了is-master-down-after-milliseconds指定的毫秒数之后,就主观认为master宕机

sdown到odown转换的条件很简单,如果一个哨兵在指定时间内,收到了quorum指定数量的其他哨兵也认为那个master是sdown了,那么就认为是odown了,客观认为master宕机

七、哨兵集群的自动发现机制

哨兵互相之间的发现,是通过redis的pub/sub系统实现的,每个哨兵都会往_sentinel_:hello这个channel里发送一个消息,这时候所有其他哨兵都可以消费到这个消息,并感知到其他的哨兵的存在

每隔两秒钟,每个哨兵都会往自己监控的某个master+slaves对应的_sentinel_:hello channel里发送一个消息,内容是自己的host、ip和runid还有对这个master的监控配置

每个哨兵也会去监听自己监控的每个master+slaves对应的_sentinel_:hello channel,然后去感知到同样在监听这个master+slaves的其他哨兵的存在

每个哨兵还会跟其他哨兵交换对master的监控配置,互相进行监控配置的同步

八、slave配置的自动纠正

  • 哨兵会负责自动纠正slave的一些配置,比如slave如果要成为潜在的master候选人,哨兵会确保slave复制新master的数据;

  • 如果slave连接到了一个错误的master上,比如故障转移之后,那么哨兵会确保它们连接到正确的master上

九、slave->master选举算法

如果一个master被认为odown了,而且majority哨兵都允许了主备切换,那么某个哨兵就会执行主备切换操作,此时首先要选举一个新master来

会考虑slave的一些信息

  1. 跟master断开连接的时长
  2. slave优先级
  3. 复制offset
  4. run id

如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍,外加master宕机的时长,那么slave就被认为不适合选举为master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下来会对slave进行排序

  1. 按照slave优先级进行排序,slave priority越低,优先级就越高
  2. 如果slave priority相同,那么看replica offset,哪个slave复制了越多的数据,offset越靠后,优先级就越高
  3. 如果上面两个条件都相同,那么选择一个run id比较小的那个slave

十、quorum和majority

majority取值如下:
n= 2,majority=2
n= 3,majority=2
n= 4,majority=2
n= 5,majority=3

每次一个哨兵要做主备切换,首先需要quorum数量的哨兵认为odown,然后选举出一个哨兵来做切换,这个哨兵还得得到majority哨兵的授权,才能正式执行切换

如果quorum < majority,比如5个哨兵,majority就是3,quorum设置为2,那么就3个哨兵授权就可以执行切换

但是如果quorum >= majority,那么必须quorum数量的哨兵都授权,比如5个哨兵,quorum是5,那么必须5个哨兵都同意授权,才能执行切换

十一、configuration epoch

哨兵会对一套redis master+slave进行监控,有相应的监控的配置

执行切换的那个哨兵,会从要切换到的新master(salve->master)那里得到一个configuration epoch,这就是一个version号,每次切换的version号都必须是唯一的

如果第一个选举出的哨兵切换失败了,那么其他哨兵,会等待failover-timeout时间,然后接替继续执行切换,此时会重新获取一个新的configuration epoch,作为新的version号

十二、configuraiton传播

哨兵完成切换之后,会在自己本地更新生成最新的master配置,然后同步给其他的哨兵,就是通过之前说的pub/sub消息机制

这里之前的version号就很重要了,因为各种消息都是通过一个channel去发布和监听的,所以一个哨兵完成一次新的切换之后,新的master配置是跟着新的version号的

其他的哨兵都是根据版本号的大小来更新自己的master配置的

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Redis哨兵模式是一种高可用性方案,用于监控和管理Redis主从复制架构中的故障转移。在哨兵模式中,有一个或多个哨兵进程运行在不同的节点上,它们负责监控Redis实例的状态,并在主节点出现故障时自动将一个从节点升级为新的主节点。 以下是Redis哨兵模式的详细解释: 1. 哨兵的角色:哨兵进程是一个特殊的Redis实例,它通过向被监控的Redis实例发送命令来获取实例的状态信息。每个哨兵进程都会定期检查主节点和从节点的状态,并与其他哨兵进程进行通信以达成共识。 2. 监控主节点状态:哨兵进程通过向主节点发送PING命令来检测主节点是否存活。如果主节点未响应,哨兵会将该主节点标记为下线,并开始进行故障转移。 3. 选择新的主节点:当主节点下线时,哨兵进程会从当前还在运行的从节点中选出一个新的主节点。它会根据预定义的优先级、运行健康度和复制偏移量等因素来选择新的主节点。 4. 执行故障转移:一旦新的主节点被选出,哨兵进程会发送命令给其他从节点,将它们切换到新的主节点上。之后,哨兵会通知客户端新的主节点的地址,以便客户端能够重新连接到新的主节点。 5. 监控复制过程:哨兵进程会监控主从节点之间的复制状态。如果从节点未能及时同步主节点,哨兵会将该从节点标记为下线,并启动故障转移过程。 6. 自动化管理:哨兵模式具有自动化管理的特性。一旦配置好哨兵进程,它们将自动监控并管理Redis实例的状态,提供高可用性和故障转移能力。 总结起来,Redis哨兵模式通过监控和管理主从复制架构中的节点状态,实现了自动化的故障转移和高可用性。它是一种简单且可靠的方式来确保Redis实例的持续可用性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值