Zookeeper学习（三）：脑裂现象与应对策略
springcloud难学吗
⼀、脑裂现象
脑裂现象主要是指当出现⽹络分区时，zookeeper集形成了两个或者多个leader的情况，这时如果两个leader都提供服务，则会出现数据不⼀致问题。
⼆、集出现分区的选举⽅式
当由于⽹络分区，集被分离为多个⼦集时，则此时原集的leader失去了半数的follower节点，故需要重新进⾏leader选举。同时另外的⼦集由于没有leader，故也会发起leader选举。此时就需要在可⽤性和数据⼀致性⽅⾯做出选择。
zookeeper针对这种情况，提供了⼀下三种机制来对可⽤性和数据⼀致性进⾏取舍。
1. Quorums机制（超过半数）
即如果出现多个分区，则每个分区不满⾜超过总数的⼀半条件，所以要么只有⼀个leader，要么选举失败，这种⽅式是保持数据⼀致性，舍弃可⽤性的⼀种实现。
2. Weight机制（加权机制）
通过Quorums机制只有超过半数才能提供服务，这样如果集很⼤，出现分区则⽆法使⽤，故可以给节点设置权重，⼀些节点权重较⾼，这样计算出来超过⼀定权重值则也可以选举leader。
这种⽅式由于机器的权重不⼀样，故某些分区也是可以选举leader成功的，故可以继续提供服务，即保留可⽤性。所以可⽤性⽅⾯相对于Quorums机制是有提⾼的。
3. Fencing机制（共享资源加锁机制）
集节点可以看到共享资源说明在集中，可以获取共享资源的锁则成为leader。
这种⽅式偏向于可⽤性，数据⼀致性较弱。
三、CP⽽⾮AP：数据⼀致性
针对以上3种⽅式，zookeeper默认是基于Quorums机制的，即只有超过半数follower的分区才可以选举出leader继续提供服务，如果选举不出来，则不可⽤。这种⽅式⼀定程度上保持了数据⼀致性，所以总体来说Zookeeper 是强调 CP，即数据⼀致性，⽽舍弃了 CAP 的A，即⾼可⽤。
微服务框架的注册中⼼问题
在微服务架构中，对于注册中⼼，开源的Dubbo使⽤了Zookeeper，但是阿⾥内部却不推荐使⽤Zookeeper，并且微服务框架SpringCloud 使⽤了 Eureka，⽽不是 Zookeeper 来作为注册中⼼，其中很⼤⼀部分原因就是微服务的注册中⼼是更加强调⾼可⽤，⽽⾮数据强⼀致性。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。