Zookeeper 与 eureka的区别

本文探讨了CAP定理在服务发现领域的应用,对比分析了Zookeeper与Eureka的设计理念。Zookeeper遵循CP原则,强调数据一致性和分区容忍性;而Eureka遵循AP原则,更注重系统的高可用性。通过具体场景说明了两者在节点故障情况下的表现差异。

1.CAP定理:

从图中我们可以看到,zk为cp,erreka为ap

2.可用性.

zk主从设计,如果zk节点有一半吧节点宕机或者有节点正在选举,此时zk集群不可用.

eureka,p2p点对点设计,每个点的信息都可以用户接入,每个点如果信息变化,它内部会自动同步所有数据,eureka即使所有节点都宕机,仍然能提供服务,所以,对于服务发现而言,可用性比数据一致性更加重要,AP胜过CP

比如说,有三台机器,S1,S2,S3.这三台机器要两两注册,所以当S1宕机,我们还可以继续从S2,S3中获取服务.

3.运行

zk是服务端主动发现客户端,因此它的节点是持久性.

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、付费专栏及课程。

余额充值