ZooKeeper与Eureka的区别

我们来看Zookeeper与Eureka的一个区别,在这里准备了一个表格,在这里通过对比项,来对比Zookeeper与Eureka的

一个区别,我们先从CAP来看Zookeeper与Eureka的一个区别,Zookeeper当中是支持CP而放弃了A,而Eureka当中是支持AP,

而放弃了C,我们通过这个对比项呢,可以看出来,无论是Zookeeper还是Eureka,他都支持分区容错的,只不过Zookeeper是

支持数据一致性,而放弃了可用性,而Eureka当中呢,是支持了可用性,而放弃了一致性,那么我先来看一下,Zookeeper,

Zookeeper为什么会支持数据一致性,而放弃了可用性呢,其实原因是Zookeeper技术的一个特点,天然具备数据一致性,

2为什么说他天然具备数据一致性呢,我们用的Zookeeper的都知道,要想搭建一个Zookeeper集群,无论是有多少个节点,

最终都是一个主从关系的,其他的都是从节点,然后我们所有的服务注册,是以主节点为主的,一旦主节点宕掉了,然后再通过

他的一些算法,正因为他每次对于服务的注册,都在一个设备上完成,所以它是具备数据一致性的,那么P容错性,容错性它是怎么

做的呢,这个大家应该能知道,其实Leader拿到信息以后,最终它是通过复制的方式,Leader当中的数据,同步到从节点当中,Zookeeper

他经常要做主从节点的同步,势必会影响到他的性能,所以Zookeeper由于他的设计的原因,所以他只能选择CP,而放弃A,因为他经常

要做主从备份,主从同步,那么在同步的过程当中,如果你的数据量比较大,几兆甚至几十兆,甚至上百兆,在这一段时间范围内,同步的

过程当中,他的服务是不可用的,所以他放弃了A,保留了CP,我们再来看Eureka,Eureka跟Zookeeper不同的是,保证了高可用,那么他

保证了可用性,保证了可用性的原因是什么呢,Eureka的集群我们自己也搭过,他跟Zookeeper是不一样的,不具备这种主从关系,

他所有的节点几乎都是平等的,我们之前讲Eureka的架构原理也说过,Eureka当中呢,他的每一个节点,相互之间都是平等的,不具备

主从的问题,当我们要去请求拿Zookeeper服务的时候,正因为有这样一个原因,不具备主从关系,所有集群当中的某一个节点,所以

他就不具备数据一致性了,Zookeeper他有一个Leader,所有的操作都是以Leader为主的,所以它是具备数据一致性的,那么他就不具备

数据一致性了,说明他肯定具备服务的可用性,然后再来看他的key,分区容错性,Eureka当中是怎么来实现的呢,跟Zookeeper还是有

区别的,Zookeeper的分区容错,采用的是主从复制的一个方式,Eureka是什么呢,Eureka也是通过主从复制的方式来完成的,但是他跟

Zookeeper不同的是什么呢,他并不是从一个主的复制到从的,他是这样的,节点和节点之中呢,或者节点和服务之间,会发心跳包,讲

架构原理的时候说过,如果集群当中有一个节点,在发心跳包时,某个节点没有收到另一个节点的心跳包,或者某个服务没有收到某个

服务的心跳包,那么这个时候,Eureka注册中心,会将这个服务做一个服务的保护,所谓的服务保护是什么意思呢,他并不是真正的把这个

服务从注册中心中删掉,并不是从集群里把这个节点删掉,因为他要考虑到,导致心跳包没有返回的原因,除了服务或者节点出现问题

以外,还有一种可能是,网络阻塞,那么网络阻塞时间是不可控的,有的时候可能是几秒钟,有的时候可能是几分钟,也有可能是几个小时,

那么网络故障不代表我服务不可用,所以Eureka有想到这一点了,会把注册中心当中的信息,无论是服务还是其他子节点的信息,他都做了

一个服务的保护,注册中心不也是服务吗,我们所谓的做Eureka集群,不就是做多个服务的集群吗,所以他会将没有收到心跳包的服务,

做一个服务的保护,他并不是真的从这里删除掉了,那么他 采用这种方式的原则是什么呢,我并不会从这里去删除数据,因为无论什么

