CAP 理论学习

1. 什么是分布式系统

在《分布式系统概念与设计》一书中,对分布式系统做了如下定义:

分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。

上面这个简单的定义涵盖了几乎所有有效地部署了网络化计算机的系统。严格地讲,同一个分布式系统中的计算机在空间部署上是可以随意分布的, 这些计算机可能被放在不同的机柜上,也可能在不同的机房中,甚至分布在不同的城市。无论如何,一个标准的分布式系统在没有任何特定业务逻辑约束的情况下,都会有如下几个特征。

1.1 分布式系统的特点

1.1.1 分布性

分布式系统中的多台计算机都会在空间上随意分布,同时,机器的分布情况也会随时变动。

1.1.2. 对等性

分布式系统中的计算机没有主/从之分,既没有控制整个系统的主机,也没有被控制的从机,组成分布式系统的所有计算机节点都是对等的。副本(Replica)是分布式系统最常见的概念之一,指的是分布式系统对数据和服务提供的一种冗余方式。在常见的分布式系统中,为了对外提供高可用的服务,我们往往会对数据和服务进行副本处理。

• 数据副本是指在不同的节点上持久化同一份数据,当某一个节点上存储的数据丢失时,可以从副本上读取到该数据,这是解决分布式系统数据丢失问题最为有效的手段。
• 另一类副本是服务副本,指多个节点提供同样的服务,每个节点都有能力接收来自外部的请求并进行相应的处理。

1.1.3. 并发性

在一个计算机网络中,程序运行过程中的并发性操作是非常常见的行为,例如同一个分布式系统中的多个节点,可能会并发地操作一些共享的资源,诸如数据库或分布式存储等, 如何准确并高效地协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一。

1.1.4. 缺乏全局时钟

在上面的讲解中,我们已经了解到,一个典型的分布式系统是由一系列在空间上随意分布的多个进程组成的,具有明显的分布性,这些进程之间通过交换消息来进行相互通信。因此,在分布式系统中,很难定义两个事件究竟谁先谁后,原因就是因为分布式系统缺乏一个全局的时钟序列控制。关于分布式系统的时钟和事件顺序,在 Leslie Lamport 2的经典论文 Time,Clocks, and the Ordering of Events in a Distributed System "中已经做了非常深刻的讲解。

1.1.5. 故障总是会发生

组成分布式系统的所有计算机,都有可能发生任何形式的故障。一个被大量工程实践所检验过的黄金定理是:任何在设计阶段考虑到的异常情况,一定会在系统实际运行中发生, 并且,在系统实际运行过程中还会遇到很多在设计时未能考虑到的异常故障。所以,除非需求指标允许,在系统设计时不能放过任何异常情况。这个时候就可以发现一套完整的服务监控平台的重要性。

1.2. 分布式环境的各种问题

1.2.1通信异常

从集中式向分布式演变的过程中,必然引入了网络因素,而由于网络本身的不可靠性,因此也引入了额外的问题。分布式系统需要在各个节点之间进行网络通信,因此每次网络通信都会伴随着网络不可用的风险,网络光纤、路由器或是 DNS 等硬件设备或是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。另外,即使分布式系统各节点之间的网络通信能够正常进行,其延时也会远大于单机操作。通常我们认为在现代计算机体系结构中,单机内存访问的延时在纳秒数量级(通常是 10ns 左右),而正常的一次网络通信的延迟在 0.1\~1ms 左右(相当于内存访问延时的 105~106 倍),如此巨大的延时差别,也会影响消息的收发的过程,因此消息丢失和消息延迟变得非常普遍。

1.2.2 网络分区

当网络由于发生异常情况,导致分布式系统中部分节点之间的网络延时不断增大,最终导致组成分布式系统的所有节点中,只有部分节点之间能够进行正常通信, 而另一些节点则不能——我们将这个现象称为网络分区,就是俗称的“脑裂”。当网络分区出现时,分布式系统会出现局部小集群,在极端情况下,这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能,包括对数据的事务处理,这就对分布式一致性提出了非常大的挑战。

1.2.3 三态

