CAP定理 & BASE理论

CAP定理

一、CAP定理

简介

CAP定理，又被称作 布鲁尔定理。指的是在一个分布式系统中，Consistency（数据一致性）、 Availability（服务可用性）、Partition tolerance（分区容错性），三者不可兼得。在分布式架构中，P永远要求被保证，所以当前的分布式架构只有AP和CP两种。CAP由Eric Brewer在2000年分布式计算原理研讨会上（PODC）提出。该猜想在提出两年后被证明成立，成为我们熟知的分布式领域的定理。

	分布式系统CAP定理
数据一致性(Consistency)	所有节点访问同一份最新的数据副本。优点： 数据一致，没有数据错误可能。缺点： 相对效率降低。
服务可用性(Availablity)	非故障的节点在合理的时间内返回合理的响应，这里需要注意的是"一定时间内"和"返回结果"。一定时间内指的是，在可以容忍的范围内响应，响应的结果可以是成功或者是失败。
分区容错性(Partition-torlerance)	在网络分区的情况下，被分隔的节点仍能正常对外提供服务

	定律：任何分布式系统只可同时满足二点，没法三者兼顾。
CA，放弃P	如果想避免分区容错性问题的发生，一种做法是将所有的数据(与事务相关的)/服务都放在一台机器上。虽然无法100%保证系统不会出错，但不会碰到由分区带来的负面效果。通长在可扩展性上不太强大。
CP，放弃A	相对于放弃"分区容错性"来说，其反面就是放弃可用性。一旦遇到分区容错故障，那么受到影响的服务需要等待一定时间，因此在等待时间内系统无法对外提供服务。通常性能不是特别高。
AP，放弃C	这里所说的放弃一致性，并不是完全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。以网络购物为例，对只剩下一件库存的商品，如果同时接受了两个订单，那么较晚的订单将被告知商品告罄。通常可能对一致性要求低一些。

网络分区：

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

不是所谓的“3 选 2”

CAP 之父也在 2012 年重写了之前的论文中提到到，就是：当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。简而言之就是：CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C

因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。

为啥无同时保证 CA 呢？

举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。

为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。

如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。

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

二、服务注册中心对比

ZooKeeper 保证的是 CP。 任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是不保证每次请求的可用性。

Eureka 保证的则是 AP。 Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。

组件名	编写语言	CAP	服务健康检查	对外暴露接口	SpringCloud集成
Eureka	Java	AP	可配支持	HTTP	已集成
Consul	Go	CP	支持	HTTP/DNS	已集成
Zookeaper	Java	CP	支持	客户端	已集成

三、总结

1、在进行分布式系统设计和开发时，我们不应该仅仅局限在 CAP 问题上，还要关注系统的扩展性、可用性等等

2、在系统发生“分区”的情况下，CAP 理论只能满足 CP 或者 AP。这里的前提是系统发生了“分区”。因为如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。

BASE理论

起源于 2008 年， 由eBay的架构师Dan Pritchett在ACM上发表。

1、简介：BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

• 基本可用：基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。
• 软状态：软状态指允许系统中的数据存在中间状态，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• 最终一致性：是指系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个数据一致的状态。

分布式一致性的 3 种级别：

1. 强一致性 ：系统写入了什么，读出来的就是什么。
2. 弱一致性 ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
3. 最终一致性 ：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。

业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。

2、核心思想是即使系统无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

3、描述

• 以牺牲数据的一致性来满足系统的高可用性；以牺牲部分可用性来满足数据的一致性。

• BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。

总结

ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。