为什么Eureka是AP，zookeeper是CP

为什么Eureka是AP，zookeeper是CP 这个问题大多数人的回答是因为ZK如果leader挂了，那么会进行投票选举，而选举的时候ZK是无法提供服务的。对没错，所以我们来详细分析下为什么ZK保证的是CP而eureka保证的是AP。

本文试图搞清楚以下问题：

1.eureka 如何保证AP。

2.ZK为什么不能保证AP。

3.什么是自我保护模式。

随着微服务的盛行，spring cloud微服务架构被很多人引荐和使用，所以再次回顾下eureka于zk的区别并且从理论层面去更深层次的理解eureka如何保证AP的。

首先再回顾下eureka高可用架构图

再大致理解下这张图的含义

服务提供者（applicatonService）向eurekaServer发起注册（register），心跳续约（renew），服务下线（cancel），客户端服务获取（get）。eureka server 之间也是相互注册。

zookeeper 架构图:

Zookeeper是以节点的形式去管理客户端，节点分为很多种临时节点、持久节点等。客户端对zk进行注册后，zk的watch机制会去监听节点数据发生的变化。zk的核心是原子广播（zab协议）来保证各个server之前的同步，为了不跑题这里不做过多赘述。

宕机情况：

在zookeeper集群环境下如果有zk发生了宕机zk会发起选举，对比令牌等一系列选举操作，此时的zk是不可用的，所以zk会保证强一致性。选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。尤其云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

eurekaServer之间也是相互进行注册（replicate），那么当有3台eurekaServer中的其中一台宕机客户端请求会自动切换到新的Eureka节点（与rocketMQ大致一个思想，这就是为什么rocketMQ不使用ZK从而使用nameServer来保证高可用）当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。

并且在网络分隔发生故障时每个eureka节点依然可以堆外提供服务，接收新的服务注册同时将它们提供给下游的服务发现请求。新发布的服务仍然可以被发现与访问。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。

自我保护模式：

eureka的自我保护模式简而言之就是15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，eureka不会再注册列表中移除长时间没有收到心跳的过期服务。但是这个自我保护模式慎用，需要具体情况具体分析，例如你在生产发布新版本应用，不希望在部署服务时还被用户访问到，此时就需要关闭自我保护模式，不然eureka不会对正在发布的节点进行剔除，用户依然可以访问到该节点从而导致无数据返回。

自我保护模式失效：

eurekaServer端默认30s频率来向服务提供者发送心跳，如果是2个eurekaServer则希望收到最少的心跳为实例数 x 2 x 85% = 最少心跳数。2台实例的话希望收到的心跳是 2 x 2 x 82% = 3.4，3个心跳。

但是如果更改了心跳时间15s发送一次，一分钟会有4个心跳，而运行一段时间后2个eurekaServer挂掉一个，对应公式则为 1 x 2 x 82% = 3.4，还是3个心跳，如果使用自我保护模式不建议降低心跳时间。

REGION 与 ZONE：

region与zone的概念来源于亚马逊的AWS，因为对于大公司而言为了保证服务机房的高可用性一般会进行多城市机房部署（异地灾备），例如我之前所参与某APP中一些业务的高可用方案。在北京A地区，北京B地区，武汉地区，都有该业务机房部署。北京B作为backUp机房。而对于每个地区的机房又划分成2个区域，分别为电信区域，联通区域。比如一个用户系统部署在4台机器，2台在电信机器，2台在联通的区域。其区别就算对应机器的网络运营商不一样。eureka的region 就相当于北京A，北京B，武汉地区。zone就相当于电信机器，联通机器。以前为了避免运营商网络故障导致访问不可用的情况我们把应用部署在电信和联通区分的机器，比如当联通运营商有问题，我们在nginx上把联通的流量切换到电信上，但是跨运营商访问延迟会比较高，电信运营商应用请求联通运营商应用肯定不如电信运营商应用访问电信运营商的要更快，所以这时候zone的概念就体现出来了，虽然在不同region但是zone会优先请求相同zone的实例。可以看下图。