从上面的介绍中,我们已经了解到了在分布式环境下, 网络可能会出现各式各样的问题,因此分布式系统的每一次请求与响应,存在特有的“三态”概念,即成功、失败与超时。

在传统的单机系统中,应用程序在调用一个函数之后,能够得到一个非常明确的响应:成功或失败。而在分布式系统中,由于网络是不可靠的,虽然在绝大部分情况下,网络通信也能够接收到成功或失败的响应,但是当网络出现异常的情况下,就可能会出现超时现象。通常有以下两种情况:

• 由于网络原因,该请求(消息)并没有被成功地发送到接收方,而是在发送过程就发生了消息丢失现象。
• 该请求(消息)成功的被接收方接收后,并进行了处理,但是在将响应反馈给发送方的过程中,发生了消息丢失现象。

当出现这样的超时现象时,网络通信的发起方是无法确定当前请求是否被成功处理的。

1.2.4 节点故障

节点故障则是分布式环境下另一个比较常见的问题, 指的是组成分布式系统的服务器节点出现的宕机或“僵死”现象。通常根据经验来说,每个节点都有可能会出现故障,并且每天都在发生。

2. ACID

在上文中,我们讲解了集中式系统和分布式系统各自的特点,同时也看到了在从集中式系统架构向分布式系统架构变迁的过程中会碰到的一系列问题。接下来,我们再重点看看在分布式系统事务处理与数据一致性上遇到的种种挑战。

2.1 ACID

事务(Transaction)是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元(Unit),狭义上的事务特指数据库事务。

• 一方面,当多个应用程序并发访问数据库时,事务可以在这些应用程序之间提供一个隔离方法,以防止彼此的操作互相干扰。

• 另一方面,事务为数据库操作序列提供了一个从失败中恢复到正常状态的方法,同时提供了数据库即使在异常状态下仍能保持数据一致性的方法。

事务具有四个特征,分别是原子性(Atomicity)､一致性(Consistency)､隔离性(Isolation)和持久性(Durability),简称为事务的 ACID 特性。

2.1.1 原子性

事务的原子性是指事务必须是一个原子的操作序列单元。事务中包含的各项操作在一次执行过程中,只允许出现以下两种状态之一。

• 全部成功执行。
• 全部不执行。

任何一项操作失败都将导致整个事务失败, 同时其他已经被执行的操作都将被撤销并回滚,只有所有的操作全部成功,整个事务才算是成功完成。

2.1.2 一致性

事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性, 一个事务在执行之前和执行之后,数据库都必须处于一致性状态。也就是说,事务执行的结果必须是使数据库从一个一致性状态转变到另一个一致性状态,因此当数据库只包含成功事务提交的结果时,就能说数据库处于一致性状态。而如果数据库系统在运行过程中发生故障,有些事务尚未完成就被迫中断, 这些未完成的事务对数据库所做的修改有一部分已写入物理数据库,这时数据库就处于一种不正确的状态,或者说是不一致的状态。

2.1.3 隔离性

事务的隔离性是指在并发环境中,并发的事务是相互隔离的, 一个事务的执行不能被其他事务干扰。也就是说,不同的事务并发操纵相同的数据时,每个事务都有各自完整的数据空间,即一个事务内部的操作及使用的数据对其他并发事务是隔离的,并发执行的各个事务之间不能互相干扰。

在标准 SQL 规范中,定义了4个事务隔离级别,不同的隔离级别对事务的处理不同,如未授权读取、授权读取、可重复读取和串行化。

2.1.3.1 读未提交

读未提交(Read Uncommitted),该隔离级别允许脏读取,其隔离级别最低。换句话说,如果一个事务正在处理某一数据,并对其进行了更新,但同时尚未完成事务,因此还没有进行事务提交;而与此同时,允许另一个事务也能够访问该数据。举个例子来说,事务 A 和事务 B 同时进行,事务 A 在整个执行阶段,会将某数据项的值从1开始,做一系列加法操作(比如说加1操作)直到变成 10 之后进行事务提交,此时,事务 B能够看到这个数据项在事务A操作过程中的所有中间值(如1变成2､2变成3等),而对这一系列的中间值的读取就是未授权读取。

