1、CAP原则

分布式中有个重要的概念就是CAP原则：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
CAP在分布式存储系统中，最多只能实现以上两点。
而由于当前网络延迟故障会导致丢包等问题，所以分区容错性是必须实现的，我们只能在一致性和可用性中进行选择，没有Nosql数据库能同时保证三点。也就是说我们只能选择CP或者AP。

2、Zookeeper保证CP

zookeeper选择优先保证一致性。zookeeper保证访问请求都能保持一致的结果，同时具有容错性，但是不保证每次访问请求都是可用的。为什么不保证对请求可用呢？当zookeeper的master节点如果因为网络故障导致与其它节点失去联系时，剩余的节点会进行选举产生新的master节点，但是在这过程需要一定的时间，并且在选举这段时间内，整个zookeeper集群是不可用的。并且由于网络问题，这种情况发生的概率是比较大的。

3、Eureka保证AP

Eureka选择优先保证可用性。Eureka的节点之间是平等的。如果某个节点服务器宕机了，Eureka不会像zookeeper那样进行停止服务进行选举，而是让请求自动切换到另外的可用Eureka节点上，等到宕机的节点恢复后，再将其纳入集群中，只是不保证查询到的信息可能不是最新的。同时，如果15分钟内超过85%的节点都没有心跳，那么Eureka就认为客户端和注册中心出现了网络故障，就执行一下策略：

1. Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 (即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

4、总结

zookeeper的设计理念就是分布式协调服务，保证数据（配置数据，状态数据）在多个服务系统之间保证一致性，这也不难看出Zookeeper是属于CP特性（Zookeeper的核心算法是Zab，保证分布式系统下，数据如何在多个服务之间保证数据同步）。Eureka是吸取Zookeeper问题的经验，先保证可用性。zookeeper优先选择了一致性（CP），Eureka优先选择了可用性（AP）。