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

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

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从

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

重启salve节点，

再次试验

注意事项

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