Spring Cloud中的Eureka和Zookeeper的区别在哪?

首先为自己打个广告,我目前在某互联网公司做架构师,已经有5年经验,每天都会写架构师系列的文章,感兴趣的朋友可以关注我和我一起探讨,关注我,免费分享Java基础教程,以及进阶的高级Java架构师教程,全部免费送

做程序员的,对Spring和Cloud一定不会感到陌生

如何才能实打实的消化它们呢

接下来沃师傅将会告诉你,如何夯实Spring Cloud

CAP理论

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

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原则),只不过查到的信息可能不是最新的(不保证B原则)。

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

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

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

以下是分享的部分架构师的学习资料和部分零基础学习Java的视频资料,附带练习题和课堂笔记,需要的朋友可以私信我免费获取

你可能感兴趣的:(Spring Cloud中的Eureka和Zookeeper的区别在哪?)