Eureka和ZooKeeper都遵循CAP（Consistency, Availability, Partition-tolerance）原则。但是，任何分布式协调服务都不可能同时满足CAP中的三个要求。

图1 CAP 原则

      在分布式系统中，由于网络故障导致的丢包问题经常发生，所以网络分区容错是必须保证的。对于一致性和可用性，则需要根据实际需求合理取舍。

     （1）Eureka保证AP

        Eureka中各个节点都是平等的。一个或多个节点挂掉不会影响正常节点的工作，剩余节点仍然可以提供注册和查询服务，只不过查到的信息可能不是最新的。

        另外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有检测到正常的心跳，那么Eureka就认为客户端与注册中心之间出现了网络故障，此时会出现以下几种情况：

        a. Eureka不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务；

        b.Eureka仍然能够接受新的服务注册和查询请求，但不会将其同步到其它节点；

        c.当网络恢复正常后，新注册的服务信息会被同步到其它节点上

     （2）ZooKeeper保证CP

        a. ZK不能保证每次请求的可用性。任何时刻对ZK的访问请求都能得到一直的数据结果。在极端环境下，ZK可能会丢弃一些请求，应用程序需要重新请求才能获取结果。

        b.进行leader选举时ZK集群不可用。通过ZK获取服务列表时，当leader节点因为网络故障与其他节点失联时，剩余节点需要重新进行leader选举。问题在于，选举的时间太长，30-120s，这就导致选举期间注册服务瘫痪。