简答

2000 年 7 月，来自加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC（Principles of Distributed Computing）会议上，首次提出了著名的 CAP 猜想。其理论观点是，在分布式计算机系统中不可能同时提供以下三个保证：

• 一致性（Consistency）：所有节点同一时间看到的是相同的数据。
• 可用性（Availability）：不管是否成功，确保每一个请求都能接收到响应。
• 分区容错性（Partition tolerance）：将系统任意分区后，在网络故障后，仍能操作。

在 2003 年的时候，来自麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上正式证明了 Brewer 教授 CAP 猜想的可行性。从此，CAP 理论正式在学术上成为了分布式计算领域的公认定理，并深深地影响了分布式计算的发展。

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

CP 模型举例：Zookeeper、HBase

AP 模型举例：Eureka、Redis 集群、DNS

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写，是由来自 eBay 的架构师 Dan Pritchett 在其文章 BASE: An Acid Alternative 中第一次明确提出的。

BASE 是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

详解

对于本地事务处理或者是集中式的事务处理系统，很显然我们可以采用已经被实践证明很成熟的 ACID 模型来保证数据的严格一致性。随着分布式事务的出现，传统的单机事务模型已经无法胜任。尤其是对于一个高访问量、高并发的互联网分布式系统来说，如果我们期望实现一套严格满足 ACID 特性的分布式事务，很可能出现的情况就是在系统的可用性和严格一致性之间出现冲突——因为当我们要求分布式系统具有严格一致性时，很可能就需要牺牲掉系统的可用性。

但毋庸置疑的一点是，可用性又是一个所有消费者不允许我们讨价还价的系统属性。而对于一致性，则更加是所有消费者对于一个软件系统的刚需。因此，在可用性和一致性之间永远无法存在一个两全其美的方案，于是如何构建一个兼顾可用性和一致性的分布式系统成为了无数工程师探讨的难题，出现了诸如 CAP 和 BASE 这样的分布式系统经典理论。

1 CAP 定理

2000 年 7 月，来自加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC（Principles of Distributed Computing）会议上，首次提出了著名的 CAP 猜想。其理论观点是，在分布式计算机系统中不可能同时提供以下三个保证：

• 一致性（Consistency）：所有节点同一时间看到的是相同的数据。
• 可用性（Availability）：不管是否成功，确保每一个请求都能接收到响应。
• 分区容错性（Partition tolerance）：将系统任意分区后，在网络故障后，仍能操作。

2 年后，在 2003 年的时候，来自麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上正式证明了 Brewer 教授 CAP 猜想的可行性。从此，CAP 理论正式在学术上成为了分布式计算领域的公认定理，并深深地影响了分布式计算的发展。

Gilbert 认为这里所说的一致性（Consistency）其实就是数据库系统中提到的 ACID 的另一种表述：一个用户请求要么成功、要么失败，不能处于中间状态（Atomic）；一旦一个事务完成，将来的所有事务都必须基于这个完成后的状态（Consistent）；未完成的事务不会互相影响（Isolated）；一旦一个事务完成，就是持久的（Durable）。对于可用性（Availability），其概念没有变化，指的是对于一个系统而言，所有的请求都应该“成功”并且收到“返回”。分区容错性（Partition tolerance）指的就是分布式系统的容错性。节点崩溃或者网络分片都不应该导致一个分布式系统停止服务。

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

1.1 一致性

在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。

对于一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是老数据（或称为脏数据），这就是典型的分布式数据不一致情况。在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性）。

1.2 可用性

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里我们重点看下“有限的时间内”和“返回结果”。

“有限的时间内”是指，对于用户的一个操作请求，系统必须能够在指定的时间（即响应时间）内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。另外，“有限的时间内”是一个在系统设计之初就设定好的系统运行指标，通常不同的系统之间会有很大的不同。比如说，对于一个在线搜索引擎来说，通常在 0.5 秒内需要给出用户搜索关键词对应的检索结果。以 Google 为例，搜索“分布式”这一关键词，Google 能够在 0.3 秒左右的时间，返回大约上千万条检索结果。而对于一个面向 HIVE 的海量数据查询平台来说，正常的一次数据检索时间可能在 20 秒到 30 秒之间，而如果是一个时间跨度很大的数据内容查询，“有限的时间”有时候甚至会长达几分钟。

从上面的例子中，我们可以看出，用户对于一个系统的请求响应时间的期望值不尽相同。但是，无论系统之间的差异有多大，唯一相同的一点就是对于用户请求，系统必须存在一个合理的响应时间，否则用户便会对系统感到失望。

“返回结果”是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出对请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。

让我们再来看看上面提到的在线搜索引擎的例子，如果用户输入指定的搜索关键词后，返回的结果是一个系统错误，通常类似于“OutOfMemoryError”或“System Has Crashed”等提示语，那么我们认为此时系统是不可用的。

1.3 分区容错性

