Eureka比Zookeeper好在哪里?

Eureka遵守AP,Zookeeper遵守CP

RDBMS(oracle/mysql、sqlServer) ====> ACID, 关系型数据库遵循ACID原则

NoSQL(redis/mongodb)====> CAP

一、ACID的介绍

ACID分别为:

原子性(Automicity):事务里面的所有操作,要么全部做完,要么全不做;事务成功的条件是事务里面的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚;

一致性(Consistency):数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束;也就是说:如果事务是并发多个,系统也必须如同串行事务一样操作。其主要特征是保护性和不变性(Preserving an Invariant),以转账案例为例,假设有五个账户,每个账户余额是100元,那么五个账户总额是500元,如果在这个5个账户之间同时发生多个转账,无论并发多少个,比如在A与B账户之间转账5元,在C与D账户之间转账10元,在B与E之间转账15元,五个账户总额也应该还是500元,这就是保护性和不变性。

隔离性(Isolation): 并发的事务之间不会互相影响;

持久性(Durability):在事务完成以后,该事务对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。

二、CAP的介绍

CAP分别为:强制一致性(Consistency),可用性(Availability),分区容错性(Partition tolerance):

CAP的3进2:任何一个分布式系统中,无法同时满足CAP3个原则,最多只能满足其中的2个

CAP的理论核心:任何一个分布式系统中,无法同时满足强制一致性、可用性、分区容错性这3个需求;因此,根据CAP原则将NoSQL 数据库分成满足CA原则、CP原则、AP原则三大类:

CA原则:单点集群,满足一致性、可用性的原则,通常在扩展上不太强;

CP原则:满足一致性、分区容错的系统,通常性能不是特别高;

AP原则:满足可用、分区容错的系统,通常对一致性要求低一点;

由于当前的网络硬件肯定会出现延迟丢包的问题,所以分区容错性是我们必须实现的,所以分布式系统只能在强制一致性和可用性中权衡;

因此:Zookeeper保证的是CP,Eureka保证的是AP;

当向注册中心查询服务列表时,我们可以容忍服务返回的是几分钟之前的数据,但是我们不能容忍服务之间Down掉不可用。也就是说服务的注册功能对可用性的要求高于一致性。

但是Zookeeper中会出现一种情况,当master节点因为网络故障和其他节点失去联系了时,剩余的节点会重新选举leader。但是选举leader的时间太长,30~120s,而且选举期间整个Zookeeper集群是不可用的,这就导致选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得Zookeeper的master失去联系可能性是很大的,虽然最后服务能够恢复,但是较长时间的选举导致注册的长期不可用是不能容忍的;

Eureka的各个节点是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询的服务。Eureka的客户端在向某个Eureka注册的时候,若发现连接失败,则会自动切换至其他节点,只要一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查询到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内,超过85%的节点都没有正常的心跳,那么Eureka就认为客户端和注册中心之间出现了网络故障,此时会出现以下情况:

(1)Eureka不再从注册中心表中移除因为长时间没有收到心跳而应该过期的服务;

(2)Eureka仍然能够接收新的服务注册和查询的请求,但是不会被同步到其他节点上去(即保证当前节点依然可用);

(3)当网络稳定时,当前实例新的注册信息会被同步到其他节点上去;

因此,Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会向Zookeeper那样使整个注册服务瘫痪;

原文地址:https://www.cnblogs.com/yufeng218/p/10928323.html

时间: 2024-10-10 17:29:45

Eureka比Zookeeper好在哪里?的相关文章

【Eureka篇三】Eureka比Zookeeper好在哪里?(8)

Eureka遵守AP,Zookeeper遵守CP RDBMS(oracle/mysql.sqlServer) ====> ACID, 关系型数据库遵循ACID原则 NoSQL(redis/mongodb)====> CAP 一.ACID的介绍 原子性(Automicity):事务里面的所有操作,要么全部做完,要么全不做:事务成功的条件是事务里面的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚: 一致性(Consistency):数据库要一直处于一致的状态,事务的运行不会改变数据库