2.1.3.2 读已提交

读已提交(Read Committed),它和未授权读取非常相近,唯一的区别就是授权读取只允许获取已经被提交的数据。同样以上面的例子来说,事务A 和事务 B 同时进行,事务A 进行与上述同样的操作,此时,事务 B 无法看到这个数据项在事务 A 操作过程中的所有中间值,只能看到最终的 10。另外,如果说有一个事务 C,和事务 A 进行非常类似的操作,只是事务C是将数据项从 10 加到20,此时事务 B 也同样可以读取到 20,即授权读取允许不可重复读取。

2.1.3.3 可重复读取

可重复读取(Repeatable Read),简单地说,就是保证在事务处理过程中,多次读取同一个数据时,其值都和事务开始时刻是一致的。因此该事务级别禁止了不可重复读取和脏读取,但是有可能出现幻影数据。所谓幻影数据,就是指同样的事务操作,在前后两个时间段内执行对同一个数据项的读取,可能出现不一致的结果。 在上面的例子,可重复读取隔离级别能够保证事务 B 在第一次事务操作过程中,始终对数据项读取到 1,但是在下一次事务操作中,即使事务 B(注意,事务名字虽然相同,但是指的是另一次事务操作)采用同样的查询方式,就可能会读取到 10 或 20。

2.1.3.4 串行化

串行化(Serializable)是最严格的事务隔离级别。它要求所有事务都被串行执行,即事务只能一个接一个地进行处理,不能并发执行。

事务隔离级别越高,就越能保证数据的完整性和一致性,但同时对并发性能的影响也越大。通常,对于绝大多数的应用程序来说,可以优先考虑将数据库系统的隔离级别设置为Read Committed,这能够在避免脏读取的同时保证较好的并发性能。尽管这种事务隔离级别会导致不可重复读、虚读和第二类丢失更新等并发问题,但较为科学的做法是在可能出现这类问题的个别场合中,由应用程序主动采用悲观锁或乐观锁来进行事务控制。

2.1.4 持久性

事务的持久性也被称为永久性,是指一个事务一旦提交,它对数据库中对应数据的状态变更就应该是永久性的。换句话说,一旦某个事务成功结束,那么它对数据库所做的更新就必须被永久保存下来——即使发生系统崩溃或机器宕机等故障,只要数据库能够重新启动,那么一定能够将其恢复到事务成功结束时的状态。

3. BASE 理论

BASE 是 Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写,是由来自 eBay 的架构师 Dan Pritchett 在其文章 BASE:An Acid Alternative 中第一次明确提出的。BASE 是对 CAP 中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结,是基于 CAP 定理逐步演化而来的,其核心思想是即使无法做到強一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

它的核心思想是既然无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。

基本可用（Basically Available）

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

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

弱状态（Soft state）

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

最终一致性(Eventually consistent)

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

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

事实上,最终一致性并不是只有那些大型分布式系统才涉及的特性, 许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中,大多都会采用同步和异步方式来实现主备数据复制技术。

在同步方式中,数据的复制过程通常是更新事务的一部分,因此在事务完成后,主备数据库的数据就会达到一致。而在异步方式中,备库的更新往往会存在延时,这取决于事务日志在主备数据库之间传输的时间长短,如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上,那么很显然,从备库中读取的数据将是旧的,因此就出现了数据不一致的情况。当然,无论是采用多次重试还是人为数据订正,关系型数据库还是能够保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。

总的来说,BASE 理论面向的是大型高可用可扩展的分布式系统,和传统事务的 ACID特性是相反的,它完全不同于 ACID 的強一致性模型,而是提出通过牺牲強一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态。

4. CAP 定理

2000年7月,来自加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC(Principlesof Distributed Computing)会议上,首次提出了著名的 CAP 猜想。2年后,来自麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了Brewer 教授 CAP 猜想的可行性,从此,CAP 理论正式在学术上成为了分布式计算领域的公认定理,并深深地影响了分布式计算的发展。CAP 理论告诉我们,一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个基本需求,最多只能同时满足其中的两项。

4.1 一致性

