CAP理论&ZK&Eureka

22 篇文章 0 订阅
9 篇文章 0 订阅

如果我们期待实现一套严格满足ACID(Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性)的分布式事务,很可能的情况就是系统的可用性和严格一致性出现冲突。在可用性和一致性之间永远无法存在一个两全其美的方案。

CAP理论

2000年7月,加州大学伯克利分校Eric Brewer教授提出了著名的CAP猜想。2年后,来自麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP,从此CAP定理成为了分布式计算领域公认的定理。
CAP理论告诉我们:一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)、分区容错性(P:Partition tolerance)这三个基本需求,并且最多只能满足其中的两项
* 一致性:指更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致
* 可用性:指用户在访问数据时可以得到及时的响应
* 分区容错性:指分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务

一致性

一致性是指从系统外部读取系统内部的数据时,在一定约束条件下相同,即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同,可以将一致性级别分为如下几种:
* 强一致性(strong consistency)。任何时刻,任何用户都能读取到最近一次成功更新的数据。
* 单调一致性(monotonic consistency)。任何时刻,任何用户一旦读到某个数据在某次更新后的值,那么就不会再读到比这个值更旧的值。也就是说,可  获取的数据顺序必是单调递增的。
* 会话一致性(session consistency)。任何用户在某次会话中,一旦读到某个数据在某次更新后的值,那么在本次会话中就不会再读到比这值更旧的值   会话一致性是在单调一致性的基础上进一步放松约束,只保证单个用户单个会话内的单调性,在不同用户或同一用户不同会话间则没有保障。示例case:php的  session概念。
* 最终一致性(eventual consistency)。用户只能读到某次更新后的值,但系统保证数据将最终达到完全一致的状态,只是所需时间不能保障。
* 弱一致性(weak consistency)。用户无法在确定时间内读到最新更新的值。

ZooKeeper

分析:可用性(A:Available)
不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注:也就是在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。所以说,ZooKeeper不能保证服务可用性。
进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说,ZooKeeper不能保证服务可用性。

Eureka保证AP

Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中

因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。
Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”,因为注册服务更重要的是可用性,我们可以接受短期内达不到一致性的状况。不过Eureka目前1.X版本的实现是基于servlet的java web应用,它的极限性能肯定会受到影响。期待正在开发之中的2.X版本能够从servlet中独立出来成为单独可部署执行的服务。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Nacos、Eureka和Zookeeper都是服务发现和注册中心,但它们有一些区别: 1. Nacos是阿里巴巴开源的服务发现和配置中心,支持服务发现、配置管理、动态DNS服务等功能。Eureka是Netflix开源的服务发现组件,主要用于AWS云平台上的服务注册和发现。Zookeeper是Apache开源的分布式协调服务,可以用于服务发现、配置管理、分布式锁等。 2. Nacos支持多种协议,如HTTP、DNS、gRPC等,可以适应不同的场景。Eureka只支持HTTP协议。Zookeeper也支持多种协议,如TCP、UDP、HTTP等。 3. Nacos支持服务配置管理,可以动态修改服务的配置信息。Eureka和Zookeeper也支持配置管理,但需要自己实现。 4. Nacos支持服务健康检查,可以检测服务的状态。Eureka和Zookeeper也支持健康检查,但需要自己实现。 5. Nacos支持服务路由和流量控制,可以实现服务的负载均衡和限流。Eureka和Zookeeper不支持路由和流量控制。 总的来说,Nacos功能比Eureka和Zookeeper更全面,但也更复杂一些。选择哪个服务发现和注册中心,需要根据具体的需求和场景来决定。 ### 回答2: Nacos,Eureka和Zookeeper(ZK)都是非常流行的服务注册中心和配置中心。现在,让我们一起探讨这三个工具的区别。 1. 用途 Nacos和Eureka都是用于服务发现和注册的。相比之下,Zookeeper不仅支持服务发现和注册,还提供了分布式协调的功能,例如分布式锁,分布式队列,以及提供了分布式事务管理。 2. 架构 Eureka和Zookeeper都是为了实现分布式系统架构而开发的,而Nacos是较为新的用于云原生环境的服务中心。Eureka是一个基于REST(Representational State Transfer)的框架,可以轻松部署在AWS云上。Zookeeper是一个为分布式系统提供协调和服务发现的平台。Nacos则是一个更加现代的框架,可以轻松集成Spring Cloud、Dubbo等微服务组件。 3. 数据结构 Eureka和Nacos都使用基于HTTP REST的API,用于服务注册和发现。Zookeeper使用了基于ZAB (ZooKeeper Atomic Broadcast)协议的复制流。此外,Zookeeper还有一种称为ZNode的数据模型,ZNode是一个具有一系列属性的文件节点,保存着状态、权限、元数据、时间戳等等。 4. 一致性 在分布式系统中,一致性一直是一个很大的问题。Zookeeper使用了zab协议来达到一致性。Eureka则使用了AP(availability和partition tolerance可用性和分区容忍性)服务来保证高可用性。Nacos采用自适应 Raft 算法和发布/订阅事件通知机制来实现数据一致性。 总而言之,Eureka、Nacos和Zookeeper都是使用服务注册和发现的工具,各有优劣。Eureka是较为成熟的框架,Zookeeper则是更灵活,而Nacos则可以更好地支持云原生架构。这些工具的选择取决于企业的需求,应该根据实际情况做出选择。 ### 回答3: Nacos、Eureka和Zookeeper(ZK)都是基于云原生和微服务的服务注册中心,但它们在功能和设计上存在一些区别。 首先,Nacos是阿里开源的一款服务注册和配置中心,它支持服务的发现、配置、流量管理等。相较于EurekaZK,Nacos具有更强的动态配置管理和服务发现功能,并且能够将服务注册、配置管理和DNS等功能统一实现。同时,Nacos还具有集群管理和命名空间隔离的特点,可以实现对不同环境、不同部门的服务管理。 Eureka是Netflix开源的一款具有服务注册和发现功能的组件,旨在由应用程序进行自我注册并提供服务的可用性。与Nacos相比,Eureka较为轻量级,适用于单一环境、少量服务的场景。另外,Eureka的容错机制不如Nacos,所以在轻量级环境下使用可以满足要求,但在高可用性和高性能的场景下有所不足。 Zookeeper是一款分布式应用程序协调服务,其主要作用是为分布式应用提供一个可靠的协调服务,包括配置管理、集群管理、服务发现等功能。与Nacos和Eureka相比,ZK的主要优势在于其对事务的支持,以及支持分布式锁的特性。但ZK的设计较为简约,配置管理和服务发现等功能相较于Nacos和Eureka而言不如灵活和全面。 总之,三者都是当前服务注册中心的主流解决方案,具有不同的优势。当需要对大规模的服务进行动态配置管理、服务发现和负载均衡等操作时,Nacos是更好的选择。而Eureka则适用于较小规模的简单应用,而ZK则用于特定需要分布式锁或事务的场景。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值