zookeeper和eureka使用场景(eureka与zookeeper差别)

如何比较ZooKeeper和尤里卡，很多新手都不是很清楚。为了帮助大家解决这个问题，下面小编就详细讲解一下。需要的人可以从中学习，希望你能有所收获。

简介

Eureka本身是一个网飞开源产品，提供服务注册和发现，并提供相应的Java包。在它的实现中，节点彼此相等，如果注册表的某些节点挂起，集群不会受到影响。即使集群中只剩下一个节点，也可以正常提供发现服务。即使所有的服务注册节点都死了，服务调用的信息也会被缓存在尤里卡客户端。这确保了我们的微服务之间的相互调用足够健壮。

Zookeeper主要为大规模分布式计算提供开源分布式配置服务、同步服务和命名注册。以前是Hadoop项目的子项目，用来控制集群中的数据，现在升级为独立的顶层项目。在许多情况下，它还被用作服务发现服务解决方案。

对比

分布式系统中有一个著名的CAP定理(C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特征在任何分布式系统中都不能同时满足，最多两个可以同时满足)。

Zookeeper

Zookeeper是基于CP设计的，即对Zookeeper的访问请求可以随时得到一致的数据结果，系统对网络分段是容错的，但不能保证每个服务请求的可用性。从实际情况分析，在使用zookeeper获取服务列表时，如果Zookeeper选择的是master或者Zookeeper集群中有一半以上的机器不可用，那么就不会获取数据。因此，动物园管理员不能保证服务的可用性。

诚然，在大多数分布式环境中，尤其是那些涉及数据存储的环境，首先应该保证数据的一致性，这就是为什么zookeeper被设计成CP的原因。但是对于服务发现场景，情况就不一样了：对于同一个服务，即使存储在注册中心不同节点的服务提供者的信息不同，也不会造成灾难性的后果。因为对于服务消费者来说，能够消费是最重要的；mdash最好在获取不正确的服务实例信息后尝试消费，而不是因为无法获取实例信息而不消费。(尝试会很快失败，然后可以更新配置再试一次)因此，对于服务发现来说，可用性比数据一致性mdash更重要；mdashAP打败CP。

Eureka

春云网飞在设计尤里卡时遵循了AP原则。尤里卡服务器还可以运行多个实例来构建集群和解决单点问题，但与ZooKeeper的领导者选举过程不同，尤里卡服务器使用Peer to Peer点对点通信。这是一个分散的架构。没有主/从的区别，每个对等体都是平等的。在这种架构中，节点相互注册以提高可用性，每个节点需要添加一个或多个有效的serviceUrl来指向其他节点。每个节点都可以被视为其他节点的副本。

如果尤里卡服务器发生故障，尤里卡客户端的请求将自动切换到新的尤里卡服务器节点。当故障服务器恢复后，尤里卡将再次将其纳入服务器集群管理。当节点开始接受客户端请求时，所有操作都将被复制操作者，它会将请求复制到其他尤里卡服务器当前已知的所有节点。

新的尤里卡服务器节点启动后，它将首先尝试从相邻节点获取所有实例注册表信息，以完成初始化。尤里卡服务器通过getEurekaServiceUrls()方法获取所有节点，并通过心跳更新定期更新。默认情况下，如果尤里卡服务器在一定时间内没有收到服务实例的心跳，尤里卡服务器将注销该实例(默认为90秒，由尤里卡. instance . lease-expire-duration-in-seconds配置)。当尤里卡服务器节点在短时间内丢失太多心跳(如网络分区故障)时，该节点将进入自我保护模式。

什么是自我保护模式？默认情况下，如果尤里卡服务器每分钟收到的心跳更新低于阈值(实例数(60/心跳间隔秒/实例)自我保护系数)并持续15分钟，将触发自我保护。在自我保护模式下，尤里卡服务器将保护服务注册表中的信息，并且不会注销任何服务实例。当尤里卡服务器节点接收到的心跳数恢复到阈值以上时，它将自动退出自我保护模式。它前面提到的设计理念，就是保留错误的服务注册信息，比盲目取消任何可能健康的服务实例要好。eureka . server . enable-自保=false可以禁用该模式，而eureka . instance . lease-renew-interval-in-second可以

用来更改心跳间隔，eureka.server.renewal-percent-threshold可以用来修改自我保护系数(默认0.85)。

ZooKeeper基于CP，不保证高可用，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无法获得数据。Eureka基于AP，能保证高可用，即使所有机器都挂了，也能拿到本地缓存的数据。作为注册中心，其实配置是不经常变动的，只有发版和机器出故障时会变。对于不经常变动的配置来说，CP是不合适的，而AP在遇到问题时可以用牺牲一致性来保证可用性，既返回旧数据，缓存数据。

所以理论上Eureka是更适合做注册中心。而现实环境中大部分项目可能会使用ZooKeeper，那是因为集群不够大，并且基本不会遇到用做注册中心的机器一半以上都挂了的情况。所以实际上也没什么大问题。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。