一、CAP是什么？？
CAP理论告诉我们，一个分布式系统不可能同时满足以下三种

一致性（C:Consistency）
可用性（A:Available）
分区容错性（P:Partition Tolerance）
这三个基本需求，最多只能同时满足其中的两项，因为P是必须的,因此往往选择就在CP或者AP中

CAP三进二原则，CA，AP，CP

CAP理论核心：
一个分布式系统不可能同时很好的满足一致性，可用性，分区容错性3个需求。
根据CAP原则，将NoSQL数据库，分成了满足CA原则，CP原则，AC原则三类。
CA：单点集群，满足一致性，可用性。但是扩展性交较差
CP：满足一致性，分区容错性，但是，性能一般
AP：满足可用性，分区容错性，但是，一致性一般。

作为服务注册中心，Eureka比Zookeeper好在哪里？

根据CAP理论，
Zookeeper保证的是CP
Eureka保证的是AP

因此：Zookeeper保证的是CP，Eureka保证的是AP；

当向注册中心查询服务列表时，我们可以容忍服务返回的是几分钟之前的数据，但是我们不能容忍服务之间Down掉不可用。也就是说服务的注册功能对可用性的要求高于一致性。

但是Zookeeper中会出现一种情况，当master节点因为网络故障和其他节点失去联系了时，剩余的节点会重新选举leader。但是选举leader的时间太长，30~120s，而且选举期间整个Zookeeper集群是不可用的，这就导致选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得Zookeeper的master失去联系可能性是很大的，虽然最后服务能够恢复，但是较长时间的选举导致注册的长期不可用是不能容忍的；

Eureka的各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询的服务。Eureka的客户端在向某个Eureka注册的时候，若发现连接失败，则会自动切换至其他节点，只要一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查询到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内，超过85%的节点都没有正常的心跳，那么Eureka就认为客户端和注册中心之间出现了网络故障，此时会出现以下情况：

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

（2）Eureka仍然能够接收新的服务注册和查询的请求，但是不会被同步到其他节点上去（即保证当前节点依然可用）；

（3）当网络稳定时，当前实例新的注册信息会被同步到其他节点上去；

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会向Zookeeper那样使整个注册服务瘫痪；

**结论：
Eureka可以很好的应对网络故障导致部分节点，失去了联系，
而不会像zookeeper那样，让整个注册中心服务瘫痪！！！！**