分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络等）中，由于一些特殊的原因导致这些子网络之间出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是，组成一个分布式系统的每个节点的加入和退出都可以看作是一个特殊的网络分区。

以上就是对 CAP 定理中一致性、可用性和分区容错性的讲解。

1.4 为什么 CAP 只能三选二

例如，一个网络中，N1 和 N2 两个节点共享数据块 V，其中有一个值 V0。运行在 N1 上的 A 程序可以认为是安全、无 bug、可预测和可靠的。运行在 N2 上的是 B 程序。在这个例子中，A 将写入 V 的新值，而 B 从 V 中读取值。

系统预期执行的操作如下：

1. 写一个 V 的新值 V1。
2. 消息（M）从 N1 更新 V 的副本到 N2.
3. 从 B 读取返回的 V1。

如果网络是分区的，当 N1 到 N2 的消息不能传递时，执行第三步，会出现虽然 N2 能访问 V 的值（可用性），但其实与 N1 的 V 值已经不一致了（一致性）的情况。

1.5 抛弃 CAP 其一的不同场景

既然在上文中我们提到，一个分布式系统无法同时满足上述三个需求，而只能满足其中的两项，因此在进行对 CAP 定理的应用时，我们就需要抛弃其中的一项，下面表格所示是抛弃 CAP 定理中任意一项特性的场景说明。

从 CAP 定理中我们可以看出，一个分布式系统不可能同时满足一致性、可用性和分区容错性这三个需求。另一方面，需要明确的一点是，对于一个分布式系统而言，分区容错性可以说是一个最基本的要求。为什么这样说，其实很简单，因为既然是一个分布式系统，那么分布式系统中的组件必然需要被部署到不同的节点，否则也就无所谓分布式系统了，因此必然出现子网络。而对于分布式系统而言，网络问题又是一个必定会出现的异常情况，因此分区容错性也就成为了一个分布式系统必然面对和解决的问题。因此系统架构设计师往往需要把精力花在如何根据业务特点在 C（一致性）和 A（可用性）之间寻求平衡。

1.6 CAP 常见模型

既然 CAP 理论已经证明了一致性、可用性、分区容错性三者不可能同时达成。那么在实际应用中，可以在其中的某一些方面来放松条件，从而达到妥协。下面是常见的三种 CAP 模型。

1.6.1 牺牲分区（CA 模型）

牺牲分区容错性意味着把所有的机器搬到一台机器内部，或者放到一个“要死大家一起死”的机架上（当然机架也可能部分失效），这明显违背了我们希望获得的可伸缩性。

CA 模型常见的例子：

• 单站点数据库；
• 集群数据库；
• LDAP；
• xFS 文件系统。

实现方式：

• 两阶段提交；
• 缓存验证协议。

1.6.2 牺牲可用性（CP 模型）

牺牲可用性意味着一旦系统中出现分区这样的错误，则系统直接停止服务。

CP 模型常见的例子：

• 分布式数据库；
• 分布式锁；
• 绝大部分协议。

实现方式：

• 悲观锁；
• 少数分区不可用。

1.6.3 牺牲一致性（AP 模型）

AP 模型常见的例子：

• Coda；
• Web 缓存；
• DNS。

实现方式：

• 到期/租赁；
• 解决冲突；
• 乐观。

1.6.4 《凤凰架构》中的举例

• 如果放弃分区容忍性（CA without P），意味着我们将假设节点之间通信永远是可靠的。永远可靠的通信在分布式系统中必定不成立的，这不是你想不想的问题，而是只要用到网络来共享数据，分区现象就会始终存在。在现实中，最容易找到放弃分区容忍性的例子便是传统的关系数据库集群，这样的集群虽然依然采用由网络连接的多个节点来协同工作，但数据却不是通过网络来实现共享的。

  以 Oracle 的 RAC 集群为例，它的每一个节点均有自己独立的 SGA、重做日志、回滚日志等部件，但各个节点是通过共享存储中的同一份数据文件和控制文件来获取数据的，通过共享磁盘的方式来避免出现网络分区。因而 Oracle RAC 虽然也是由多个实例组成的数据库，但它并不能称作是分布式数据库。

• 如果放弃可用性（CP without A），意味着我们将假设一旦网络发生分区，节点之间的信息同步时间可以无限制地延长，此时，问题相当于退化到前面“全局事务”中讨论的一个系统使用多个数据源的场景之中，我们可以通过 2PC/3PC 等手段，同时获得分区容忍性和一致性。

  在现实中，选择放弃可用性的 CP 系统情况一般用于对数据质量要求很高的场合中，除了 DTP 模型的分布式数据库事务外，著名的 HBase 也是属于 CP 系统，以HBase 集群为例，假如某个 RegionServer 宕机了，这个 RegionServer 持有的所有键值范围都将离线，直到数据恢复过程完成为止，这个过程要消耗的时间是无法预先估计的。

