查看“Zookeeper 和 Eureka 的区别”的源代码

https://www.bilibili.com/video/BV1eU4y187zE/?p=8

在 Spring Cloud Netflix 中可以使用 Eureka 作为注册中心，但是也可以通过配置的方式使用 Zookeeper 作为配置中心，既然都支持，就需要知道两者的区别。

=== CAP 理论（分布式一致性定理） ===
著名的 CAP 理论指出，一个分布式系统不可能同时满足 C（Consistency，一致性）、A（Availability，可用性），P（Partition-tolerance，分区容错性）。

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

在此 Zookeeper 保证的是 CP，而 Eureka 则是 AP



==== C（Consistency，一致性） ====
在分布式系统中，是否'''<big>立即</big>'''达到数据同步的效果（平时多说的强一致性）。

在分布式系统一定最终会一致的。如果请求时，整个分布式系统同步后才返回结果，叫做强一致性（满足一致性）。

如果先返回结果，在一定时间后才实现一致性就叫做弱一致性。




==== A（Availability，可用性） ====
在分布式系统中，其中一些节点出现问题，整个整体是否还可用。




==== P（Partition-tolerance，分区容错性） ====
在分布式系统中，是否可以在有限的时间内达到数据一致性的效果，如果因为网络等问题最终没有达到一致性，这时称为出现分区错误。





=== Zookeeper 保证 CP ===
在 Zookeeper 集群中，Zookeeper 的数据保证的是一致性。

当 Leader 出现问题时，整个 Zookeeper 不可用，需要花费 30~120 s 来进行重新选择 leader，当 leader 选举成功以后才能进行访问整个 Zookeeper 集群。

通过这点也可以看出 Zookeeper 是强一致性的，集群所有节点必须能通信，才能用集群。

虽然这样集群数据安全了，但是可用性大大降低了。

而作为注册中心来说可用性是很重要的。



=== Eureka 保证 AP ===
Eureka 发现了 Zookeeper 的问题，所以它舍弃了 Zookeeper 中的强一致性，而保证了可用性。

在 Eureka 集群中所有的节点都是保存完整的信息的，当 Eureka Client 向 Eureka 中注册信息时，如果发现节点不可用，会自动切换到另一台 Eureka Server，也就是说整个集群中即使只有一个 Eureka Server 可用，那么整个集群也是可用的。

同时 Eureka 的自我保护机制也是实现可用性非常重要的体现。



=== Zookeeper 和 Eureka 对比（最完整的对比） ===
{| class="wikitable"
!对比项
!Zookeeper
!Eureka
!
|-
|CAP
|CP
|AP
|
|-
|Dubbo 集成
|已支持
| -
|
|-
|Spring Cloud 集成
|已支持
|已支持
|
|-
|kv（键值对）服务
|支持
| -
|Zookeeper 支持数据存储
Eureka 不支持
|-
|使用接口（多语言能力）
Java、Python、C……
|提供客户端
（zkClient、Curator）
|HTTP 协议
（跨语言）
|ZK 的跨语言支持比较弱
|-
|watch 支持
|支持
|支持
|什么是 watch 支持？
就是客户端监听服务端的变化情况。

Zookeeper 通过订阅监听来实现；

Eureka 通过轮询的方式来实现。
|-
|集群监控
| -
|metrics
|metrics，运维者可以收集并报警这些度量信息达到监控目的
|}