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 来作为注册中心,其中很大一部分原因就是微服务的注册中心是更加强调高可用,而非数据强一致性。

你可能感兴趣的:(中间件)