CAP

传统的SQL —>ACID

A : atomicity 原子性
C : Consistency 一致性
I ：Isolation 独立性
D：Durability持久性

NoSQL —> CAP

C :Consistency 强一致性
A ：Availability 可用性
P：Partition tolerance 分区容错性

CAP理论就是说在分布式存储系统中，最多只能同时较好的满足两个。
由于当前的硬件条件一定会出现延迟丢包的问题。
分区容错性是我们必须要实现的。
针对大流量的网站，通常采用AP原则，牺牲强一致性，以保证高可用性。
如双十一、618商品的喜欢、页面的PV的数据没那么敏感，就牺牲了这些不重要的数据的强一致性，来保证重要的系统（网站能否访问、订单系统）使用

而 Eureka 遵守AP原则
Zookeeper遵守CP原则

对比

著名的CAP理论指出，一个分布式系统不可能同时满足C、A、P。由于分区容错性上分布式系统必须要保证的，所以我们只能在A和C之间权衡。

Zookeeper保证的是CP：当Zookeeper的master节点由于网络故障与其他节点失去联系，Zookeeper的选举时间太长（30~120s）。且选举期间整个集群都是不可用的，注册服务瘫痪。在云部署的环境下，由于网络问题使得zk集群失去master节点是大概率事件。虽然能恢复，但是漫长的选举时间导致注册不可用是不能容忍的。

Eureka保证的是AP：Eureka优先保证可用性，每个节点都是是平等的。几个节点挂掉不会影响正常节点的工作，剩余节点依然可以提供注册和查询服务。Eureka客户端向Eureka Server注册发现失败，就会切换至其他节点。只要还有一台节点存在，就能保证注册服务可用，只不过查到的信息可能不是最新的（不保证强一致性）。Eureka还有一种自我保护机制：如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就会认为客户端与注册中心出现了网络故障，此时会：
1、Eureka不再从注册列表中移除长时间没收到心跳而应该过期的服务。
2、Eureka依然接受客户端的注册和查询，但是不同步到其他节点。（保证当前节点可用）
3、当网络稳定时，将当前节点的注册信息同步到其他节点。

结论

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