ZooKeeper与Eureka比较

1.CAP原理：

• C (Consistency) 数据一致性

  ​ 要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性, 这里指的是强一致性

• A (Availability) 服务可用性

• P (Partition Tolrerance) 分区容错性

  某节点或网络分区故障时，仍能对外提供一致性和可用性的服务

为什么CAP不能同时满足呢？

​ （出现网络中断的情况）假设同时访问两个节点上的同个服务，要保证数据一致性，需要两个节点之间实时数据同步，但要保证数据不一致，就要等待网络故障恢复后同步数据后才访问，这样又违背了服务可用性，如果不同步数据直接访问，又会违背数据一致性。

满足两者的情况：

• 舍弃P

舍弃P, 也就是舍弃使用分布式系统，没就没有必要讨论CAP 理论了。

• 舍弃A

例如Redis、Zookeeper , 数据一致性是最基本的要求

• 舍弃C

例如淘宝购物，购票软件，点进去后才会发现余量不足，牺牲了一致性，因为舍弃的是强一致性，保证了最终一致性。

2. Zookeeper 与 Eureka 区别

Zookeeper （CP)、 Eureka (AP)

• Zookeeeper

  ​ 极端情况下（因网络故障与其他节点失去联系，需要重新进行leader选举，选举期间导致整个zk集群不可用），会丢弃一些请求，消费者程序需要多次请求才能获得结果，因为它的职责就是保证（配置数据、状态数据）一致，

• Eureka

  ​ 只要有一台Eureka在，就能保证注册服务可用，两外还有一种保护机制，如果15分钟内超过85%节点没有正常心跳，会出现：

  1. 不再从注册列表中移除因长时间没收到心跳而应该过期的服务。
  2. 仍能接收新服务注册和查询请求，但不会被同步到其他节点上。