Redis第11讲——Redis集群脑裂问题

2024-04-04 09:28
文章标签 问题 集群 redis 脑裂

本文主要是介绍Redis第11讲——Redis集群脑裂问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、什么是集群脑裂

所谓脑裂,就如同它的名字一样,大脑裂开了,一般来说是指一个分布式系统中有两个子集,然后每个子集都有一个自己的大脑(Leader/Master)。那么整个分布式系统就会存在多个大脑了,而且每个都认为自己是正常的,这就会导致数据不一致或重复写入的问题。

在Redis集群中,每个节点的部署方式一般都是【一主多从】,主节点提供写操作,从节点提供读操作。如果主节点此时发生网络故障,与从节点断开连接了,但主节点与客户端是正常的,客户端依旧向主节点写入数据。

这时哨兵节点发现主节点有故障失联了,于是哨兵节点就会从 从节点选出一个leader作为新主节点,这时脑裂就出现了。

突然这时原主节点网络好了,然而此时故障转移已完毕,已经有新主节点了,那么原主节点就会降级为新主节点的从节点,新主节点会向所有实例发送slave of命令,让所有实例重新全量同步,在全量同步之前,从节点会先清空自己的数据,那么客户端在原主节点故障期间写入的数据就丢失了。

二、脑裂的发生

Redis的脑裂问题可能发生在网络分区或者主节点出现问题的时候:

  • 网络分区:网络故障或分区导致了不同子集之间的通信中断。Master、哨兵和Slave节点被分割为了两个网络,此时哨兵发现和Master连接不上,就会发起主从切换,选出一个新的Master,这就出现了两个主节点(如上图)。
  • 主节点问题:主节点出现问题,导致不同的子集认为它们是正常的主节点。Master出现问题,哨兵开始主从切换,但在切换过程中主节点又恢复了,这时候可能会导致一部分slave节点认为它是Master,而另一部分新选出了一个Matser(如第五节图)。

三、脑裂导致的问题

从上面图中可以清楚地看到脑裂的危害,这里再总结一下:

  • 数据不一致:不同子集之间可能对同一数据进行不同的写入,导致数据不一致。
  • 重复写入:在脑裂问题解决后,不同子集可能尝试将相同的写操作应用到主节点上,导致数据重复。
  • 数据丢失:新选出来的Matser会向所有的实例发送slave of命令,让所有实例重新进行全量同步,在此之前会先清空实例上的数据,所以在主从切换期间,原Matser上执行的写命令也会被清空。

四、解决方案

脑裂的主要原因其实就是哨兵集群认为主节点出现"假故障"了,于是开始主从切换,选举出了新的主节点,这就导致短暂的出现了两个主节点。

所以应对脑裂的解决办法应该是取限制原主库接收请求,Redis提供了两个配置项(已翻译): 

# 如果有少于 N 个从节点连接且滞后时间小于或等于 M 秒,主节点可以停止接受写入操作。
# 这些 N 个从节点需要处于“在线”状态。
# 滞后时间必须小于或等于指定值,以秒为单位,是从上次接收到的从节点ping的时间计算出来的,
# 通常每秒发送一次。
# 此选项不能保证 N 个副本会接受写入操作,但会限制在不足够的从节点可用时丢失写入的暴露窗口# 到指定的秒数。
# 例如,要求至少有 3 个滞后时间小于或等于 10 秒的从节点,请使用:
min-slaves-to-write 3
min-slaves-max-lag 10

再解释下:

  • min-slaves-to-write:主库能进行数据同步的最少从库数量。
  • min-slaves-max-lag:主从进行数据复制时,从库给主库发送ACK消息的最大延迟秒数。

这两项必须同时满足,不然主节点会禁止写入操作,这就解决了因脑裂导致数据丢失的问题。

举个例子,我们把min-slaves-to-write设置为1,把min-slaves-max-lag设置为10。

如果Master节点因为某些原因挂了12s,导致哨兵判断主节点客观下线,开始主从切换。

同时,因为原Master宕机了12s,没有一个(min-slaves-to-write)从节点与主节点之间的数据复制在10s(min-slaves-max-lag)内,不满足配置要求,原Master就无法执行写操作了。

五、为什么不能彻底解决脑裂问题

我们来看一个场景:

我们把min-slaves-to-write设置为1,把min-slaves-max-lag设置为10,同时把down-after-milliseconds设置为8s,也就是如果8秒连不上主节点,哨兵就会进行主从切换。

