Spring Cloud Eureka和Zookeeper的区别

一.CPA原则
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
一致性（C）：在分布式系统的所有数据备份，在同一时刻是否同样的值（等同于所有节点访问同一份最新的数据副本））
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据跟新具备高可用）
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求，系统如果不能在时限内达成数据的一致性，就以为发生了分区的情况，必须在A和C之间做出选择

CAP原则的精髓之处就是要么AP,要么AC，要么CP，但是不存在CAP。如果在某个分布式系统中数据无副本，那么系统必然满足一致性条件，以为只有独一数据，不会出现数据不一致的情况，此时C和P两者兼备，但是如果系统发生网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足 。因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。

二.eureka和zookeeper的对比
Eureka（基于AP来设计的）
a.Eureka 是 Netflix 在线影片公司开源的一个服务注册与发现的组件，和其他Netflix 公司的服务组件（例如负载均衡、熔断器、网关等） 一起，被Spring Cloud 社区整合为Spring Cloud Netflix 模块，提供相应的JAVA封装类。

b.在Eureka的实现中优先保证可用性，节点之间相互平等，部分注册节点的挂掉不会对集群产生影响（不存在leader.不用选举），即使只剩下一个节点，也可以正常的提供发现服务。就算是所有的服务注册节点都挂掉了，Eureka Client（客户端）也会缓存服务调用信息，等宕机的活过来,就会把最新的一份信息同步给它.。保证了注册服务可用(保证可用性)。

c.Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1.ureka Server采用的是Peer to Peer对等通信。这是一种去中心化的架构，无master/slave区分，每一个Peer都是对等的。
2.Eureka仍能接收新服务的注册和查询请求，但是不会被同步到其他的节点上
3.网路稳定时，当前实例新的注册信息会被同步到其他节点上
在默认配置中，Eureka Server在默认90s内没有接收到客户的心跳，则注销该实例，但是因为微服务跨进程调用，网络通信往往存在各种问题，比如微服务状态正常，但是因为网络分区故障时，Eureka Server注销服务实例则会让大部分微服务不可用，这很危险，因为服务明明没有问题。
所以在配置Eureka时配置如下参数，可启动保护机制：
eureka.server.enable-self-preservation=true（当Eureka Server节点在短时间内丢失过多客户端时，那么这个节点将进入自我保护模式，不在注销任何微服务。网络稳定后自动退出自我保护模式）

zookeeper（Zookeeper是基于CP来设计的）
在zookeeper里面，若主机挂掉了，则zk集群整体不对外提供服务了，需要选一个新leader的出来（120s作用）才能继续对外提供服务！不保证高可用。

Eureka基于AP， 不是很注重数据的一致性！注重服务的可用性，即使所有机器都挂了，也能拿到本地缓存的数据。
Zookeeper基于CP， 注重数据的一致性。