从CAP到zookeeper和eureka对比

今天看了一篇eureka对比zookeeper的文章,对zookeeper满足CAP中的CP,eureka满足AP产生了一点疑问,故写此篇文章进行一些探讨。

首先我们来看看CAP的定义

Consistency

  中文叫做"一致性"。意思是,写操作之后的读操作,必须返回该值。举例来说,某条记录是 v0,用户向 G1 发起一个写操作,将其改为 v1,接下来,用户的读操作就会得到 v1。这就叫一致性。

Availability

  中文叫做"可用性",意思是只要收到用户的请求,服务器就必须给出回应。用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器,只要收到请求,就必须告诉用户,到底是 v0 还是 v1,否则就不满足可用性。

Partition tolerance:

  中文叫做"分区容错",大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区(partition)。分区容错的意思是,区间通信可能失败。比如,一台服务器放在中国,另一台服务器放在美国,这就是两个区,它们之间可能无法通信。

即在一个分布式系统中,只能满足其中的两个,且在一般情况下,都是要满足分区容错性的。

eureka的AP特性

eureka既然说满足AP特性,是否说明eureka是一个不满足一致性的注册中心呢,这样一来作为一个注册中心中间件肯定是无法接受的,所以我们来细究下。

Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性),其中说明了,eureka是不满足强一致性,但还是会保证最终一致性,所以可以得出一个结论,eureka不是不满足一致性,只是在同等情况下,eureka会首先保证可用性,在一定程度内再去进行一致性的同步。

zookeeper的CP特性

同样我们来看zookeeper,zookeeper在选举leader时,会停止服务,直到选举成功之后才会再次对外提供服务,这个时候就说明了服务不可用,但是在选举成功之后,因为一主多从的结构,zookeeper在这时还是一个高可用注册中心,只是在优先保证一致性的前提下,zookeeper才会顾及到可用性。

总结

所以这里从zk的CP和eureka的AP探讨得出一个结果,CAP其实在分布式系统中,是优先保证满足其中两个特性,而不是传统意义上的单纯只满足其中两个特性而舍弃另一个特性。

原文地址:https://www.cnblogs.com/hszwx/p/11595160.html

时间: 2024-10-30 06:25:35

从CAP到zookeeper和eureka对比的相关文章

ZooKeeper与Eureka对比

简介 Eureka [ j?'rik? ]本身是Netflix开源的一款提供服务注册和发现的产品,并且提供了相应的Java封装.在它的实现中,节点之间相互平等,部分注册中心的节点挂掉也不会对集群造成影响,即使集群只剩一个节点存活,也可以正常提供发现服务.哪怕是所有的服务注册节点都挂了,Eureka Clients(客户端)上也会缓存服务调用的信息.这就保证了我们微服务之间的互相调用足够健壮. Zookeeper主要为大型分布式计算提供开源的分布式配置服务.同步服务和命名注册.曾经是Hadoop项

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

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

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

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使用 查看