@程序员，京东面试官让你谈谈..中心的问题！

[本文来自：www.ii77.com]

[本文来自：www.ii77.com]

作者 | 倪升武

责编 | 郭   芮

大家都说今年是互联网寒冬，但是前段时间有个读者很高兴的跟我聊天说他去京东了。我问他都问了什么问题？他说问了很多微服务相关的，其中有一个问题就是：同样是..中心，你觉得 Zookeeper 和 Eureka 哪个更好？

刚好最近也在看微服务相关的东西，索性就针对这个问题，简单总结一下 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 原则