Eureka和zookeeper区别

ACID与CAP原则

数据库分为关系型数据库和非关系型数据库。 主流的关系型数据库有Oracle、DB2、MySQL、Microsoft SQLServer、Microsoft Access等多个品种，每种数据库的语法、功能和特性也各具特色。
非关系数据库（Nosql）有MongoDB，redis。

关系型数据库强调ACID规则：（原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）），可以满足对事务性要求较高或者需要进行复杂数据查询的数据操作，而且可以充分满足数据库操作的高性能和操作稳定性的要求。并且关系型数据库十分强调数据的强一致性，对于事务的操作有很好的支持。关系型数据库可以控制事务原子性细粒度，并且一旦操作有误或者有需要，可以马上回滚事务。

非关系型数据库强调CAP原则。 CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
• 可用性（A）：保证每个请求不管成功或者失败都有响应。
• 分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。
  

CAP理论的核心

一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求
根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类:
CA:单点集群，满足一致性，可用性的系统，通常可扩展性较差
CP:满足一致性，分区容错性的系统,通常性能不是特别高
AP:满足可用性，分区容错性的系统，通常可能对一致性要求低一些

由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。
Zookeeper保证的是CP;
Eureka保证的是AP;

Zookeeper与Eureka比较

Zookeeper保证的是CP：
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接宕机不可用。也就是说，服务注册功能对可用性的要求要小于一致性。
但是Zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。类似于redis哨兵机制，在我以前的博客里详细介绍过redis哨兵机制原理，可以适当参考；
https://blog.csdn.net/JiaMing11_27/article
问题在于，选举leader的时间太长，30~120s，且选举期间整个Zookeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP：

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

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

总结

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