ZooKeeper与Eureka对比

简介

  Eureka [ j?‘rik? ]本身是Netflix开源的一款提供服务注册和发现的产品,并且提供了相应的Java封装。在它的实现中,节点之间相互平等,部分注册中心的节点挂掉也不会对集群造成影响,即使集群只剩一个节点存活,也可以正常提供发现服务。哪怕是所有的服务注册节点都挂了,Eureka Clients(客户端)上也会缓存服务调用的信息。这就保证了我们微服务之间的互相调用足够健壮。

  Zookeeper主要为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。曾经是Hadoop项目中的一个子项目,用来控制集群中的数据,目前已升级为独立的顶级项目。很多场景下也用它作为Service发现服务解决方案。

对比

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

Zookeeper

  Zookeeper是基于CP来设计的,即任何时刻对Zookeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性,但是它不能保证每次服务请求的可用性。从实际情况来分析,在使用Zookeeper获取服务列表时,如果zookeeper正在选主,或者Zookeeper集群中半数以上机器不可用,那么将无法获得数据。所以说,Zookeeper不能保证服务可用性。

  诚然,在大多数分布式环境中,尤其是涉及到数据存储的场景,数据一致性应该是首先被保证的,这也是zookeeper设计成CP的原因。但是对于服务发现场景来说,情况就不太一样了:针对同一个服务,即使注册中心的不同节点保存的服务提供者信息不尽相同,也并不会造成灾难性的后果。因为对于服务消费者来说,能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下,也好过因为无法获取实例信息而不去消费。(尝试一下可以快速失败,之后可以更新配置并重试)所以,对于服务发现而言,可用性比数据一致性更加重要——AP胜过CP。

Eureka

  而Spring Cloud Netflix在设计Eureka时遵守的就是AP原则。Eureka Server也可以运行多个实例来构建集群,解决单点问题,但不同于ZooKeeper的选举leader的过程,Eureka Server采用的是Peer to Peer对等通信。这是一种去中心化的架构,无master/slave区分,每一个Peer都是对等的。在这种架构中,节点通过彼此互相注册来提高可用性,每个节点需要添加一个或多个有效的serviceUrl指向其他节点。每个节点都可被视为其他节点的副本。

  如果某台Eureka Server宕机,Eureka Client的请求会自动切换到新的Eureka Server节点,当宕机的服务器重新恢复后,Eureka会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时,所有的操作都会进行replicateToPeer(节点间复制)操作,将请求复制到其他Eureka Server当前所知的所有节点中。

  一个新的Eureka Server节点启动后,会首先尝试从邻近节点获取所有实例注册表信息,完成初始化。Eureka Server通过getEurekaServiceUrls()方法获取所有的节点,并且会通过心跳续约的方式定期更新。默认配置下,如果Eureka Server在一定时间内没有接收到某个服务实例的心跳,Eureka Server将会注销该实例(默认为90秒,通过eureka.instance.lease-expiration-duration-in-seconds配置)。当Eureka Server节点在短时间内丢失过多的心跳时(比如发生了网络分区故障),那么这个节点就会进入自我保护模式。

什么是自我保护模式?默认配置下,如果Eureka Server每分钟收到心跳续约的数量低于一个阈值(instance的数量(60/每个instance的心跳间隔秒数)自我保护系数),并且持续15分钟,就会触发自我保护。在自我保护模式中,Eureka Server会保护服务注册表中的信息,不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时,该Eureka Server节点就会自动退出自我保护模式。它的设计哲学前面提到过,那就是宁可保留错误的服务注册信息,也不盲目注销任何可能健康的服务实例。该模式可以通过eureka.server.enable-self-preservation = false来禁用,同时eureka.instance.lease-renewal-interval-in-seconds可以用来更改心跳间隔,eureka.server.renewal-percent-threshold可以用来修改自我保护系数(默认0.85)。

总结

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

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

原文地址:https://www.cnblogs.com/jasontec/p/9651820.html

时间: 2024-10-18 13:42:32

ZooKeeper与Eureka对比的相关文章

