Zookeeper集群和Eureka集群有一个最大的区别，zookeeper集群是存在leader和follower关系的，也就是一主多从。
而eureka集群却不是这样，eureka集群中的各个节点是平等的地位，peer to peer对等通信。这是一种去中心化的架构，在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点都可被视为其他节点的副本。
zookeeper是如何保证“一致性”呢？
当往zookeeper的leader节点写数据时，leader会对剩下的follower节点进行主从数据同步，它必须得同步超过半数的follower节点才给客户端返回写成功的信号。
所以从这点上它是保证了数据一致性，但是却不是强一致性。
另外一点就是，如果由于网络故障或是其他原因导致leader节点挂了，那么这个时候zookeeper集群就得在剩下那些follower接点中重新进行leader的选举，选出一个新leader来。但是别忘了，选举是需要时间的，哪怕30s到120秒，这一段时间之内，zookeeper集群是不能给外部提供服务的，处于不可用的状态，所以从这个角度来讲它丧失了一定的系统可用性（即CAP中的A）。
eureka是如何保证“可用性”的呢？
Eureka集群中各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外Eureka还有一种保护机制，如果15分钟内超过85%的节点都没有正常的心跳，那么Eureka就会认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1.Eureka不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务为。
2.Eureka依然能够接受新服务的注册和查询请求，但是不会同步到其他节点去（为了保证当前节点可用）。
3.当网络稳定的时候，当前新注册的信息会被同步到其他节点。
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper集群那样使整个注册服务瘫痪。