Eureka和zookeeper的区别
Eureka和zookeeper的区别
前⾔
最近在⾯试的时候，被问到了这个问题，作答的不是很好，在此进⾏整理和学习，希望能够帮助⼤家。
CAP理论
在了解eureka和zookeeper区别之前，我们先来了解⼀下这个知识，cap理论。
1998年的加州⼤学的计算机科学家 Eric Brewer 提出，分布式有三个指标。Consistency，Availability，Partition tolerance。简称即为CAP。Eric 提出 CAP 不能全部达到，这就是CAP定理。
接下来我们分别说下cap。
C
Consistency，⼀致性的意思。
⼀致性就是说，我们读写数据必须是⼀摸⼀样的。
⽐如⼀条数据，分别存在两个服务器中，server1和server2。
我们此时将数据a通过server1修改为数据b。此时如果我们访问server1访问的应该是b。
当我们访问server2的时候，如果返回的还是未修改的a，那么则不符合⼀致性，如果返回的是b，则符合数据的⼀致性。
A
Availability，可⽤性的意思。
这个⽐较好理解，就是说，只要我对服务器，发送请求，服务器必须对我进⾏相应，保证服务器⼀直是可⽤的。
国庆节佳句简短
P
Partition tolerance，分区容错的意思。
⼀般来说，分布式系统是分布在多个位置的。⽐如我们的⼀台服务器在北京，⼀台在上海。可能由于天⽓等原因的影响。造成了两条服务器直接不能互相通信，数据不能进⾏同步。这就是分区容错。我们认为，分区容错是不可避免的。也就是说 P 是必然存在的。
为什么CAP只能达到 CP 或者 AP？
信阳职业技术学院录取查询由以上我们得知，P是必然存在的。
如果我们保证了CP，即⼀致性与分布容错。当我们通过⼀个服务器修改数据后，该服务器会向另⼀个服务器发送请求，将数据进⾏同步，但此时，该数据应处于锁定状态，不可再次修改，这样，如果此时我们想服务器发送请求，则得不到相应，这样就不能A，⾼可⽤。
如果我们保证了AP，那么我们不能对服务器进⾏锁定，任何时候都要得到相应，那么数据的⼀致性就不好说了。
eureka和zookeeper的cap理论
eureka是基于ap的。zookeeper是基于cp的。
Eureka的实现
eureka的架构实现图如下：
eureka的基本原理
上图是来⾃eureka的官⽅架构图，这是基于集配置的eureka；
处于不同节点的eureka通过Replicate进⾏数据同步
Application Service为服务提供者
Application Client为服务消费者
Make Remote Call完成⼀次服务调⽤蛋白质含量高的食物
服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进⾏同步，当服务消费者要调⽤服务提供者，则向服务注册中⼼获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调⽤时，则直接从本地缓存中取，完成⼀次调⽤。
当服务注册中⼼Eureka Server检测到服务提供者因为宕机、⽹络原因不可⽤时，则在服务注册中⼼将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。
服务提供者在启动后，周期性（默认30秒）向Eureka Server发送⼼跳，以证明当前服务是可⽤状态。Eureka Server在⼀定的时间（默认90
秒）未收到客户端的⼼跳，则认为服务宕机，注销该实例。
eureka的⾃我保护机制
在默认配置中，Eureka Server在默认90s没有得到客户端的⼼跳，则注销该实例，但是往往因为微服务跨进程调⽤，⽹络通信往往会⾯临着各种问题，⽐如微服务状态正常，但是因为⽹络分区故障时，Eureka Server注销服务实例则会让⼤部分微服务不可⽤，这很危险，因为服务明明没有问题。
为了解决这个问题，Eureka 有⾃我保护机制，通过在Eureka Server配置如下参数，可启动保护机制。
able-self-preservation=true
它的原理是，当Eureka Server节点在短时间内丢失过多的客户端时（可能发送了⽹络故障），那么这个节点将进⼊⾃我保护模式，不再注销任何微服务，当⽹络故障回复后，该节点会⾃动退出⾃我保护模式。
eureka保证ap
海南水果特产eureka优先保证可⽤性。在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会⾃动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳⼊到服务器集管理之中；⽽对于它来说，所有要做的⽆⾮是同步⼀些新的服务注册信息⽽已。所以，再也不⽤担⼼有“掉队”的服务器恢复以后，会从Eureka服务器集中剔除出去的风险
了。Eureka甚⾄被设计⽤来应付范围更⼴的⽹络分割故障，并实现“0”宕机维护需求。当⽹络分割故障发⽣时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样⼀来，就可以实现在同⼀个⼦⽹中（same side of partition），新发布的服务仍然可以被发现与访问。Eureka各个节点都是平等的，⼏个节点挂掉不会影响正常节点的⼯作，剩余的节点依然可以提供注册和查询服务。⽽Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会⾃动切换⾄其它节点，只要有⼀台Eureka还在，就能保证注册服务可⽤(保证可⽤性)，只不过查到的信息可能不是最新的(不保证强⼀致性)。除此之外，Eureka还有⼀种⾃我保护机制，如果在15分钟内超过85%的节点都没有正常的⼼跳，那么Eureka就认为客户端与注册中⼼出现了⽹络故障，此时会出现以下⼏种情况：
1. Eureka不再从注册列表中移除因为长时间没收到⼼跳⽽应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可⽤)
3. 当⽹络稳定时，当前实例新的注册信息会被同步到其它节点中
Eureka还有客户端缓存功能（注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接⼝）。所以即便Eureka集中所有节点都失效，或者发⽣⽹络分割故障导
致客户端不能访问任何⼀台Eureka服务器；Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚⾄最极端的环境下，所有正常的Eureka节点都不对请求产⽣相应，也没有更好的服务器解决⽅案来解决这种问题时；得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息。
zookeeper保证cp
作为⼀个分布式协同服务，ZooKeeper⾮常好，但是对于Service发现服务来说就不合适了；因为对于Service发现服务来说就算是返回了包含不实的信息的结果也⽐什么都不返回要好；再者，对于Service发现服务⽽⾔，宁可返回某服务5分钟之前在哪⼏个服务器上可⽤的信息，也不能因为暂时的⽹络故障⽽不到可⽤的服务器，⽽不返回任何结果。所以说，⽤ZooKeeper来做Service发现服务是肯定错误的。
仙剑歌曲
当向注册中⼼查询服务列表时，我们可以容忍注册中⼼返回的是⼏分钟以前的注册信息，但不能接受服务直接down掉不可⽤。也就是说，服务注册功能对可⽤性的要求要⾼于⼀致性。但是zk会出现这样⼀种情况，当master节点因为⽹络故障与其他节点失去联系时，剩余节点会重新进⾏leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集都是不可⽤的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因⽹络问题使得zk集失去master节点是较⼤概率会发⽣的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可⽤是不能容忍的。
奔驰最便宜的跑车
eureka和zookeeper的区别总结
Eureka可以很好的应对因⽹络故障导致部分节点失去联系的情况，⽽不会像zookeeper那样使整个注册服务瘫痪。Eureka作为单纯的服务注册中⼼来说要⽐zookeeper更加“专业”，因为注册服务更重要的是可⽤性，我们可以接受短期内达不到⼀致性的状况。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。