zookeeper 和 eureka 有什么区别，哪个更适合作为注册中心？

zookeeper 和 eureka 有什么区别，哪个更适合作为注册中心？

最近接触到一个问题，Zookeeper 和 Eureka 有什么区别，为什么注册中心一定要用 Eureka ，今天又看到一篇文章说京东面试好像有问到这个问题，所以来记录一下自己的理解：

CAP 原则

谈到这个问题，最主要的是明白什么事 CAP 原则：

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

A（Availability）：可用性。即 只要收到用户的请求，服务器就必须给出回应。我们需要获取数据时，都能够正常的获取到想要的数据（允许可接受范围内的网络延迟），也就是说，要保证任何时候请求数据都能够正常响应。

P（Partition Tolerance）：分区容错性。当网络通信发生故障时，集群仍然可用，不会因为某个节点挂了或者存在问题，而影响整个系统的正常运作。大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition），区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信，系统设计的时候，必须考虑到这种情况。

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到，所以需要取舍是做到 A 还是 C 。

Zookeeper 保证 CP

Zookeeper 是保证数据的一致性的，但是并不是强一致的。

比如客户端 A 提交一个写操作，Zookeeper 在过半数节点操作成功之后就可以返回，但此时，客户端 B 的读操作请求的是 A 写操作尚未同步到的节点，那么读取的就不是 A 最新提交的数据了。
我们可以在读取数据的时候先执行一下 sync 操作，即与 leader 节点先同步一下数据，再去取，这样才能保证数据的强一致性。

关于可用性，Zookeeper 的 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举，选举 leader 的时间太长，需要 30 ~ 120 s, 且选举期间整个 Zookeeper 集群都是不可用的，这就导致在选举期间注册服务瘫痪。同时，在云部署的环境下，因网络问题使得 Zookeeper 集群失去 master 节点是较大概率会发生的事，整个服务停下这么长的时间是非常严重的，比如双十一。

Eureka 保证 AP

就是针对 Zookeeper 出现的这一问题，Eureka选择了优先保证可用性。

大规模网络部署时，失败是在所难免的。当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。而集群部署的 Eureka 即使挂掉一定的数量，也可以保证有信息可以返回，依然可以提供注册和查询服务，只不过查到的信息可能不是最新的。

ribbon 提供了负载均衡和重试机制。

作为服务注册中心，最重要的是要保证可用性，可以接受短时间内数据不一致的情况，所以 Eureka 会更适合。