Zookeeper学习（三）：脑裂现象与应对策略

一、脑裂现象

• 脑裂现象主要是指当出现网络分区时，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 来作为注册中心，其中很大一部分原因就是微服务的注册中心是更加强调高可用，而非数据强一致性。