• 如果放弃一致性（AP without C），意味着我们将假设一旦发生分区，节点之间所提供的数据可能不一致。选择放弃一致性的 AP 系统目前是设计分布式系统的主流选择，因为 P 是分布式网络的天然属性，你再不想要也无法丢弃；而 A 通常是建设分布式的目的，如果可用性随着节点数量增加反而降低的话，很多分布式系统可能就失去了存在的价值，除非银行、证券这些涉及金钱交易的服务，宁可中断也不能出错，否则多数系统是不能容忍节点越多可用性反而越低的。

  目前大多数 NoSQL 库和支持分布式的缓存框架都是 AP 系统，以 Redis 集群为例，如果某个 Redis 节点出现网络分区，那仍不妨碍各个节点以自己本地存储的数据对外提供缓存服务，但这时有可能出现请求分配到不同节点时返回给客户端的是不一致的数据。

1.7 CAP 最新发展

Eric Brewer 在 2012 年发表文章指出了 CAP 里面“三选二”的做法存在一定的误导性，主要体现在：

• 由于分区很少发生，在系统不存在分区的情况下没什么理由牺牲 C 或 A；
• C 与 A 之间的取舍可以在同一系统内以非常细小的粒度反复发生，而每一次的决策可能因为具体的操作，乃至因为牵涉特定的数据或用户而有所不同；
• 这三种性质都可以在一定程度上衡量，并不是非黑即白的有或无。可用性显然是在 0% 到 100% 之间连续变化的。一致性分很多级别，连分区也可以细分为不同含义，如系统内的不同部分对于是否存在分区可以有不一样的认知。

理解 CAP 理论最简单的方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了 C 性质。如果为了保证数据的一致性，将分区一侧的节点设置为不可用，那么又丧失了 A 性质。除非两个节点可以互相通信，才能既保证 C 又保证 A，但这又会导致丧失 P 性质。一般来说，跨区域的系统，架构师无法舍弃 P 性质，就只能在数据一致性和可用性上做一个艰难的选择。不确切地说，NoSQL 运动的主题其实是创造各种可用性优先、数据一致性其次的方案；而传统数据库坚守 ACID 特性，做的是相反的事情。

2 BASE 理论

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写，是由来自 eBay 的架构师 Dan Pritchett 在其文章 BASE: An Acid Alternative 中第一次明确提出的。

BASE 是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来我们着重对 BASE 中的三要素进行详细讲解。

2.1 基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。以下两个就是“基本可用”的典型例子。

• 响应时间上的损失：正常情况下，一个在线搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1 ~ 2 秒。
• 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

2.2 弱状态

弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

2.3 最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证数据的强一致性。

亚马逊首席技术官 Werner Vogels 在于 2008 年发表的一篇经典文章 Eventually Consistent Revisited 中，对最终一致性进行了非常详细的介绍。他认为最终一致性是一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够获取到最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟、系统负载的数据复制方案设计等因素。

在实际工程实践中，最终一致性存在以下五类主要变种。

因果一致性（Causal consistency）

因果一致性是指，如果进程 A 在更新完某个数据项后通知了进程 B，那么进程 B 之后对该数据项的访问都应该能够获取到进程 A 更新后的最新值，并且如果进程 B 要对该数据项进行更新操作的话，务必基于进程 A 更新后的最新值，即不能发生丢失更新情况。与此同时，与进程 A 无因果关系的进程 C 的数据访问则没有这样的限制。

读己之所写（Read your writes）

读己之所写是指，进程 A 更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者来说，其读取到的数据，一定不会比自己上次写入的值旧。因此，读己之所写也可以看作是一种特殊的因果一致性。

会话一致性（Session consistency）

会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读己之所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

单调读一致性（Monotonic read consistency）

单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

单调写一致性（Monotonic write consistency）

单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。

以上就是最终一致性的五类常见的变种，在实际系统实践中，可以将其中的若干个变种互相结合起来，以构建一个具有最终一致性特性的分布式系统。事实上，最终一致性并不是只有那些大型分布式系统才涉及的特性，许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中，大多都会采用同步和异步方式来实现主备数据复制技术。在同步方式中，数据的复制过程通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往会存在延时，这取决于事务日志在主备数据库之间传输的时间长短，如果传输时间过长或者甚至在日志传输过程中出现异常无法及时将事务应用到备库上，那么很显然，从备库上读取的数据将是旧的，因此就出现了数据不一致的情况。当然，无论是采用多次重试还是人为数据订正，关系型数据库还是能够保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。

总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 特性是相反的，它完全不同于 ACID 的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID 特性与 BASE 理论往往又会结合在一起使用。

参考文档

• 《从 Paxos 到 Zookeeper：分布式一致性原理与实践》1.2.3 CAP 和 BASE 理论
• 《分布式系统：常用技术及案例分析》1.6 CAP 理论
• 《凤凰架构》5.2.4 分布式事务 1. CAP 和 ACID