CAP理论

起源

CAP定理，又被称作布鲁尔定理。这个定理起源于加州大学柏克莱分校的计算机科学家埃里克·布鲁尔在2000年的分布式计算原理研讨会上提出的一个猜想¹。在2002年，麻省理工学院的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为一个定理。

吉尔伯特和林奇证明的CAP定理比布鲁尔设想的某种程度上更加狭义。定理讨论了在两个互相矛盾的请求到达彼此连接不通的两个不同的分布式节点的时候的处理方案。

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

CAP理论

CAP理论中的CA和数据库事务中ACID的CA并完全是同一回事儿。两者之中的A都是C都是一致性(Consistency)。CAP中的A指的是可用性（Availability），而ACID中的A指的是原子性（Atomicity)，切勿混为一谈。

可以理解为如果一个写操作成功了，那么后续的请求都必须读到这个最新的值。如果这个操作失败了，那么后续所有的读操作都不能读到这个新的值。也可以理解为当一个节点更新操作成功后，所有节点在同一时间的数据保持一致。

所有的读/写操作都能在一定响应时间内及时响应，可以终止、不会一直等待，不出现用户操作失败或者访问超时等用户体验不好的情况。可用性通常情况下和分布式数据冗余，负载均衡等有着很大的关联。

通常采用停机时间来衡量一个系统的可用性，称之为N个9。

以5个9（99.999%）为例，它的计算公式如下：
$\times 365 \times 24 \times 60 = 5.256$
也就是说全年停机时间不超过5.256分钟，至于6个9，全年停机时间不超过半分钟（已经十分夸张了）。

分区容错性是指除非整个网络瘫痪，否则一直能够对外提供服务。在系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

CAP理论证明了一个系统不能同时满足C、A、P三个理论，只能三选二。以下图为例：

CAP证明

现在有一个客户端向三个节点发送信息，假定只要有一个节点成功则认为成功，那么如果【N2】和【N3】成功写入但是【N1】因为网络故障没有成功写入，对于客户端来说依旧认为系统可用，但是从服务端的角度触发各个节点之间的一致性（C）就会被放弃，但是保证了可用性（A）。

现在假定所有节点都写入成功才认为操作成功，则【N1】因为网络故障写入失败，那么【N2】和【N3】就会回滚，那么整个操作也就失败了，这样做虽然保证了一致性（C），但是放弃了可用性（A）。

综上，任何一个分布式系统无法同时保证CAP，必须进行三选二，以一张表进行说明：

选择	说明
CA	放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择
AP	放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式系统设计时的选择，例如很多NoSQL系统就是如此
CP	放弃可用性，追求一致性和分区容错性，一些分布式数据库会选用此方案

在分布式环境下，P是一定存在的，一旦出现了网络分区，那么一致性和可用性就一定要抛弃一个。

对于NoSQL系统，更加注重可用性，所以会使一个AP系统；
对于分布式关系型数据库，强调一致性，所以一般会是一个CP系统，虽然分布式关系型数据库无法做到100% 高可用，单一般做到5个9。实际应用中通常采用如下两个指标进行评价
- RPO（Recovery Point Objective）：指数据库在灾难发生后会丢失多长时间数据，只要还有一个节点保留了最新数据，那么RPO=0；
- RTO（Recovery Time Objective）：指数据库在灾难发生后多长时间恢复正常，一般指定一个阈值，保证RTO<几分钟。

BASE理论是CAP理论的一种妥协，由于cap只能CA二选一，所以BASE理论降低了对可用性和一致性的要求。

基本可用（Basic Available）：允许可用性降低（可能响应延长、可能服务降级）；
软状态（Soft State）：指允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，比方说【正在同步】这个状态，其实就是允许节点间交互数据具有一定的延迟；
最终一致性（Eventually consistent）：所有节点数据同步可以存在时延，在一定时间后必须达成数据一致。