Eureka基于AP，不会有类似于ZooKeeper的选举leader的过程，采用的是Peer to Peer 对等通信，没有leader/follower的说法，每个peer都是对等的；客户端请求会自动切换 到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中。当Eureka节点接受客户端请求时，所有的操作都会在节点间进行复制（replicate To Peer）操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。至于为啥Eureka不能保证数据一致性，源于Eureka的自我保护机制：如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 。
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用) 。
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中。
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
总结以上是对zookeeper的工作原理和相关概念的一些整理，希望能对大家认识zookeeper有所帮助。下一篇文章开始基于zookeeper做一个简单的分布式配置中心，敬请期待！！！
参考链接https://blog.csdn.net/pml18710973036/article/details/64121522
https://www.cnblogs.com/stateis0/p/9062133.html
https://www.jianshu.com/p/2bceacd60b8a