CAP定理

CAP定义

---

• 一致性（Consistency）：等同于所有节点访问同一份最新的数据副本，在同一时刻是否同样的值。（范围是分布式系统中的所有数据备份，但是一般描述的对象针对于主从存储设备）

• 可用性（Availability）：每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据（该特性一般作用于集群环境）

• 分区容错性（Partition tolerance）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP详细解释 

分区容错性（Partition tolerance）  

先来看分区容错性，阮一峰老师是这样描述的： 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。 分区容错的意思是，区间通信可能失败。 比如，一台服务器A，一台服务器B，这就是两个区，它们之间可能无法通信。 一般来说，在分布式系统中分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。 只有单体应用不需要保证分区容错性。

一致性（Consistency） 

该特性一般针对于主从存储环境 举例 有数据库DB1，数据库中的数据版本为V1，客户端对DB1更新了一条数据变成了V2，然后接着读取了数据库中的数据，这时读到的数据版本也是V2，这就是一致性。

假设刚刚的场景中多了一个从数据库DB2，这时会造成DB2中的数据还停留在V1，这就导致了读数据时不一致，这时可以让DB1向DB2发送同步数据的请求，让DB2中的数据也变成V2，即可保证一致性。

但是这个发送同步数据的请求的过程必定有延迟（或多或少），导致DB2处理同步请求之前数据并不是一致的，这个时候就只能对DB2的资源进行锁定（此时不允许处理读请求），等待DB2处理同步请求后再允许DB2处理读请求，这也造成了短暂的数据不可用问题。

可用性（Availability）

还是前面的场景，如果不对DB2的资源进行锁定即可保证可用性，但是这样无法保证一致性。（分布式环境下C和A只能很好的保证其中一个，它们是互相矛盾的，要么CP要么AP）

BASE 理论

BASE 理论指的是基本可用 Basically Available，软状态 Soft State，最终一致性 Eventual Consistency，核心思想是即便无法做到强一致性，但应该采用适合的方式保证最终一致性。

BASE，Basically Available Soft State Eventual Consistency 的简写： BA：Basically Available 基本可用，分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。 S：Soft State 软状态，允许系统存在中间状态，而该中间状态不会影响系统整体可用性。 E：Consistency 最终一致性，系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。 BASE 理论本质上是对 CAP 理论的延伸，是对 CAP 中 AP 方案的一个补充。

满足BASE理论的事务，我们称之为“柔性事务”。

基本可用

分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如电商网站交易付款出现问题了，商品依然可以正常浏览。

软状态

由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单的"支付中"、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。

最终一致

最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，最终会变 为“支付成功”或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。