一.概述

在理论计算机科学中，CAP原理指出对于一个分布式系统来说，当设计读写操作时，只能同时满足一下三点中两个：

一致性（Consistence）：所有节点访问同一份最新的数据副本
可用性（Avaliability）：非故障的节点在合理时间内返回合理的响应（不是错误或者超时的响应）
分区容错性（Partition tolerance）：分布式系统出现网络分区（分布式系统中，多个节点之前的网络本来是连通的，但是由于某些故障，比如部分节点网络出了问题。某些节点之间不连通，整个网络就分为几个区域，这就叫做网络分区。）的时候，仍然能够对外提供服务

二.三选二

当发生网络分区的时候，如果我们要继续服务，那么一致性和可用性只能2选1。也就是说当网络分区之后P是前提，决定P之后才有C和A的选择，也就是说分区容错性我们是必须要实现的。

为什么无法保证CA呢？若系统出现了分区，系统某个节点在进行写操作。为了保证C，必须要禁止其他节点的读写操作，这就是和A发生冲突了。如果为了保证A，其他节点的读写操作正常的时候，那么就和C发生了冲突。

选择的关键在于当前的业务场景，没有定论，比如对于需要保证强一致的场景的银行会保证CP。

Eureka保证的是AP。Eureka在设计的时候就是优先保证A（可用性）。在Eureka中不存在什么Leader节点，每个节点都是一样的，平等的。因此Eureka不会像Zookeeper那样出现选举过程中或者半数以上的机器不可用的时候也就是服务不可用的时候。Eureka保证及时大部分节点挂掉也不会影响正常提供服务，只要有一个节点可用就行。只不过这个节点上的数据可能并不是最新的。
Zookeeper保证的是CP。任何适合对Zookeeper的读请求都能得到一致性的结果，但是，Zookeeper不保证请求的可用性比如在Leader选举过程中或者半数机器不可用的时候服务就是不可用的。

Zookeeper和Eureka的数据一致性问题？Eureka创建的初心就是为了一个注册中心，但是zk更多是作为分布式协调服务的存在，只不过因为它的特性被Dubbo赋予了注册中心，它的职责更多的是保证数据在管辖的所有服务之间保持一致，所以可以这样理解了了ZK被设置了CP而不是AP。

更深层的原因，ZK是按照CP原则构建的，也就是它必须保持一个每一个节点的数据都保持一致，如果节点断开或者集群下出现网络分割，那么ZK会将它们从自己管理的范围剔除出去，外界不能访问这些节点，即使这些节点是健康的可以提供正常的服务，所以会导致这些节点的请求都会被丢失。

Eureka每个节点都是相对独立，不需要考虑数据一致性的问题。数据不一致性带来的问题：无非就是某一个节点被注册的服务多，某节点注册的服务少，在某一瞬间可能会导致某些IP节点被调用数少，某些IP节点被调用数多的问题。也可能存在一些本应该被删除而没被删除的脏数据。

对于服务注册来说，针对同一个服务，即使注册中心的不同节点保存的服务注册信息不相同，也不会造成灾难性的后果。对于服务消费者来说，能消费才是最重要的，就算拿到的数据不是最新的数据，消费者本身也可以进行失败重试，总比为了追求数据一致性而获取不到实例信息整个服务不可用要好。

所以，对于服务注册来说，可用性比数据一致性更加重要，选择AP。

发布者：全栈程序员-用户IM，转载请注明出处：https://javaforall.cn/144523.html原文链接：https://javaforall.cn

【正版授权，激活自己账号】： Jetbrains全家桶Ide使用，1年售后保障，每天仅需1毛

【官方授权正版激活】： 官方授权正版激活支持Jetbrains家族下所有IDE 使用个人JB账号...