eureka 和zookeeper 区别 优势【转】

作为服务注册中心,Eureka比Zookeeper好在哪里 著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性).A(可用性)和P(分区容错性).由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡.在此Zookeeper保证的是CP, 而Eureka则是AP. 4.1 Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性的要求要高于一致性.但

Eureka与Zookeeper的区别

作为服务注册中心,Eureka比Zookeeper好在哪里 著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性).A(可用性)和P(分区容错性).由于分区容错性P是在分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡. 因此 Zookeeper保证的是CP Eureka则是AP. Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性的要求要高于一致性.但是zk

eureka和ZooKeeper的区别

背景 在这边文章 中,我们将用我们在实践中遇到的问题来说明,为什么使用ZooKeeper做Service发现服务是个错误. 服务部署环境 让我们从头开始梳理.我们在部署服务的时候,应该首先考虑服务部署的平台(平台环境),然后才能考虑平台上跑的软件 系统或者如何在选定的平台上自己构建一套系统.例如,对于云部署平台来说,平台在硬件层面的伸缩(注:作者应该指的是系统的冗余性设计,即系统遇到单点失 效问题,能够快速切换到其他节点完成任务)与如何应对网络故障是首先要考虑的.当你的服务运行在大量服务器构建的

Eureka对比Zookeeper、CAP定理

eureka对比Zookeeper: Zookeeper在设计的时候遵循的是CP原则,即一致性,Zookeeper会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时剩余节点会重新进行leader选举,问题在于,选举leader的时间太长:30~120s,且选举期间整个Zookeeper集群是不可用的,这就导致在选举期间注册服务处于瘫痪状态,在云部署的环境下,因网络环境使Zookeeper集群失去master节点是较大概率发生的事情,虽然服务能够最终恢复,但是漫长的选举时间导致

Eureka与zookeeper

Eureka的优势 1.在Eureka平台中,如果某台服务器宕机,Eureka不会有类似于ZooKeeper的选举leader的过程:客户端请求会自动切换到新的Eureka节点:当宕机的服务器重新恢复后,Eureka会再次将其纳入到服务器集群管理之中:而对于它来说,所有要做的无非是同步一些新的服务注册信息而已.所以,再也不用担心有"掉队"的服务器恢复以后,会从Eureka服务器集群中剔除出去的风险了.Eureka甚至被设计用来应付范围更广的网络分割故障,并实现"0"

Springcloud 的Eureka和ZooKeeper比较

关于CAP理论,可以去看看阮一峰的文章[http://www.ruanyifeng.com/blog/2018/07/cap.html] C(一致性)A(可用性)P(分区容错性) ZooKeeper: zookeeper保证了cp(一致性.分区容错性),但是作为服务注册中心,我们可以容忍注册中心返回的是几分钟以前的注册信息.但是服务中心却必须保证可用性, 即服务注册中心对于高可用性的需求高于一致性.对于可用性,zookeeper有一个leader选举方案.当master主节点宕机与其他节点失去联

Eureka 与 ZooKeeper(一)

CAP理论:c 强一致性 a 可用性 p 分区容错性 ZooKeeper遵循的是CP,  Eureka  则是AP. Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性的要求要高于一致性.但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举.问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个

服务注册中心,Eureka与Zookeeper比较

转自https://my.oschina.net/thinwonton/blog/1622905 1. 前言 服务注册中心,给客户端提供可供调用的服务列表,客户端在进行远程服务调用时,根据服务列表然后选择服务提供方的服务地址进行服务调用.服务注册中心在分布式系统中大量应用,是分布式系统中不可或缺的组件,例如rocketmq的name server,hdfs中的namenode,dubbo中的zk注册中心,spring cloud中的服务注册中心eureka. 在spring cloud中,除了可