关于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一样直接集群瘫痪
原文地址:https://www.cnblogs.com/vincent928/p/10084176.html