CAP定理与BASE理论

CAP定理

CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、 Partition tolerance（分区容错性），三者不可得兼。

1. 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。
2. 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）。
3. 分区容错性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作（除非整个网络全部故障）。

网络分区

分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区。

论文原义：当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。

也就是说在网络分区后，分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。于是一个分布式系统通常分为以下两类：

• CP - 满足一致性，分区容错性的系统，通常性能不是特别高。
• AP - 满足可用性，分区容错性的系统，通常可能对一致性要求低一些。

为什么无法实现CA

若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。

示例—注册中心

1. ZooKeeper 保证的是 CP。 任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是， ZooKeeper 不保证每次请求的可用性比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。
2. Eureka 保证的则是 AP。 Eureka 在设计的时候就是优先保证可用性 A 。在 Eureka 中不存在什么 Leader 节点，每个节点都是对等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。 Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的，也就是保证不了一致性 C。
3. Nacos 不仅支持 CP 也支持 AP。 通过 DelegateConsistencyServiceImpl 类进行策略选择。

BASE理论

BASE 理论，它是在 CAP 理论的基础之上的延伸。包括 基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）。

• Basically Availble ：基本可用，是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。比如：请求时间边长，部分非核心功能不可用等。
• Soft-state ： 软状态 / 柔性事务，是指允许系统中的数据存在中间状态。并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• Eventual Consistency ： 最终一致性， 是指系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。不需要实时保证系统数据的强一致性。

我的更多文章尽在：我的个人博客