CAP 理论

CAP 定理（CAP theorem）又被称作布鲁尔定理（Brewer's theorem），是加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想。2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了布鲁尔猜想的证明，使之成为分布式计算领域公认的一个定理。对于设计分布式系统的架构师来说，CAP 是必须掌握的理论。

Consistency：等同于所有节点访问同一份最新的数据副本

Availability：对数据更新具备高可用性

Partition tolerance ：以实际效果而言，分区相当于对通信的时限要求。

任何分布式架构设计的系统，只能同时满足 CAP 中的任意两种，无法同时三种并存。

CAP（Consistency、Availability、Partition tolerance） 分别代表一致性，可用性，分区容错性。

Consistency 一致性

我们知道 ACID 中事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行前后，数据库都必须处于一致性状态。

也就是说，事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。

举个例子：

A 转账 B ，A 扣款一百，B 增加一百，这个是业务层级的一致性，连个业务都执行，才能保证最终一致性状态。

这种从刚开始的不变的状态，转变为另一种最终一致的状态，就是一致性。

分布式环境中的一致性是指数据在多个副本之间是否能够保持一致。这点应该不难理解，分布式集群架构中，有可能服务节点是多个，这个时候我们就要考虑多个服务的情况下，读取的数据是否都能够一致，或者数据库集群中的数据是否都能够保证一致。

强一致性

要求所有系统中的数据必须一致，不管谁先执行操作，都要等到其他系统数据更新完成才能继续执行下一步。

这点就会对性能有一部分影响，因为要确保所有节点的完全一致。

数据库为例，单库的数据肯定是一致的。多库情况下，其他节点的数据必须等到日志更新所有数据库完全后才能读取，这样才会保证数据的一致性。

弱一致性 & 最终一致性

弱一致指数据更新后，不会立即要求所有的节点必须先同步，允许在一定时间后达到同步，这里面还有一种情况就是可能数据同步会失败，怎么办？

重试机制，失败了就再次尝试，直到最终达到一致性。

Availability 可用性

用户访问的服务会处在一种一直可用的集群状态，也就是服务高可用。能够保证一个请求在规定的有限时间返回结果。这里面还要考虑到服务熔断、异常返回、服务降级（容错性）。这些都是微服务里面的重要概念。

Partition tolerance 分区容错性

容错性就是网络节点之间无法通信的情况下，节点被隔离，产生了网络分区， 整个系统仍然是可以工作的。

随着网络节点出现问题，产生了分区，这时候其他节点和出错节点的数据必然会不一致，这时候就要面临选择，是选择停掉所有的服务，等网络节点修复后恢复数据，以此来保证一致性（PC）,还是选择继续提供服务，放弃强一致性的要求，以此来保证整体的可用性（PA）。

更多 CAP 理论优秀课程

从 0 开始学架构

在极客时间的《从 0 开始学架构》中，有更详细的说明：

https://time.geekbang.org/column/article/9390

• CAP 关注的粒度是数据，而不是整个系统。

• CAP 是忽略网络延迟的。

CAP 理论告诉我们分布式系统只能选择 CP 或者 AP，但其实这里的前提是系统发生了“分区”现象。如果系统没有发生分区现象，也就是说 P 不存在的时候（节点间的网络连接一切正常），我们没有必要放弃 C 或者 A，应该 C 和 A 都可以保证，这就要求架构设计的时候既要考虑分区发生时选择 CP 还是 AP，也要考虑分区没有发生时如何保证 CA。

BASE

BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。前面在剖析 CAP 理论时，提到了其实和 BASE 相关的两点：

• CAP 理论是忽略延时的，而实际应用中延时是无法避免的。

• AP 方案中牺牲一致性只是指分区期间，而不是永远放弃一致性。

《分布式协议与算法实战》

https://time.geekbang.org/column/article/195675

通过为单机开源版的 InfluxDB 设计分区容错一致性模型深入理解 CAP 理论。

因为 InfluxDB 有 META 和 DATA 两个节点，它们的功能和数据特点不同，所以我还需要考虑这两个逻辑单元的特点，然后分别设计分区容错一致性模型。

根据业务场景的特点进行 CAP 权衡，设计出适合的分区容错一致性模型。

CAP 不可能三角说的是对于一个分布式系统而言，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）3 个指标不可兼得，只能在 3 个指标中选择 2 个。

CAP 不能三角最初是埃里克·布鲁尔（Eric Brewer）基于自己的工程实践，提出的一个猜想，后被赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）证明，证明过程可以参考论文《Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services》，

分区容错性（P）是前提，是必须要保证的。

• 当选择了一致性（C）的时候，一定会读到最新的数据，不会读到旧数据，但如果因为消息丢失、延迟过高发生了网络分区，那么这个时候，当集群节点接收到来自客户端的读请求时，为了不破坏一致性，可能会因为无法响应最新数据，而返回出错信息。

• 当选择了可用性（A）的时候，系统将始终处理客户端的查询，返回特定信息，如果发生了网络分区，一些节点将无法返回最新的特定信息，它们将返回自己当前的相对新的信息。

CAP 理论是一个很好的思考框架，能帮助我们思考，如何进行权衡，设计适合业务场景特性的分布式系统。