CAP 理论中的一致性是指强一致性（ Strong Consistency ），它要求多节点组成的分布式系统，能像单节点一样运作，如果一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有的读操作都不能读到这个数据。在分布式系统中,如果能够做到针对一个数据项的更新操作执行成功后,所有的用户都可以读取到其最新的值,那么这样的系统就被认为具有強一致性。

4.2 可用性

可用性是指系统提供的服务必须一直处于可用的状态, 对于用户的每一个操作请求总是能够在有限的时间内返回结果。

这里我们重点看下“有限的时间内”和“返回结果”。

• 有限的时间内是指,对于用户的一个操作请求,系统必须能够在指定的时间(即响应时间)内返回对应的处理结果,如果超过了这个时间范围,那么系统就被认为是不可用的。另外,“有限的时间内”是一个在系统设计之初就设定好的系统运行指标,通常不同的系统之间会有很大的不同。比如说,对于一个在线搜索引擎来说,通常在 0.5 秒内需要给出用户搜索关键词对应的检索结果。以 Google 为例, 搜索“分布式”这一关键词, Google 能够在 0.3 秒左右的时间, 返回大约上千万条检索结果。而对于一个面向 HIVE 的海量数据查询平台来说,正常的一次数据检索时间可能在20 秒到 30 秒之间,而如果是一个时间跨度较大的数据内容查询,“有限的时间”有时候甚至会长达几分钟。从上面的例子中,我们可以看出,用户对于一个系统的请求响应时间的期望值不尽相同。但是,无论系统之间的差异有多大,唯一相同的一点就是对于用户请求,系统必须存在一个合理的响应时间,否则用户便会对系统感到失望。
• “返回结果”是可用性的另一个非常重要的指标,它要求系统在完成对用户请求的处理后, 返回一个正常的响应结果。正常的响应结果通常能够明确地反映出对请求的处理结果,即成功或失败,而不是一个让用户感到困惑的返回结果。让我们再来看看上面提到的在线搜索引擎的例子,如果用户输入指定的搜索关键词后,返回的结果是一个系统错误,通常类似于“OutOfMemoryError”或“System Has Crashed”等提示语,那么我们认为此时系统是不可用的。

4.3 分区容错性

分区指的是在整个分布式系统中，因为各种网络原因，系统被分隔成多个单独的部分，它不仅包含我们通常说的网络分区，也包含因为网络丢包导致的网络不通的情况。并且，这里说的因为网络丢包导致网络不通的情形，还包含节点宕机的场景，由于系统的其他机器不知道某个节点宕机了，只知道与宕机节点的网络是不通的，所以当节点宕机发生时，其他节点发往宕机节点的包也将丢失。

在现实的分布式系统中，我们面对的就是一个不可靠的网络和有一定概率宕机的设备，这两个因素都会导致分区出现，因此在分布式系统实现中，分区容错性 P 是一个必须项，而不是可选项。

在分布式系统中，如果我们的设计放弃分区容错性，就相当于我们认为节点之间的网络通信永远是好的，那么我们对节点之间的远程调用的结果，就不需要处理超时、网络地址不可达等网络层错误了。但是这样一来，看似是简化了系统设计，实际却忽视了超时等网络错误的情况。当它们出现后，系统的行为就是未定义的了，可能会出现崩溃，或者是脏数据的问题。

因此，对于分布式系统工程实践来说， CAP 理论更合适的描述是：在满足分区容错的前提下，没有算法能同时满足数据一致性和服务可用性。

CAP 理论论证模型的关键点：数据一致性（ C ）指的是数据的强一致性，服务的可用性（ A ）指的是服务100 % 的可用性。。

5. CAP 理论产生的影响

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

当我们要求分布式系统具有严格一致性时,很可能就需要牺牲掉系统的可用性。但毋庸置疑的一点是,可用性又是一个所有消费者不允许我们讨价还价的系统属性,比如说像淘宝网这样的在线购物网站,就要求它能够 7×24 小时不间断地对外提供服务,而对于一致性,则更加是所有消费者对于一个软件系统的刚需。因此,在可用性和一致性之间永远无法存在一个两全其美的方案,于是如何构建一个兼顾可用性和一致性的分布式系统成为了无数工程师探讨的难题。