假设Matser节点宕机8s,哨兵会判为客观下线,开始主从切换,但是这个过程一共需要5秒。那如果主从切换过程中,主节点在第9秒恢复运行了,而min-slaves-max-lag 10s那么主节点还是可以写的。

那么在9s~12秒期间原主节点还是可以接收客户端传的写命令并且执行,新主节点执行slave of命令后,这个期间写的数据就会丢失。

所以Redis脑裂可以采用min-slaves-to-write和min-slaves-max-lag合理配置尽量规避,但无法彻底解决。

End:希望对大家有所帮助,如果有纰漏或者更好的想法,请您一定不要吝啬你的赐教🙋。

这篇关于Redis第11讲——Redis集群脑裂问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/875413

相关文章

服务器集群同步时间手记

1.时间服务器配置(必须root用户) (1)检查ntp是否安装 [root@node1 桌面]# rpm -qa|grep ntpntp-4.2.6p5-10.el6.centos.x86_64fontpackages-filesystem-1.41-1.1.el6.noarchntpdate-4.2.6p5-10.el6.centos.x86_64 (2)修改ntp配置文件 [r

HDFS—集群扩容及缩容

白名单:表示在白名单的主机IP地址可以,用来存储数据。 配置白名单步骤如下: 1)在NameNode节点的/opt/module/hadoop-3.1.4/etc/hadoop目录下分别创建whitelist 和blacklist文件 (1)创建白名单 [lytfly@hadoop102 hadoop]$ vim whitelist 在whitelist中添加如下主机名称,假如集群正常工作的节

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

好题——hdu2522(小数问题:求1/n的第一个循环节)

好喜欢这题,第一次做小数问题,一开始真心没思路,然后参考了网上的一些资料。 知识点***********************************无限不循环小数即无理数,不能写作两整数之比*****************************(一开始没想到,小学没学好) 此题1/n肯定是一个有限循环小数,了解这些后就能做此题了。 按照除法的机制,用一个函数表示出来就可以了,代码如下

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

零基础学习Redis(10) -- zset类型命令使用

zset是有序集合,内部除了存储元素外,还会存储一个score,存储在zset中的元素会按照score的大小升序排列,不同元素的score可以重复,score相同的元素会按照元素的字典序排列。 1. zset常用命令 1.1 zadd  zadd key [NX | XX] [GT | LT]   [CH] [INCR] score member [score member ...]

购买磨轮平衡机时应该注意什么问题和技巧

在购买磨轮平衡机时,您应该注意以下几个关键点: 平衡精度 平衡精度是衡量平衡机性能的核心指标,直接影响到不平衡量的检测与校准的准确性,从而决定磨轮的振动和噪声水平。高精度的平衡机能显著减少振动和噪声,提高磨削加工的精度。 转速范围 宽广的转速范围意味着平衡机能够处理更多种类的磨轮,适应不同的工作条件和规格要求。 振动监测能力 振动监测能力是评估平衡机性能的重要因素。通过传感器实时监

搭建Kafka+zookeeper集群调度

前言 硬件环境 172.18.0.5        kafkazk1        Kafka+zookeeper                Kafka Broker集群 172.18.0.6        kafkazk2        Kafka+zookeeper                Kafka Broker集群 172.18.0.7        kafkazk3

缓存雪崩问题

缓存雪崩是缓存中大量key失效后当高并发到来时导致大量请求到数据库,瞬间耗尽数据库资源,导致数据库无法使用。 解决方案: 1、使用锁进行控制 2、对同一类型信息的key设置不同的过期时间 3、缓存预热 1. 什么是缓存雪崩 缓存雪崩是指在短时间内,大量缓存数据同时失效,导致所有请求直接涌向数据库,瞬间增加数据库的负载压力,可能导致数据库性能下降甚至崩溃。这种情况往往发生在缓存中大量 k

6.1.数据结构-c/c++堆详解下篇(堆排序,TopK问题)

上篇:6.1.数据结构-c/c++模拟实现堆上篇(向下,上调整算法,建堆,增删数据)-CSDN博客 本章重点 1.使用堆来完成堆排序 2.使用堆解决TopK问题 目录 一.堆排序 1.1 思路 1.2 代码 1.3 简单测试 二.TopK问题 2.1 思路(求最小): 2.2 C语言代码(手写堆) 2.3 C++代码(使用优先级队列 priority_queue)