从CAP到zookeeper和eureka对比

今天看了一篇eureka对比zookeeper的文章,对zookeeper满足CAP中的CP,eureka满足AP产生了一点疑问,故写此篇文章进行一些探讨. 首先我们来看看CAP的定义 Consistency 中文叫做"一致性".意思是,写操作之后的读操作,必须返回该值.举例来说,某条记录是 v0,用户向 G1 发起一个写操作,将其改为 v1,接下来,用户的读操作就会得到 v1.这就叫一致性. Availability 中文叫做"可用性",意思是只要收到用户的请求,

Eureka对比Zookeeper、CAP定理

eureka对比Zookeeper: Zookeeper在设计的时候遵循的是CP原则,即一致性,Zookeeper会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时剩余节点会重新进行leader选举,问题在于,选举leader的时间太长:30~120s,且选举期间整个Zookeeper集群是不可用的,这就导致在选举期间注册服务处于瘫痪状态,在云部署的环境下,因网络环境使Zookeeper集群失去master节点是较大概率发生的事情,虽然服务能够最终恢复,但是漫长的选举时间导致

Consul zookeeper etcd eureka

这里就平时经常用到的服务发现的产品进行下特性的对比,首先看下结论: Feature Consul zookeeper etcd eureka 服务健康检查 服务状态,内存,硬盘等 (弱)长连接,keepalive 连接心跳 可配支持 多数据中心 支持 - - - kv存储服务 支持 支持 支持 - 一致性 raft paxos raft - cap ca cp cp ap 使用接口(多语言能力) 支持http和dns 客户端 http/grpc http(sidecar) watch支持 全量/

两大微服务 注册中心 ZooKeeper 和 Eureka 的区别

===>>spring cloud集成zookeeper例子:https://www.cnblogs.com/li-zhan/p/9401692.html ZooKeeper 和 Eureka 的区别 鉴于服务发现对服务化架构的重要性,Dubbo 实践通常以 ZooKeeper 为注册中心(Dubbo 原生支持的 Redis 方案需要服务器时间同步,且性能消耗过大). 针对分布式领域著名的 CAP 理论(C——数据一致性,A——服务可用性,P——服务对网络分区故障的容错性), Zookeepe

Consul vs. Zookeeper vs. Eureka

https://stackshare.io/stackups/consul-vs-eureka-vs-zookeeper Open Source Service Discovery     Favorites 61 Stacks 397 Fans 346 Votes 177 Jobs 394 Favorites 25 Stacks 313 Fans 201 Votes 34 Jobs 363 Favorites 17 Stacks 82 Fans 93 Votes 40 Jobs 46 Hack

zookeeper和Eureka对CAP理论的支持

著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性).A(可用性)和P(分区容错性).由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡.在此Zookeeper保证的是CP, 而Eureka则是AP. Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性的要求要高于一致性.但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失

Zookeeper 和Eureka比较

作为服务注册中心,Eureka比Zookeeper好在哪里著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性).A(可用性)和P(分区容错性).由于分区容错性P在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡.因此Zookeeper保证的是CP,Eureka则是AP. 4.1 Zookeeper保证CP当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性的要求要高于一致性.但是zk

Eureka -- 浅谈Eureka

目录: 一:Eureka介绍 二:Eureka架构图 三:Eureka组件 四:Eureka作用 五:Eureka和Zookeeper对比 什么是Eureka 引入SpringCloud中文文档介绍 Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load

基于zookeeper的分布式配置中心(一)

最近在学习zookeeper,发现zk真的是一个优秀的中间件.在分布式环境下,可以高效解决数据管理问题.在学习的过程中,要深入zk的工作原理,并根据其特性做一些简单的分布式环境下数据管理工具.本文首先对zk的工作原理和相关概念做一下介绍,然后带大家做一个简单的分布式配置中心. zookeeper介绍 zookeeper是一个分布式协调框架,主要是解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务.状态同步服务.集群管理.分布式应用配置项的管理.分布式锁等. zookeeper使用 查看