CAP原则以及eureka和zookeeper的对比

1 CAP理论是什么？

CAP即：

• Consistency（一致性）：对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败，返回一个错误或超时，其强调的是数据正确。
• Availability（可用性）：任何客户端的请求都能得到响应数据，不会出现响应错误，但不保证数据最新，强调的是不出错。比如我们购买商品时，他的点赞数就与购买商品无关，我们可以允许他不是最新的。
• Partition tolerance（分区容忍性）：由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。

这三个性质对应了分布式系统的三个指标。而CAP理论说的就是：一个分布式系统，不可能同时做到这三点。分布式系统必须满足分区容错性，所以要么是AP,要么是CP。

2 分布式CAP定理，为什么不能同时满足三个特性

假设有两台服务器，一台放着应用A和数据库V，一台放着应用B和数据库V，他们之间的网络可以互通，也就相当于分布式系统的两个部分。

在满足一致性的时候，两台服务器(假设为N1,N2)的数据是一样的，DB0=DB0。在满足可用性的时候，用户不管是请求N1或者N2，都会得到立即响应。在满足分区容错性的情况下，N1和N2有任何一方宕机，或者网络不通的时候，都不会影响N1和N2彼此之间的正常运作。

用户通过N1中的A应用请求数据更新到服务器DB0，这时N1中的服务器DB0变为DB1，通过分布式系统的数据同步更新操作，N2服务器中的数据库V0也更新为了DB1（图2），这时，用户通过B向数据库发起请求得到的数据就是即时更新后的数据DB1。

上面是正常运作的情况，但分布式系统中，最大的问题就是网络，现在假设一种极端情况，N1和N2之间的网络断开了，但我们仍要支持这种网络异常，也就是满足分区容错性，那么这样能不能同时满足一致性和可用性呢？

假设N1和N2之间通信的时候网络突然出现故障，有用户向N1发送数据更新请求，那N1中的数据DB0将被更新为DB1，由于网络是断开的，N2中的数据库仍旧是DB0；

如果这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据DB1，怎么办呢？有二种选择，第一，牺牲数据一致性，响应旧的数据DB0给用户；第二，牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作完成之后，再给用户响应最新的数据DB1。

3 作为服务中心，eureka和zookeeper的对比

3.1 集群方式不同

• zookeeper集群是存在leader和follower关系的，也就是一主多从。

• eureka集群中的各个节点是平等的地位，peer to peer对等通信。这是一种去中心化的架构，在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点都可被视为其他节点的副本

3.2 zookeeper 保证CP，eureka保证 AP

• Zookeeper保证 CP，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，选举是需要时间的，在这一段时间内，将无法处理请求。所以说，Zookeeper 不能保证服务可用性。
• eureka保证 AP，在Eureka平台中，如果某台服务器宕机，客户端请求会自动切换到新的Eureka节点，只要有一台Eureka还在，就能保证注册服务可用，只不过查到的信息可能不是最新的。当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。

3.3 zookeeper的实时性更好

eureka是通过心跳体制，检测节点是否正常，相比于zookeeper的watcher机制，实时性稍差一点

正常情况下，为了满足用户体验，应该先选可用性。所以，理论上来说，Eureka作为系统服务的注册中心是最适合的。