当先锋百科网

首页 1 2 3 4 5 6 7

CAP 理论

在总结两者的区别之前,我们先来看一个 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 原则

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

Eureka 在被设计的时候,就考虑到了这一点,因此在设计时优先保证可用性,这就是 AP 原则。Eureka 各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。

而 Eureka 的客户端在向某个 Eureka 注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台 Eureka 还在,就能保证注册服务可用(即保证A原则),只不过查到的信息可能不是最新的(不保证C原则)。

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

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


结论

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