CAP理论

CAP 理论具体是什么

CAP 理论：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容忍性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。

可能会有疑惑

分区容忍性到底是什么？听着好像和可用性差不多，就是网络异常不能访问吗？

其实不是。

可用性强调的是能否给到正常响应，而分区容忍性强调的是，当网络出现分区时，怎么做，能够让整个系统能够应对分区现象，才能让整个系统拥有更高的容错性。

当一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了，这时分区导致的结果，就是无法容忍的。

提高分区容忍性的办法就是一个数据项复制到多个节点上，当出现分区之后，这一数据项就可能分布到各个区里，容忍性就提高了。

一般来说，分布式系统下，分区问题是无法避免的，也是一定要满足的，因此 CAP 的 P 总是成立，所以开源分布式系统又会被划分为 CP 系统和 AP 系统。比如著名的 zookeeper 就是一个牺牲可用性，保证一致性的 CP 系统。

CAP 理论产生背景

CAP 是埃里克·布鲁尔（Eric Brewer）在2000年的分布式计算原理研讨会（PODC）上提出的一个猜想，在2002年，麻省理工学院（MIT）的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了布鲁尔猜想的证明，使之成为一个定理。CAP定理也称为布鲁尔定理（Brewer’s theorem）。

CAP 论证

对于一个分布式系统，和单机系统最大的区别，就是网络，网络是不可靠的，但是分区容忍性是一定要满足的。如果不满足分区容忍性，那可能就不算是一个分布式系统了，更像是多个单机组成的系统。

但满足分区容忍性，就要把数据复制到多个节点，因为复制时效的问题，就会带来一致性和可用性问题。

所以，要满足分区容忍性的话，能不能同时满足一致性和可用性？还是说要进行取舍？

CAP 理论认为，在满足 P 的前提下，C 和 A 是无法同时做到的。为什么无法同时做到？下面开始论证这个结论：

初始化论证场景

• 分布式系统下有两台实例 N1 和 N2，N1 和 N2 网络可以连通
• N1 部署了一个服务 A、数据库 V（数据初始 V0 版本）
• N2 部署了一个服务 B 、数据库 V（数据初始 V0 版本）

理想情况下结论

• 在满足一致性时，N1 与 N2 的数据永远一致，即 V0 = V0
• 在满足可用性时，用户请求 N1 与 N2，永远都能够在合理时间内获得正常响应
• 在满足分区容忍性时，即使实例间通信异常 或 出现宕机，服务仍能够提供服务

但，现实往往是残酷的……

假设分布式系统出现如下场景

1. 服务 A 接收到用户的写请求，将 N1 的数据由 V0 版本变更为 V1 版本
2. 此时，网络出现分区，导致 N1 的数据无法同步至 N2
3. 这个时候，凑巧用户请求服务 B 来读取数据，现在 N2 的数据因无法同步的原因，还是 V0 版本的数据，无法将最新数据 V1 给到用户

面临选择

这时，基于 CAP 理论，就面临了 2 种选择：

• AP without C，保证可用性，牺牲一致性。返回 V0 版本数据给用户
• CP without A，保证一致性，牺牲可用性，阻塞直到 V1 版本同步过来，再把 V1 版本数据返回给用户

论证结果

至此，论证了，要想满足分区容忍性，只能选择一致性或可用性，即 CP or AP

现有系统分析

AP 场景业务：

• 12306。在节假日高峰期抢票时，偶尔会遇到，反复看到某车次有余票，但每次真正点击购买时，却提示说没有余票。这样设计，虽然很小一部分功能受限，但系统整体服务稳定，影响非常有限，相比 CP，用户体验会更佳。
• 微博。如果某个区域的网络中断，区域内的用户仍然发微博、相互评论和点赞，但暂时无法看到其他区域用户发布的新微博和互动状态。
• 基于 eureka 的服务发现设计，更追求 AP

CP 场景业务：

• 银行余额提现之类的业务，就一定要保证一致性
• 12306 等购票下单等交易支付场景
• 基于 zookeeper 的服务发现设计，更追求 CP

同一系统内，不同业务，同一个业务处理的不同阶段，在分区发生时，选择一致性和可用性的策略可能都不同。比如 12306 在车次查询、余票查询这里就会选择 AP，但在购票支付阶段，则会选择 CP。因此，在系统架构或功能设计时，并不能简单选择 AP 或者 CP，还是需要具体场景具体看。

总结

CAP 一直存在很多争论，但其实 CAP 是学术理论，而非工程理论，并不解决工程问题，也就是基于 CAP 理论，无法确认某个系统应该选择 C 还是 A，选择是由工程自身场景去决定的。

作为学术理论，它本身就舍弃了很多现实的细节问题和边界问题，比如节点内部处理速度不一致、各节点的存储方式和速度的不一致，所以不需要过多的从工程角度去解读，不要做过多的脑补，能够理解 CAP 理论的用意就好。

并且 CAP 是在分布式系统还未火热的时候，归纳出了分布式系统设计中所需权衡重要的方向。CAP 的意义在于设计分布式系统时需要考虑取舍，它并不是一个严格的分类方式。

其次，在分布式系统中，分区问题肯定会发生，但却很少发生，或者说相对于稳定的环境，会很短且很小概率。当不存在分区时，不应该只选择 C 或者 A，而是可以同时提供一致性和可用性。如今做系统设计时，也不需要硬要给系统贴上 C/A/P 的标签，也不用太过拘泥于 CAP 原则，因为它不是解决工程问题的一个方式，能在设计时考虑取舍就够了。

作者新观点

CAP 在发表的第 12 个年头，即2012年，Eric Brewer 也承认 CAP 具有误导性而且过于简单化，同时作者表示，CAP 理论更多的是开阔设计师的思路，在过年的十几年里，也一直存在着「三选二」的误导性。

Eric Brewer 还阐述了他的新观点：由于分区很少发生，那么在系统不存在分区的情况下没什么理由牺牲 C 或 A。C/A/P 这三种性质可以在程度上衡量，并不是非黑即白的有或无。可用性显然是在 0% 到 100% 之间连续变化的，一致性分很多级别，连分区也可以细分为不同含义。因为分区很少出现，CAP 在大多数时候允许完美的 C 和 A。

BASE 理论

产生背景

CAP 理论在出现分区时，确实无法同时满足 C 和 A，为了用户体验，大多数系统都会选择可用性，但一致性又很重要。

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果。理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

基本可用（Basically Available）

基本可用是指，系统出现故障后，还是能用的状态，但相对于正常的系统，会有一些损失：耗时增加、舍弃部分边缘功能，保证核心功能可用

软状态（Soft State）

软状态是相对原子性来说的：

• 原子性（硬状态）： 要求多个节点的数据副本都是一致的，这是一种”硬状态”
• 软状态（弱状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，也就是允许系统在多个不同节点的数据副本存在数据延迟

最终一致性（Eventually Consistent）

处于软状态的数据，必须要在一段时间后，变更为最终状态。也就是在软状态超过存留期限后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性