对于ZooKeeper和Eureka的区别

CAP原则又叫CAP理论指的是在一个分布式系统中： Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）。
一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容错性（P）：系统如果不能达成数据一致性，就意味着发生了分区的情况 (原因多种…) ，必须就当前操作倾向于A还是倾向于C。
分布式系统当中只能满足两个，P是必须选择的，所以一般根据具体情况选择C还是A。

zookeeper满足CP，eureka满足AP

zookeeper

zk会出现这样一种情况,当master节点因为网络故障与其他节点失去取系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长, 30 ~ 120s,且选举期间整个2k集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的，所以不能满足A(可用性)

eureka

Eureka各个节点都是平等的,某个节点挂掉并不会影响正常节点的工作。
EurekaClient在向某个EurekaServer节点注册时如果如果发现注册失败,则会自动切换至其它节点,只要有一台EurekaServer还在,就能保证注册服务可用A(可用性),有可能查到的数据不是最新的C(一致性),原因如下：

默认配置中EurekaServer在一定时间（默认90s）没接受到某个服务的心跳后，EurekaServer会注销该服务。
还有就是 Eureka它具有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就以为你的集群出现了网络故障，
但ereka不会从注册列表中移除因为长时间没收到心跳而应该过期的服务==（此时的数据就可能是几分钟前的）==，还能够接受新服务的注册和查询请求,不过不会被同步到其它节点上，当网络稳定时,当前实例新的注册信息会被同步到其它节点中，从而恢复正常。

总结

1，zookeeper注重 C(一致性) + P,因为在leader节点投票选举过程中，会有一段时间不可用。
2，eureka注重A(可用性) + P，因为他的保护机制保证，让他不能保证数据一致。
3, 分布式中CAP并不是只能选择两个，只是更加倾向于哪两个。