Java - CAP定理

CAP 定理指的是在一个分布式系统中，一致性 Consistency 、可用性 Availability 、分区容

错性 Partition tolerance ，三者不可兼得。

 一致性（ C ）：分布式系统中多个主机之间是否能够保持数据一致的特性。即，当系统数

据发生更新操作后，各个主机中的数据仍然处于一致的状态。

 可用性（ A ）：系统提供的服务必须一直处于可用的状态，即对于用户的每一个请求，系

统总是可以在有限的时间内对用户做出响应。

 分区容错性（ P ）：分布式系统在遇到任何网络分区故障时，仍能够保证对外提供满足一

致性和可用性的服务。

CAP 定理的内容是：对于分布式系统，网络环境相对是不可控的，出现网络分区是不可

避免的，因此系统必须具备分区容错性。但系统不能同时保证一致性与可用性。即要么 CP ，

要么 AP 。

BASE 理论

BASE 是 Basically Available （基本可用）、 Soft state （软状态）和 Eventually consistent （最

终一致性）三个短语的简写， BASE 是对 CAP 中一致性和可用性权衡的结果，其来源于对大

规模互联网系统分布式实践的结论，是基于 CAP 定理逐步演化而来的。

BASE 理论的核心思想是：即使无法做到强一致性，但每个系统都可以根据自身的业务

特点，采用适当的方式来使系统达到最终一致性。

（ 1 ） 基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

（ 2 ） 软状态

软状态，是指允许系统数据存在的中间状态，并认为该中间状态的存在不会影响系统的

整体可用性，即允许系统主机间进行数据同步的过程存在一定延时。软状态，其实就是一种

灰度状态，过渡状态。

（ 3 ） 最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到

一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需

要保证系统数据的实时一致性。

Zookeeper 与 CP

Zookeeper 遵循的是 CP 模式，即保证了一致性，但牺牲了可用性。

当 Leader 节点中的数据发生了变化后，在 Follower 还没有同步完成之前，整个 Zookeeper

集群是不对外提供服务的。如果此时有客户端来访问数据，则客户端会因访问超时而发生重

试。不过，由于 Leader 的选举非常快，所以这种重试对于用户来说几乎是感知不到的。所

以说， Zookeeper 保证了一致性，但牺牲了可用性。

Consul 与 CP

Consul 遵循的是 CP 模式，即保证了一致性，但牺牲了可用性。

Redis 与 CAP

Redis 遵循的是 AP 模式，即保证了可用性，但牺牲了一致性。

Eureka 与 CAP

Eureka 遵循的是 AP 模式，即保证了可用性，但牺牲了一致性。

Nacos 与 CAP

Nacos 在做注册中心时，默认是 AP 的。但其也支持 CP 模式，但需要用户提交请求进行

转换。