上一篇梳理一下 CAP定理：https://blog.csdn.net/Soinice/article/details/96782876

著名的CAP理论指出，一个分布式体系不大概同时满足C（同等性）、A（可用性）、和P（分区容错性）。由于分区容错性P在分布式体系中必须要包管的，因此我们只能在A和C之间举行衡量。

因此： 
Zookeeper包管的是CP， 
Eureka则是AP。

但是对CAP/AP/CP很不明确，于是查阅资料，做一个简单的相识。

Zoopkeeper包管CP

当向注册中央查询服务列表时，我们可以容忍注册中央返回的是几分钟从前的注册信息，但是不能继承服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于同等性。但是zk会出现如许的一种情况，当master节点因网路故障与其他节点失去接洽时，剩余的节点会重新举行leader推选。标题在于，推选leader的时间太长，30~120s，且推选期间整个zk集群是都是不可用的，这就导致在推选期间注册服务瘫痪，在云摆设的情况下，因网络标题使得zk集群失去master节点是较大概率会发生的事，固然服务可以大概终极规复，但是漫长的推选时间导致的注册恒久不可用是不能容忍的。

Eureka包管AP

Eureka看明确了这一点，因此在筹划时就优先包管可用性。Eureka各个节点都是同等的，几个节点挂掉不影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时假如发现毗连失败，则会主动切换至其他的节点，只要有一台Eureka还在，就能包管注册服务可用（包管可用性），只不外查到的信息大概不是最新的（不包管同等性）。除此之外，Eureka尚有一种自我掩护机制，假如在15分钟内凌驾85%的节点都没有正常的心跳，那么Eureka就以为客户端与注册中央出现了网络故障，此时会出现以下几种情况： 
1.Eureka不再从注册列表中移除由于长时间没有收到心跳而应该逾期的服务 
2.Eureka仍旧可以大概继承新服务的注册和查询哀求，但是不会被同步到别的节点上（即包管当前节点依然可用） 
3.当前网络稳固时，当前实例新的注册信息会被同步到别的节点中 
因此，Eureka可以很好的应对因网络故障导致节点失去接洽的情况，而不会像zookeeper那样使整个注册服务瘫痪。

Eureka服务管理机制与Dubbo服务管理机制的比力

Eureka支持康健查抄，自我掩护等。

Zookeeper为CP筹划，Eureka为AP筹划。

作为服务发现产物，可用性优先级较高，同等性的特点并不紧张，宁愿返回错误的数据，也比不反回效果要好得多。

服务列表变更Zookeeper服务端会有关照，Eureka则通过长轮询来实现，Eureka未来会实现watch机制。

取与舍

CAP理论提出就是针对分布式数据库情况的，以是，P这个属性是必须具备的。
P就是在分布式情况中，由于网络的标题大概导致某个节点和别的节点失去接洽，这时间就形成了P(partition)，也就是由于网络标题，将体系的成员隔离成了2个地域，相互无法知道对方的状态，这在分布式情况下好坏经常见的。
由于P是必须的，那么我们必要选择的就是A和C。
各人知道，在分布式情况下，为了包管体系可用性，通常都接纳了复制的方式，制止一个节点粉碎，导致体系不可用。那么就出现了每个节点上的数据出现了很多个副本的情况，而数据从一个节点复制到别的的节点时必要时间和要求网络流畅的，以是，当P发生时，也就是无法向某个节点复制数据时，这时间你有两个选择：
选择可用性 A(Availability)，此时，谁人失去接洽的节点依然可以向体系提供服务，不外它的数据就不能包管是同步的了（失去了C属性）。
选择同等性C(Consistency)，为了包管数据库的同等性，我们必须等候失去接洽的节点规复过来，在这个过程中，谁人节点是不答应对外提供服务的，这时间体系处于不可用状态(失去了A属性)。

最常见的例子是读写分离，某个节点负责写入数据，然后将数据同步到别的节点，别的节点提供读取的服务，当两个节点出现通讯标题时，你就面临着选择A（继承提供服务，但是数据不包管正确），C（用户处于等候状态，不绝比及数据同步完成）。

文章参考：

https://blog.csdn.net/zhumengguang/article/details/80156792 
https://blog.csdn.net/u013058742/article/details/83541905