Zookeeper 和 Eureka 之间的区别

CAP 理论

在总结两者的区别之前，我们先来看一个 CAP 理论。

什么叫 CAP 理论呢？CAP 理论是由 Eric Brewer 教授提出，是分布式系统中的一个重要的概念。CAP 具体如下：

C（Consistency）：数据一致性。大家都知道，分布式系统中，数据会有副本。由于网络或者机器故障等因素，可能有些副本数据写入正确，有些却写入错误或者失败，这样就导致了数据的不一致了。而满足数据一致性规则，就是保证所有数据都要同步。

A（Availability）：可用性。我们需要获取什么数据时，都能够正常地获取到想要的数据（当然，允许可接受范围内的网络延迟），也就是说，要保证任何时候请求数据都能够正常响应。

P（Partition Tolerance）：分区容错性。当网络通信发生故障时，集群仍然可用，不会因为某个节点挂了或者存在问题，而影响整个系统的正常运作。

对于分布式系统来说，出现网络分区是不可避免的，因此分区容错性是必须要具备的。也就是说，CAP三者，P是必须的，是个客观存在的事实，不可避免，也无法绕过。

Zookeeper 的 CP 原则

对于 Zookeeper 来说，它是 CP 的。也就是说，Zookeeper 是保证数据的一致性的，但是这里还需要注意一点是，Zookeeper 它不是强一致的，什么意思呢？打个比方，现在客户端 A 提交一个写操作，Zookeeper 在过半数节点操作成功之后就可以返回，但此时，客户端 B 的读操作请求的是 A 写操作尚未同步到的节点，那么读取的就不是 A 最新提交的数据了。

那如何保证强一致性呢？我们可以在读取数据的时候先执行一下 sync 操作，即与 leader 节点先同步一下数据，再去取，这样才能保证数据的强一致性。

但是 Zookeeper 也有个缺陷，刚刚提到了 leader 节点，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 Zookeeper 集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署的环境下，因网络问题使得 Zookeeper 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。比如双十一当天，那就是灾难性的。

Eureka 的 AP 原则

大规模网络部署时，失败是在所难免的，因此我们无法回避这个问题。当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。

Eureka 在被设计的时候，就考虑到了这一点，因此在设计时优先保证可用性，这就是 AP 原则。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 Eureka 的客户端在向某个 Eureka 注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台 Eureka 还在，就能保证注册服务可用（即保证A原则），只不过查到的信息可能不是最新的（不保证C原则）。

正因为应用实例的注册信息在集群的所有节点间并不是强一致的，所以需要客户端能够支持负载均衡以及失败重试。在 Netflix 的生态中，ribbon 可以提供这个功能。

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

作为服务注册中心，最重要的是要保证可用性，可以接受短时间内数据不一致的情况。个人觉得 Eureka 作为单纯的服务注册中心来说要比 Zookeeper 更加“专业”一点。

不过 Eureka2.x 分支不再维护，但是 Eureka1.x 官方还在维护，目前最新 RELEASE 版本是 1.9.9，所以并不是像网上说的 Eureka 凉了啥的。

Eureka 是随着 Spring Cloud 被人们熟知，但是 Spring Cloud 支持使用 Eureka、Zookeeper、Consul 实现服务发现的能力。从 Eureka 切换成 Zookeeper 只需要改个依赖，改几行配置就可以了。更多的是要多了解它们的原理和区别。