关于数据一致性和可用性之间的争论由来已久，主要表现为 ACID 与 BASE 之间的争论。

• 基于 BASE 理论支撑的 NoSQL 坚持创造各种可用性优先、数据一致性其次的方案，
• 传统数据库则坚守 ACID 特性（原子性、一致性、隔离性、持久性），优先数据一致性，在必要的时候，可以放弃系统可用性。

CAP 理论的出现，让人们能够在分布式系统中，放弃以关系数据库为代表的 ACID 强一致性系统，接受以 NoSQL 为代表的 BASE 理论。

5.1 对可用性的思考与理解

CAP 理论论证模型的关键点：数据一致性（ C ）指的是数据的强一致性，服务的可用性（ A ）指的是服务100 % 的可用性。。

在我们的日常工作中，几乎没有见过 100% 可用的服务。如果我们的服务能实现 99.9999% 的可用性，哪怕它不符合 CAP 理论的可用性，也是符合我们工作中对可用性的要求的。

所以，在我们的系统选择了 CP 模型的时候，对于可用性（ A ），我们永远无法达到 100%，但是按业务要求不断优化，是我们努力的目标。

5.2 对一致性的思考与理解

对于数据的一致性（ C ） ，除了 CAP 理论要求的强一致性外，还有单调一致性、会话一致性和最终一致性等。如果我们的系统设计选择了 AP 模型，在数据一致性方面，虽然我们无法实现强一致性，但是我们也不要全部放弃，可以去实现次高的一致性级别，为系统的服务提供更好的抽象。

这里我们通过一个例子来说明，假设我们设计一个 AP 模型的分布式系统，正常情况下，如果依据 CAP 理论，在系统设计时，我们需要放弃数据的一致性。但是，我们可以从另一个思路来设计，在系统没有出现网络分区的时候，这个分布式系统应该设计为强一致性的。

如果出现网络分区了，我们可以根据系统情况，有选择并且精心设计地降低系统的一致性级别。比如，从强一致性降低到单调一致性或会话一致性等，这样的设计，既符合 CAP 理论依据，也为系统提供了更好的一致性级别，特别是在网络分区的时候。

5.3 对分区容错性的思考与理解

在分布式系统中，节点之间必须通过网络来通信，可是网络可能会丢包和中断，节点也可能会宕机，这样的情况就要求我们在系统设计的时候，必须做好系统的分区容错处理。

但是，系统出现分区的情况非常少见，所以我们可以来试想一下，在网络不出现分区的时候，我们将数据强一致性和 100% 的可用性都选择，等到网络出现分区的时候，系统再选择放弃部分的可用性或者降低数据一致性的级别，这种处理方式是否可行呢？

其实这样的处理方式是可以的，在上面对可用性和一致性的重新思考与理解中，所举的例子都是按这个方式来处理的，它实际是将 CAP 理论的选择，推迟到出现网络分区的时候，而不是系统一启动就进行 CAP 的选择。这样可以大大提高系统的可用性和数据一致性，并且系统依然能容忍网络分区。

另外，关于 CAP 理论的重新思考，特别需要说明的一个例子是 Google 的 Spanner ，我们都知道 Spanner 是一个全球分布式数据库，但是 Google 却宣称 Spanner 是一个 CA 系统，这是不是和 CAP 理论的说法产生了矛盾呢？

其实并不矛盾，Spanner 虽然是一个分布式系统，但是它运行在 Google 的内部网络中，并且拥有大量冗余的网络链路、处理相关故障的架构规划、以及非常细致的运维，以此来确保系统的可用性超过了 99.999%。虽然不能达到 100%，但是对于使用者来说，和可用性 100% 几乎没有任何区别，所以Spanner 就是一个 CA 系统。

而且，在网络出现分区的时候，Spanner 会选择一致性而不是可用性，这个时候 CAP 理论依然会生效。所以对于 CAP 理论的重新思考，

总而言之就是一句话：CAP 理论给我们定义了系统的设计边界，虽然想要设计出超过边界的系统是徒劳的，但是我们却可以无限逼近边界，并且把它作为我们设计系统的目标。