总结：

1.eureka 如何保证AP。

eureka在设计时的分区容错保证了eureka各个节点都是平等的，只要不是所有节点都挂掉eureka就可以正常注册与使用，不会像zk出现选举而短暂不可用的情况。

2.ZK为什么不能保证AP。

当leader节点因为网络故障或者其他原因导致与其他节点失去联系，剩余节点则会发起选举，选举期间导致短暂不可用的情况，所以保证了强一致性而无法保证高可用性。

3.什么是eureka server自我保护模式。

eureka server自我保护模式指的是如服务长时间没有收到心跳导致未能及时续约会等待修复，而不是服务剔除，是一种针对网络异常波动的安全措施，能够保证服务的高可用。自我保护模式情况下如果该服务长时间未能收到心跳而导致服务过期，eureka server仍然能够接收新的服务注册和查询，但不会同步到其他节点上，当前节点依然可用，网络稳定后新注册的信息会被同步到其他节点中。而zk在网络环境不够稳定的情况下则会进行选举，导致短暂不可用情况。

后面源码对eureka进行分析讲解。

关注我的公众号 LearnMoreDoMore 可以及时看到更多技术分享文章（不会该死的卖课广告）。

为什么Eureka是AP，zookeeper是CP相关推荐

zookeeper是cp还是ap
1.zookeeper是cp还是ap zookeeper保证的是cp,eruka是ap. 准确来说zookeeper保证的是写是强一致性,读是顺序一致性. 2.那么什么是强一致性,什么是顺序一致性 2 ...
A2 AP AUTOSAR 与 CP AUTOSAR 的特性
Hello!大家好!欢迎来到<搞一下汽车电子>今天,我们给大家分享的是Adaptive Platform AUTOSAR 专题视频,增加的第二篇内容:A2 自动驾驶 & 域控中间件 ...
cp分解实现_对标Eureka的AP一致性，Nacos如何实现Raft算法
一.快速了解Raft算法 Raft 适用于一个管理日志一致性的协议,相比于 Paxos 协议 Raft 更易于理解和去实现它.为了提高理解性,Raft 将一致性算法分为了几个部分,包括领导选取(lea ...
CAP理论、AP架构、CP架构
目录 CAP理论 AP架构 CP结构 CAP理论 CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency).可用性(Availability).分区容错性(Partitio ...
Spring Cloud部分源码分析Eureka，Ribbon，Feign，Zuul
Eureka SpringCloud Eureka使用NetFlix Eureka来实现的,它包括了服务端组件和客户端组件,并且都是用java 编写的. Eureka服务端就是服务注册中心, Eure ...
关于Eureka的几个问题
本文来说下Eureka和ZooKeeper相关的几个问题文章目录微服务之服务发现概述举个例子 Eureka的架构图 Eureka Server Eureka Client Eureka Serv ...
初识微服务之Eureka
Eureka简介 Eureka就好比是一个控制中心,负责管理,记录服务提供者的信息.服务调用者无需自己寻找服务,而是把自己的需求告诉Eureka,然后Eureka会把符合你需求的服务告诉你.同时,服务 ...
Spring Cloud中五大神兽总结(Eureka/Ribbon/Feign/Hystrix/zuul)
一.常用的模块 1.Eureka Eureka是Netflix的一个子模块,也是核心模块之一.Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移.服务注册与发现对于 ...
Java开发专家阿里P6-P7面试题大全及答案汇总(持续更新)
一.CPU100%问题如何快速定位答案 1.执行top -c ,显示进程运行信息列表键入P (大写p),进程按照CPU使用率排序 2.找到最耗CPU的线程 top -Hp 10765 ,显 ...

为什么Eureka是AP，zookeeper是CP

为什么Eureka是AP，zookeeper是CP相关推荐

最新文章

热门文章