如何避免Redis集群脑裂？

2021-01-03 本文已影响0人小狐憨憨

在这里插入图片描述

CAP

CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem）。

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

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

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

一致性 (Consistency)：等同于所有节点访问同一份最新的数据副本
可用性（Availability）：对数据更新具备高可用性
网络分区容忍性（Partition tolerance）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

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

举个例子：

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

在这里插入图片描述

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从

[图片上传失败...(image-37f470-1609668873482)]

配置 min-slaves-to-write 1 ，停掉一个slave （8002），在master（8006）上操作

[图片上传失败...(image-ee2897-1609668873482)]

重启salve节点，

在这里插入图片描述

再次试验

[图片上传失败...(image-a54d46-1609668873482)]

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