情况下,你出现问题了,我没有收到你的心跳包,我也会把你保留着,为什么这么做呢,虽然我没有收到你的心跳包,但是我总觉得有总比

没有强,未来你的节点一旦被修复了,是不是还可以直接来使用,所以他是采用这种机制来做的分区容错,这个大家应该能够听明白吧,

Zookeeper采用的是主从同步的关系,而Eureka是采用节点与节点之间的同步,某个节点出现问题了,并不会真的把这个节点从服务中

删除掉,而是开启一个服务保护,等着你修复再加入到集群当中,是这样的一个道理,这是他们两个的一个区别,然后再看Dubbo,

对于Dubbo的支持,Zookeeper是支持Dubbo集成的,而Eureka当前来看是不支持Dubbo的,然后SpringCloud集成,Zookeeper也是

支持SpringCloud,也就是SpringCloud也是可以支持Zookeeper作为注册中心,当然SpringCloud也内置了Eureka注册中心,

然后kv服务,就是数据落地存储这一块,Zookeeper是支持的,而Eureka是不支持的,Eureka的数据都是在内存当中的,是不支持存储的,

而Zookeeper是支持的,然后再来看使用接口,多语言的能力,Zookeeper是以提供客户端的方式来支持Zookeeper的,我们知道装完

Zookeeper以后,Zkcli这是他的客户端,也就是Zookeeper到底支持多少种语言,他提供了多少个语言的客户端,Zookeeper对于多语言

支持这一块还是比较弱的,Eureka对于多语言支持还是比较强的,为什么呢,因为他不是以客户端方式来访问Eureka,来访问注册中心的,

它是以http协议加restful的风格,来访问的,只要你的语言支持HTTP协议,都可以支持我们的Eureka,所以对于多语言这一块呢,

Eureka支持的更多一些,然后还有一个就是watch的支持,这个watch是什么呢,我们来看一下,什么是watch支持,客户端监听服务端的

变化情况,zk就是我们的zookeeper,通过订阅监听来实现,Eureka和zookeeper都是支持watch的,然后再来看集群监控,在zookeeper

当中呢,它是不支持集群监控的,而eureka是通过metrics组件支持监控的,也就是运维人员呢可以通过metrics收集并报警这些

度量信息达到监控目的,所以这也是zookeeper和eureka对于集群监控这一块的区别,以上我们通过这几个维度呢,对Zookeeper和Eureka

做了一个比较,他们之间不存在好与坏的问题,谁的性能高谁的性能低的问题,只是说在不同的场景下,我们该如何去选择注册中心,要基于

我们不同的场景和需求来决定,我们通过这几个对比项就完成了zookeeper和eureka区别的比较

 

ZookeeperEureka都是用于实现分布式系统中的服务注册与发现的工具。 Zookeeper是一个开源的分布式协调服务,主要用于解决分布式应用中的一致性问题。它提供了一个分布式的、高可用的、有序的节点存储服务,可以被广泛应用于分布式数据、分布式协调、分布式锁等场景。Zookeeper的核心概念是Znode,可以通过创建、删除、更新、监控Znode来实现分布式系统中的数据管理与同步。在服务注册与发现场景中,Zookeeper可以作为一个注册中心,每个服务实例将自己注册到Zookeeper上,其他服务通过监听Zookeeper上的节点变化来实现服务的发现。 Eureka是Netflix开源的一个服务注册与发现框架,主要用于构建具有弹性的、可水平扩展的微服务体系。Eureka采用了一种去中心化的架构,通过将服务注册信息存储在各个节点上来实现高可用性与水平扩展。Eureka具有自我保护机制,能够在网络不稳定或者部分节点宕机的情况下保证服务的正常运行。在Eureka中,每个服务实例称为一个应用,通过心跳机制注册自己的信息到Eureka Server上。其他服务可以通过查询Eureka Server来获取可用服务实例的信息,实现服务的发现与负载均衡。 总的来说,ZookeeperEureka都是用于实现服务注册与发现的工具,但在实现方式、架构以及功能上存在一些区别Zookeeper更强调数据一致性与分布式协调,而Eureka则更注重可扩展性与弹性。选择使用哪个工具取决于具体的需求与场景。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值