Springcloud 的Eureka和ZooKeeper比较

关于CAP理论，可以去看看阮一峰的文章[http://www.ruanyifeng.com/blog/2018/07/cap.html]
C(一致性)A(可用性)P(分区容错性)

ZooKeeper：
zookeeper保证了cp(一致性、分区容错性)，但是作为服务注册中心，我们可以容忍注册中心返回的是几分钟以前的注册信息。但是服务中心却必须保证可用性，
即服务注册中心对于高可用性的需求高于一致性。对于可用性，zookeeper有一个leader选举方案。当master主节点宕机与其他节点失去联系时，其他节点会重
新进行Leader选举，选出新的master节点。然而选举耗时过长，一般为30~120S，并且整个选举期间，整个zookeeper集群是无法使用的。

Eureka：
eureka保证了ap(可用性、分区容错性)，eureka每一个节点都是平等的，几个节点宕机不会影响正常节点的工作。剩余的正常节点依旧可以提供服务注册和查询。
并且，当客户端向某节点注册服务时，注册失败或者超时，则会自动切换到其他节点。只要有一台eureka节点还正常工作，就能保证注册服务的可用。但是对于服
务信息的同步则不能保证一致性(不能保证强一致性，但是最终一致)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内85%的节点都没有正常心跳(不可用)
那么Eureka就认为客户端与注册中心之间出现了网络故障，此时会出现以下几种情况：
1、Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2、Eureka仍然能够接收新服务的注册和查询请求，但是不会被同步到其他节点上(保证当前节点的可用性)
3、当网络稳定后，当前实例新注册的服务会被同步到其他节点

因此,Eureka能够保证注册中心的高可用性，而不会像zookeeper一样直接集群瘫痪