【夯实Spring Cloud】Spring Cloud中的Eureka和Zookeeper的区别在哪？

深碍√TFBOYSˉ_ 2022-03-31 01:59 116阅读 0赞

本文属于【夯实Spring Cloud】系列文章，该系列旨在用通俗易懂的语言，带大家了解和学习Spring Cloud技术，希望能给读者带来一些干货。系列目录如下：

> [【夯实Spring Cloud】Dubbo沉睡5年，Spring Cloud开始崛起！][Spring Cloud_Dubbo_5_Spring Cloud]  
> [【夯实Spring Cloud】Spring Cloud中基于maven的分布式项目框架的搭建][Spring Cloud_Spring Cloud_maven]  
> [【夯实Spring Cloud】Spring Cloud中的Eureka服务注册与发现详解][Spring Cloud_Spring Cloud_Eureka]  
> [【夯实Spring Cloud】Spring Cloud中如何完善Eureka中的服务信息][Spring Cloud_Spring Cloud_Eureka 1]  
> [【夯实Spring Cloud】Spring Cloud中使用Eureka集群搭建高可用服务注册中心][Spring Cloud_Spring Cloud_Eureka 2]  
> [【夯实Spring Cloud】Spring Cloud中的Eureka和Zookeeper的区别在哪？][Spring Cloud_Spring Cloud_Eureka_Zookeeper]  
> [【夯实Spring Cloud】Spring Cloud中使用Ribbon实现负载均衡详解（上）][Spring Cloud_Spring Cloud_Ribbon]  
> [【夯实Spring Cloud】Spring Cloud中使用Ribbon实现负载均衡详解（下）][Spring Cloud_Spring Cloud_Ribbon 1]  
> [【夯实Spring Cloud】Spring Cloud中自定义Ribbon负载均衡策略][Spring Cloud_Spring Cloud_Ribbon 2]  
> [【夯实Spring Cloud】Spring Cloud中使用Feign实现负载均衡详][Spring Cloud_Spring Cloud_Feign]  
> [【夯实Srping Cloud】Spring Cloud中使用Hystrix实现断路器原理详解（上）][Srping Cloud_Spring Cloud_Hystrix]  
> [【夯实Srping Cloud】Spring Cloud中使用Hystrix实现断路器原理详解（下）][Srping Cloud_Spring Cloud_Hystrix 1]  
> [【夯实Spring Cloud】Spring Cloud中使用Zuul实现路由网关详解][Spring Cloud_Spring Cloud_Zuul]  
> [【夯实Spring Cloud】Spring Cloud分布式配置中心详解][Spring Cloud_Spring Cloud]  
> 【夯实Spring Cloud】未完待续

--------------------

该系列上面几篇文章主要对 Spring Cloud 中 Eureka 的服务注册与发现做了详细的介绍，针对于注册中心，zookeeper 用的也比较多，所以这篇文章主要来总结一下 Eureka 和 zookeeper 之间的区别。

## 1. CAP 理论 ##

在总结两者的区别之前，我们先来看一个 CAP 理论。什么叫 CAP 理论呢？CAP 理论是由 Eric Brewer 教授提出，是分布式系统中的一个重要的概念。具体如下：

> C（Consistency）：数据一致性。大家都知道，分布式系统中，数据会有副本。由于网络或者机器故障等因素，可能有些副本数据写入正确，有些却写入错误或者失败，这样就导致了数据的不一致了。而满足数据一致性规则，就是保证所有数据都要同步。  
> A（Availability）：可用性。我们需要获取什么数据时，都能够正常的获取到想要的数据（当然，允许可接受范围内的网络延迟），也就是说，要保证任何时候请求数据都能够正常响应。  
> P（Partition Tolerance）：分区容错性。当网络通信发生故障时，集群仍然可用，不会因为某个节点挂了或者存在问题，而影响整个系统的正常运作。

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

## 2. zookeeper 的 CP 原则 ##

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

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

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

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

## 3. eureka 的 AP 原则 ##

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

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

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

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

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

--------------------

源码下载地址：https://gitee.com/eson15/springcloud\_study

更多优质文章请关注我的微信公众号【**武哥聊编程**】，回复“**资源**”、“**架构**”、“**简历**”等关键词，可以领取海量优质的视频学习资源。大家共同进步。

![程序员私房菜][2018120514435330.png]

[Spring Cloud_Dubbo_5_Spring Cloud]: https://blog.csdn.net/eson_15/article/details/83651732
[Spring Cloud_Spring Cloud_maven]: https://blog.csdn.net/eson_15/article/details/83585344
[Spring Cloud_Spring Cloud_Eureka]: https://blog.csdn.net/eson_15/article/details/85002026
[Spring Cloud_Spring Cloud_Eureka 1]: https://blog.csdn.net/eson_15/article/details/85226439
[Spring Cloud_Spring Cloud_Eureka 2]: https://blog.csdn.net/eson_15/article/details/85252697
[Spring Cloud_Spring Cloud_Eureka_Zookeeper]: https://blog.csdn.net/eson_15/article/details/85561179
[Spring Cloud_Spring Cloud_Ribbon]: https://blog.csdn.net/eson_15/article/details/86182477
[Spring Cloud_Spring Cloud_Ribbon 1]: https://blog.csdn.net/eson_15/article/details/86225272
[Spring Cloud_Spring Cloud_Ribbon 2]: https://blog.csdn.net/eson_15/article/details/86578207
[Spring Cloud_Spring Cloud_Feign]: https://blog.csdn.net/eson_15/article/details/86590402
[Srping Cloud_Spring Cloud_Hystrix]: https://blog.csdn.net/eson_15/article/details/86628622
[Srping Cloud_Spring Cloud_Hystrix 1]: https://blog.csdn.net/eson_15/article/details/86673843
[Spring Cloud_Spring Cloud_Zuul]: https://blog.csdn.net/eson_15/article/details/86689681
[Spring Cloud_Spring Cloud]: https://blog.csdn.net/eson_15/article/details/86715157
[2018120514435330.png]: /images/20220331/47e254a2d4b04df5a6ef3f273e4d491a.png