Redis进阶 - 如何避免Redis集群脑裂?

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
简介: Redis进阶 - 如何避免Redis集群脑裂?

20200307112715522.png


CAP


CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer’s theorem) 。


这个定理起源于加州大学伯克利分校 的计算机科学家埃里克·布鲁尔在2000年的分布式计算原则研讨会 上提出的一个猜想。 在2002年,麻省理工学院(MIT)的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明, 使之成为一个定理。


吉尔伯特和林奇证明的CAP定理比布鲁尔设想的某种程度上更加狭义。 定理讨论了在两个互相矛盾的请求到达彼此连接不通的两个不同的分布式节点的时候的处理方案。


它指出对于一个分布式计算系统来说,不可能同时满足以下三点:


一致性 (Consistency):等同于所有节点访问同一份最新的数据副本

可用性(Availability):对数据更新具备高可用性

网络分区容忍性(Partition tolerance): 以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项。


举个例子:


想象两个节点分处分区两侧:


允许至少一个节点更新状态会导致数据不一致,即丧失了C性质。

如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了A性质。

除非两个节点可以互相通信,才能既保证C又保证A,这又会导致丧失P性质


Redis防止脑裂参数 min-slaves-to-write


20201105001753475.png


min-slaves-to-write  1 

写数据成功最少同步的slave数量,这个数量可以模仿大于半数机制配置,比如集群总共三个节点可以配置1,加上leader就是2,超过了半数


含义就是: 如果配置了min-slaves-to-write,健康的slave的个数小于配置项N,mater就禁止写入。


master最少得有多少个健康的slave存活才能执行写命令。这个配置虽然不能保证N个slave都一定能接收到master的写操作,但是能避免没有足够健康的slave的时候,master不能写入来避免数据丢失 。


设置为0关闭该功能。


redis集群没有过半机制会有脑裂问题,网络分区导致脑裂后多个主节点对外提供写服务,一旦网络分区恢复,会将其中一个主节点变为从节点,这时会有大量数据丢失。


这种方法不可能百分百避免数据丢失 ,原因参考Redis集群leader选举机制


验证

集群模式 3主3从

20201105002121120.png



配置 min-slaves-to-write 1 , 停掉一个slave (8002),在master(8006)上操作


20201105001919621.png

重启salve节点,


20201105002230435.png


再次试验


20201105002306194.png


注意事项


这个配置在一定程度上会影响集群的可用性,比如slave要是少于1个,这个集群就算leader正常也不能提供服务了,需要根据具体场景权衡选择。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
5月前
|
存储 缓存 NoSQL
Redis常见面试题(二):redis分布式锁、redisson、主从一致性、Redlock红锁;Redis集群、主从复制,哨兵模式,分片集群;Redis为什么这么快,I/O多路复用模型
redis分布式锁、redisson、可重入、主从一致性、WatchDog、Redlock红锁、zookeeper;Redis集群、主从复制,全量同步、增量同步;哨兵,分片集群,Redis为什么这么快,I/O多路复用模型——用户空间和内核空间、阻塞IO、非阻塞IO、IO多路复用,Redis网络模型
Redis常见面试题(二):redis分布式锁、redisson、主从一致性、Redlock红锁;Redis集群、主从复制,哨兵模式,分片集群;Redis为什么这么快,I/O多路复用模型
|
13天前
|
存储 NoSQL Redis
redis主从集群与分片集群的区别
主从集群通过主节点处理写操作并向从节点广播读操作,从节点处理读操作并复制主节点数据,优点在于提高读取性能、数据冗余及故障转移。分片集群则将数据分散存储于多节点,根据规则路由请求,优势在于横向扩展能力强,提升读写性能与存储容量,增强系统可用性和容错性。主从适用于简单场景,分片适合大规模高性能需求。
25 5
|
4月前
|
监控 NoSQL Redis
看完这篇就能弄懂Redis的集群的原理了
看完这篇就能弄懂Redis的集群的原理了
153 0
|
20天前
|
消息中间件 监控 NoSQL
Redis脑裂问题详解及解决方案
Redis脑裂问题是分布式系统中常见的复杂问题,合理配置Redis Sentinel、使用保护模式、采用分布式锁机制以及优化网络和客户端连接策略等措施,可以有效预防和解决脑裂问题。通过深入理解Redis脑裂问题的成因和影响,采取相应的解决方案,能够提高系统的可用性和数据一致性,保障Redis集群的稳定运行。希望本文能帮助你更好地理解和应对Redis脑裂问题。
29 2
|
2月前
|
存储 监控 NoSQL
Redis脑裂:预防与解决之道
在分布式系统中,Redis集群的脑裂问题是一个令人头疼的难题。它指的是由于网络分区或其他原因,导致集群中的节点无法正常通信,从而形成多个子集群,每个子集群都认为自己是主集群,进而引发数据不一致和服务可用性下降的问题。那么,如何有效预防Redis脑裂问题?当问题发生时,我们能否迅速解决?本文将围绕这一主题,分享一些实用的技术干货。
91 2
|
5月前
|
存储 NoSQL 算法
Redis 集群模式搭建
Redis 集群模式搭建
100 5
|
4月前
|
存储 缓存 NoSQL
【Azure Redis 缓存】当使用Azure Redis 集群服务时候,发生了Moved的几点分析
【Azure Redis 缓存】当使用Azure Redis 集群服务时候,发生了Moved的几点分析
|
4月前
|
NoSQL Redis
Redis——单机迁移cluster集群如何快速迁移
Redis——单机迁移cluster集群如何快速迁移
151 0
|
4月前
|
NoSQL Linux Redis
使用docker-compose搭建redis-cluster集群
使用docker-compose搭建redis-cluster集群
592 0