zookeeper 与eureka区别

CAP定理

在分布式系统的发展中,影响最大的莫过于CAP定理了,是分布式系统发展的理论基石。

  1. 2000年,加州大学的计算机科学家 Eric Brewer提出了CAP猜想

  2. 2002 年,麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP 猜想,CAP猜想成为了CAP定理

「CAP定理,简单来说就是分布式系统不可能同时满足Consistency 一致性、Availability 可用性、Partition Tolerance 分区容错性三个要素」

Consistency 一致性

一致性的含义为,在节点的任意时刻,访问任意节点返回的数据是一致的。即Client端写入一个数据后,Server端将数据同步到整个系统,从而保证系统的数据都相同

Availability 可用性

可用性的含义为,集群能够对用户的请求给予响应。

Partition Tolerance 分区容错性

分区容错的含义为,当出现分区故障时,系统仍要对外提供服务。分布式系统中,每个服务节点都是不可靠的,当某些节点出现异常时,或者节点之间的通讯产生异常时,整个系统就产生了分区问题,分布式系统中分区问题是客观存在的。

CAP权衡

CA

系统选择CA,即不支持分区容错,只支持一致性和可用性。意味着不允许出现分区异常,网络一致处于理想状态。但是分布式系统之间网络异常是客观存在的,如果避免了P,只能把分布式系统退回到单实例系统。

CP

因为分布式系统P是客观存在的,所以我们要在CP和AP之间进行抉择。

在网络分区发生时,两个分布式节点之间无法进行通信,我们对一个节点进行的修改操作将无法同步到另外一个节点,所以数据的「一致性」将无法满足,因为两个分布式节点的数据不再保持一致。除非我们牺牲「可用性」,也就是暂停分布式节点服务,在网络分区发生时,不再提供修改数据的功能,直到网络状况完全恢复正常再继续对外提供服务

「当选择CP时,相当于放弃系统的可用性,换取一致性」。zookeeper是选择了CP的系统

在zookeeper集群中,有如下三种角色

角色 作用
Leader 事务请求的唯一调度者和处理者 (事务请求为除查询之外的请求)
Follower 处理非事务请求,参与Leader选举投票
Observer 处理非事务请求,不参与选举投票

在Leader服务器失效时,会重新从Follower服务器中选举一个新的服务器作为Leader服务器。「在重新选举Leader服务器的过程中,事务请求会被挂起,选举完Leader服务器之后才会执行这些请求」。即为了保证一致性,放弃了系统的可用性

AP

「当选择AP时,相当于放弃系统一致性,换取可用性」。eureka是选择了AP的系统

和zookeeper集群中有三种角色不同的是,eureka集群中每个节点扮演相同的角色,他们通过互相注册的方式来感知对方的存在,当有注册信息时,他们会同步给集群内的其他节点。

下面我从源码角度分析一下eureka是如何放弃一致性来保证可用性的(放心,不会放源码的,说一下大概思路。源码也比较简单,有兴趣的可以看我写的博客https://blog.csdn.net/zzti_erlie/article/details/104088914)

eureka注册中心的信息保存在AbstractInstanceRegistry类的成员变量中

复制代码
// AbstractInstanceRegistry private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry  = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

就是一个双层map,这个双层map也很好理解。最外层是服务名,里面是一个具体的实例名

当有服务往eureka上注册时,注册信息会被保存在map中,同时会把信息同步给其他的节点。此时有可能有些节点不可用了,或者网络故障,并没有收到信息,此时集群节点内的信息可能是不一致的。

当客户端从某个eureka节点获取信息失败,或者注册失败,会自动切换到另一个eureka节点。只要有一台eureka节点可用,就能保证注册服务可用。

Zookeeper和Eureka的区别

最后总结一下两者的区别

Zookeeper Eureka
设计原则 CP AP
优点 数据最终一致 服务高可用
缺点 选举leader过程中集群不可用 服务节点间的数据可能不一致
适用场景 对数据一致性要求较高 对注册中心服务可用性要求较高

本文转载自:一文了解Zookeeper和Eureka有哪些区别? - 环信

如有侵权请及时联系博主删除,谢谢

相关推荐
echoyu.11 小时前
消息队列-初识kafka
java·分布式·后端·spring cloud·中间件·架构·kafka
AAA修煤气灶刘哥12 小时前
缓存这「加速神器」从入门到填坑,看完再也不被产品怼慢
java·redis·spring cloud
AAA修煤气灶刘哥12 小时前
接口又被冲崩了?Sentinel 这 4 种限流算法,帮你守住后端『流量安全阀』
后端·算法·spring cloud
T_Ghost16 小时前
SpringCloud微服务服务容错机制Sentinel熔断器
spring cloud·微服务·sentinel
喂完待续18 小时前
【序列晋升】28 云原生时代的消息驱动架构 Spring Cloud Stream的未来可能性
spring cloud·微服务·云原生·重构·架构·big data·序列晋升
惜.己1 天前
Docker启动失败 Failed to start Docker Application Container Engine.
spring cloud·docker·eureka
chenrui3102 天前
Spring Boot 和 Spring Cloud: 区别与联系
spring boot·后端·spring cloud
喂完待续2 天前
【序列晋升】29 Spring Cloud Task 微服务架构下的轻量级任务调度框架
java·spring·spring cloud·云原生·架构·big data·序列晋升
麦兜*3 天前
MongoDB 性能调优:十大实战经验总结 详细介绍
数据库·spring boot·mongodb·spring cloud·缓存·硬件架构