CAP定理下:Zookeeper、Eureka、Nacos简单分析

这篇具有很好参考价值的文章主要介绍了CAP定理下:Zookeeper、Eureka、Nacos简单分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

CAP定理下:Zookeeper、Eureka、Nacos简单分析


CAP定理

CAP定理下:Zookeeper、Eureka、Nacos简单分析,分布式,zookeeper,eureka,分布式,CAP

C: 一致性(Consistency):写操作之后的读操作也需要读到之前的
A: 可用性(Availability):收到用户请求,服务器就必须给出响应
P: 分区容错性(Partition tolerance):系统中任意信息的丢失或失败不会影响系统的继续运作

CAP定理指的是在一个分布式系统中,C、A、P三者不可兼得

由于P是无法避免的,P总是成立的,故剩下的C和A无法同时做到,因为CA场景下通信可能会失败(即出现分区容错),类似于加锁不加锁。

火车票场景:放弃一致性实现AP
银行转账:放弃分区容错性实现CA

Zookeeper

实现:CP(一致性+分区容错性)
ZK选择放弃了高可用性,为达到了强一致性,采用了ZAB(Zookeeper Atomic Broadcast)协议,即原子广播协议来保证分布式事务的一致性(C),大概内容如下:

1)发现:必须选举出一个Leader进城,维护一个Follower客户端列表
2)同步:Leader负责与Followers同步数据,多副本保存(高可用、分区容错)
3)广播:Leader可接受客户端新的proposal请求,并广播给Followers

- 所有的事务必须由一个全局唯一的服务器来协调处理
- Leader将客户端请求转换为一个事务proposal广播给所有的Followers,然后等待所有Follower的ACK确认反馈,有一半Follower反馈就会向所有Follower下发commit请求,让他们将上一个事务proposal提交执行(二阶段提交)

所以,ZK集群在进行消息同步的时候,必须由一半以上的节点完成了同步才会生效返回,当Leader或过半节点不可用时,会重新进行Leader选举(选举模式),过程中就无法对外提供服务(无A)。但是对于服务发现注册组件来说,就算无法及时获得最新的服务列表,一般也不会导致系统整体的崩溃。

Eureka

CAP定理下:Zookeeper、Eureka、Nacos简单分析,分布式,zookeeper,eureka,分布式,CAP

实现:AP(可用性+分区容错性)
从Eureka的架构可知,他使用的是去中心化的模式,各个节点是平等的且没有主从概念,通过互相通讯注册的方式来实现消息的同步,自然保证了高可用性(A)。在消息同步时,Eureka并不对消息的抵达进行保证,

Nacos

实现:CP/AP均支持
1)AP:注册时临时存在于注册中心,即临时节点模式,会在服务下线或不可用时,或是心跳检测无响应时,更新其健康状态,过一段时间进行列表节点删除。(放弃一致性)在此模式下,Nacos集群中的节点之间通过Distro协议同步实例注册消息(Distro协议保证的是最终一致性)

2)CP:注册永久节点,通过注册中心主动探活,去探测永久实例的状态,在Nacos集群中通过Raft协议更新实例列表(类似zk的ZAB协议,选举过程中nacos集群不可用)文章来源地址https://www.toymoban.com/news/detail-713887.html

到了这里,关于CAP定理下:Zookeeper、Eureka、Nacos简单分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 一篇搞定分布式大数据系统所有概念,包括有Hadoop、MapReduce、HDFS、HBASE、NoSql 、ZooKeeper 、Reidis 、Nginx 、BASE、CAP定义、特点和应用场景

    1.1hadoop定义和特点 Hadoop定义: Hadoop是一个开源的分布式计算框架,用于存储和处理大规模数据集。它基于Google的MapReduce论文和Google文件系统(GFS)的设计理念,并由Apache软件基金会进行开发和维护。 Hadoop的主要特点包括: 分布式存储:Hadoop通过分布式文件系统(Hadoop Dist

    2024年02月03日
    浏览(53)
  • Eureka:CAP原则及对比Zookeeper

             

    2024年02月12日
    浏览(35)
  • 服务注册与发现Eureka、Zookeeper、Consul 三个注册中心的异同点(CAP理论)

    Eureka Eureka是由Netflix开源的一个服务注册和发现组件,它主要用于构建高可用、分布式系统的基础设施中。Eureka的服务器端被称为Eureka Server,客户端则是那些需要注册的服务。Eureka具有以下特点: 高可用性 :Eureka支持多节点部署,能够在节点故障时自动进行故障转移。 自我

    2024年04月22日
    浏览(33)
  • 【简单认识zookeeper+kafka分布式消息队列集群的部署】

    Zookeeper是一个开源的分布式的,为分布式框架提供协调服务的Apache项目。 Zookeeper从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper就将负责通知已

    2024年02月13日
    浏览(40)
  • 【分布式锁】06-Zookeeper实现分布式锁:可重入锁源码分析

    前言 前面已经讲解了Redis的客户端Redission是怎么实现分布式锁的,大多都深入到源码级别。 在分布式系统中,常见的分布式锁实现方案还有Zookeeper,接下来会深入研究Zookeeper是如何来实现分布式锁的。 Zookeeper初识 文件系统 Zookeeper维护一个类似文件系统的数据结构 image.png 每

    2024年02月22日
    浏览(46)
  • 分布式系统的一致性级别划分及Zookeeper一致性级别分析

    在谈到Zookeeper的一致性是哪种级别的一致性问题,以及CAP原则中的C是哪一种一致性级别时有些疑惑。 下面是大多数文章中提到的一致性级别 一致性(Consistency)是指多副本(Replications)问题中的数据一致性。可以分为强一致性、顺序一致性与弱一致性。 1.1 强一致性(Stric

    2024年04月12日
    浏览(58)
  • 分布式理论:CAP理论 BASE理论

    解决分布式事务问题,需要一些分布式系统的基础知识作为理论指导。 Consistency(一致性): 用户访问分布式系统中的任意节点,得到的数据必须一致 Availability(可用性): 用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝。 Partition(分区): 因为网络故障或其

    2024年02月15日
    浏览(42)
  • 分布式理论CAP、BASE和RPC

    CAP原则是指当分布式系统遇到网络分区时,只能满足其中两个需求,一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)。在实际系统中,我们常常会选择在CA、CP或AP三者中做出取舍。 CA模型 CA模型要求分布式系统保持强一致性,即所有节点上的数据都

    2023年04月10日
    浏览(37)
  • 分布式之CAP理论与BASE理论

    CAP:一致性(consistency)、可用性(Availability)、分区容错(partition-tolerance)。CAP定律说的是在一个分布式计算机系统中,一致性,可用性和分区容错性这三种保证无法同时得到满足,最多满足两个。 系统在执行过某项操作后仍然处于一致的状态。在分布式系统中,更新操作

    2024年02月11日
    浏览(44)
  • eureka、zookeeper、nacos区别

    在分析eureka、zookeeper、nacos区别前,需要先清楚服务注册、服务发现是什么? 在传统的系统部署中, 服务运行在一个固定的已知的 IP 和端口上 ,如果一个服务需要调用另外一个服务,可以 通过地址直接调用 。但是,在微服务架构下,服务实例的启动和销毁是很频繁的, 服

    2024年02月07日
    浏览(34)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包