1.2　分布式理论

分布式系统是建立在网络之上的软件系统。正是因为分布式系统是由软件在硬件基础上构建的，且具有软件特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多地表现在高层软件（特别是操作系统）方面，而不是硬件方面[1]。

分布式系统需要解决的一个核心问题是，观察数据时如何保障一致性的问题，此类问题即分布式一致性问题。而分布式一致性存在多种情况，这些情况统一由一致性模型（Consistency Model[2]）表示。常见的一致性有线性一致性、顺序一致性、因果一致性等。

而一致性模型包括的一致性，从强度的角度可以分为两种：一种是强一致性，另外一种是弱一致性（见参考文献[286]）。其中，线性一致性和顺序一致性属于强一致性，其他的属于弱一致性，但弱一致性相对又有强弱之分。

CAP理论提出，在分布式系统环境下，为了应对不可避免的网络分区事件的发生，常牺牲数据的一致性来换取服务可用性；或者为了保证数据的强一致性而牺牲可用性。

BASE[3]理论是牺牲了强一致性而采用了弱一致性中的最终一致性模型，目的是换取服务的持续可用。

CAP的作者在2012年[4]和2017年[5]提出C与A还是有机会在一定条件下共存的。CAP和BASE理论在分布式系统领域影响深远。分布式和事务型数据库结合，使得分布式数据库中的强一致性和事务一致性被再次重视。因为在数据库层提供强大的分布式一致性和事务一致性融合的服务，能够减轻应用层研发者的负担（减少或避免出现数据异常，即避免不一致性问题出现），不需要应用层研发者精通分布式一致性和事务一致性的全部语义，如此可极大简化应用研发的负担，提高工作效率。

下面将就上面谈及的具体内容进行详细讨论。

1.2.1　ACID、BASE与CAP简析

ACID是数据库事务处理的4个特性，本节不就其基本概念进行讨论，而是着重探讨ACID、BASE与CAP之间的关系。

BASE是一个弱一致性模型，Fox和Eric Brewer等在参考文献[13]中首次提出，目的是表达与ACID“相反”的语义，以帮助在不稳定的网络环境下构建分布式系统，容忍分区发生。

• Basically Available：基本可用，是指一个分布式系统在分区发生时，依然能对外提供部分服务。
• Soft state：软状态，是描述分布式系统健壮性的一个词语，其允许系统中的数据存在中间状态，而此中间状态不会影响系统的整体可用性，例如允许分布式系统在不同节点的数据副本之间进行数据同步的过程存在延时（即允许某些时刻数据存在不一致但要满足最终一致性）。
• Eventual consistency：最终一致性，描述系统中所有的数据副本在经过一段时间后，最终能够达到一个一致的状态，即不需要实时保证系统数据的强一致性。

如上三者使得一个分布式系统的多个组件之间协作不再强耦合，弱耦合会使系统成为一个异步系统，这样理论推导和工程实现会变得简单。

Eric Brewer在1997年发表的参考文献[13]和在2000年的PODC会议[8]上对ACID与BASE进行了对比，如图1-7所示。BASE相对于ACID，弱化了强一致性的要求，把可用性提到最高程度，这使得系统的设计更为简单；而缺少事务处理，则使得基于BASE的系统运行速度更快。

对于数据库事务处理的ACID特性，Eric Brewer有如下观点（见参考文献[5]）。

• 原子性（A）：原子性操作对任何系统都是有益的，在网络分区发生时，在考虑分区各侧可用性的时候，是需要保持各侧操作的原子性的。满足ACID定义的、高抽象层次的原子操作会简化分区恢复的处理复杂度。
• 一致性（C）：ACID中的C指的是不能破坏任何数据库的约束，如键的唯一性约束；也不能出现某个隔离级别不允许发生的数据异常。而CAP中的C仅指one-copy（效果类似作用在单副本上）上的分布式一致性和事务一致性，因此其与ACID的一致性有交集。但是，在旧的观念中，事务ACID的一致性不可能在分区过程中保持（跨分区的事务），因此分区恢复时需要重建ACID的一致性（比如使用异步方式同步数据）。另外，分区期间也许不能维持某些不变性约束，所以有必要仔细考虑哪些操作应该禁止，分区后又如何恢复这些不变性约束。
• 隔离性（I）：如果系统要求具备ACID中的隔离性，那么它在分区期间最多可以在分区一侧维持隔离性。跨分区的事务可串行性要求全局通信，因此这种隔离性在分区发生的情况下不能成立。在分区恢复时，通过补救办法可确保在分区发生之前和之后保持一个较弱的正确隔离性。
• 持久性（D）：尽管开发者有理由（持久性成本太高）选择BASE风格的软状态来避免实现持久性，但是放弃持久性没有意义，其道理和保持原子性一样。让分区两侧的事务都满足ACID特性会使得后续的分区恢复变得更容易，并且可为分区恢复时进行事务的补偿工作奠定基础。

BASE（上述内容并没有充分展示出BASE和ACID之间的本质差异）被用于构建大型高可用、可扩展的分布式系统，如NoSQL系统。在BASE理论的基础上，Eric Brewer进一步提出了CAP理论。

1.2.2　CAP分布式理论

1. CAP历史与发展

CAP理论，始于1997年，Eric Brewer等发表的参考文献[13]，其概念被周知于2000年，被证明于2002年。这一个时间段，正值互联网兴起，传统的关系型数据库理论提出的ACID已不能满足互联网业务发展对高可用性的需求，因此引发了人们对大型互联网业务系统应该具备什么属性的思考。因而由20世纪90年代之前已经成型的ACID的C出发，于20世纪90年代末发展出CAP的C，也就是说，ACID中的C是CAP中C的出发点，也是C概念的基本落脚点。

但是，CAP中的C在2002年被Seth Gilbert和Nancy Lynch定义为外部一致性（本书统一称为分布式一致性，见参考文献[211][6]）。因此，如何理解一致性成为重点。对CAP的3个特性的常规理解如下。

• 一致性：读一个数据项，应读取[7]到最新的值。参考文献[211]把C定义为基于原子数据对象的原子一致性，而此一致性表达的含义为“读操作未能立即读到此前最近一次写操作的结果，但多读几次还是获得了正确结果。所有对数据的修改操作都是原子的，不会产生竞态冲突[8]”。
• 可用性：每个系统访问的请求都收到成功或失败的响应。
• 分区容忍：系统中任意消息的丢失或传输失败，都不影响系统的继续运行。

这3个属性之间，分区是不可避免的，因此分区容忍是必须要满足的。一致性和可用性在分区事件存在的前提下只能二选一。图1-8是Eric Brewer在2000年的PODC会议上首次提出的CAP猜想图。

CAP理论的发展可分为如下3个阶段。

• 第一个阶段：CAP被提出。Eric Brewer在1998年发表文献[13]提出CAP[9]后，又于2000年在PODC会议上提出了CAP假定，称为Brewer猜想（见参考文献[8]）。这个猜想提出分布式系统的3个属性——一致性、可用性、分区容忍，合称CAP。
• 第二个阶段：CAP被证明并被应用。Seth Gilbert和Nancy Lynch在2002年发表了对Brewer猜想的正式证明（见参考文献[211]），并给出了一个定理，Brewer猜想演变为CAP定理，又称布鲁尔定理。此后引发了分布式系统的架构需要遵守“三个属性只能选二个”的认知。这对分布式系统的构建产生了巨大影响，尤其是对NoSQL系统。互联网等行业基本遵照CAP理论，并且多数选择以AP方式构建Web Services等大型联机分布式系统。
• 第三个阶段：重新认识CAP。对于CAP，多方有着不同的意见，批评者指出CAP不是适用于所有分布式系统的理论，支持者则修正或更精准地重新描述了CAP的内容。

下面我们就来详细了解上述这三个阶段。

第一阶段，Eric Brewer提出了分布式环境下的三个系统属性。

在CAP这个猜想中，Eric Brewer针对C指出，其指的是单拷贝（one-copy）情况（是逻辑上唯一的一份数据），其实质讨论的是“单逻辑写操作发生后，读操作是不是因为分区事件发生而不能读到数据”。如图1-9所示，左侧是不能容忍分区发生的情况（即无分区事件发生），其典型案例是单节点（单逻辑节点）的数据库不能容忍分区情况发生；右侧是容忍分区发生时（即有分区事件发生），舍弃可用性的情况，其典型案例是分布式数据库。对于分布式数据库，CAP中的C不仅是数据库系统中事务特性ACID中的C，还是分布式数据库中每份数据需要保证跨节点的写事务在成功之后读操作能满足一致性，而节点的写事务在失败之后读操作能读取写事务在之前的最新数据，从而确保满足一致性。

尽管Eric Brewer认为分布式系统中C、A、P这3个属性只能确保其中的2个，但是他认为，相比于可用性，数据库的一致性更重要。可惜这个观点被后人忽略了。

另外，Eric Brewer限定了CAP强一致性、高可用性、分区复原的范围。

• 强一致性：在个单拷贝（不是多个副本中的单个副本）上具有ACID语义的一致性。这是一个逻辑上的概念（系统实现时为确保高可用，每一份数据会有多个副本，这导致保证强一致性更为复杂）。强一致性适用于有更新操作的应用。
• 高可用性：高可用性可通过数据冗余提供，例如多副本的数据复制。如果某个给定的数据总是能有一定个数的副本存活且能提供服务，则说明该数据服务具有高可用性[10]。
• 分区复原：分区发生后复原，整个系统可以在多数据副本之间恢复数据。

然后，Eric Brewer又提出强CAP理论，并对选CA舍弃P的情况采用分布式事务语义进行举例，这意味着没有分区发生则一致性和可用性都可以得到保证。选CP舍弃A，则一些分布式事务操作应被阻塞直至分区复原，这样一致性可以保证但可用性丢失。选AP舍弃C，适用于HTTP Web缓存类应用。

所以，在1999年、2000年时，Eric Brewer认为CAP是适用于分布式数据库的。

第二阶段，CAP理论被证明。

对于一个异步网络模型，Seth Gilbert和Nancy Lynch采用反证法证明了CAP定理1（见参考文献[211]）。这个定理表明分区事件发生，可用性和一致性不能兼得。

CAP定理1：在一个异步网络模型中，所有的配对操作执行时（包括消息丢失），读写一个数据对象要想同时确保可用性、原子一致性是不可能的。

对于一个部分同步网络模型，Seth Gilbert和Nancy Lynch证明了CAP定理2（见参考文献[211]）。这个定理表明分区事件发生，可用性和一致性不能兼得。

CAP定理2：在一个局部网络模型中，所有的配对操作执行时（包括消息丢失），读写一个数据对象要想同时确保可用性、原子一致性是不可能的。

在参考文献[211]中，一致性被定义为atomic/linearizable consistency[11]（原子/线性一致性）。这和ACID中的C有所不同。这就引发一个问题：在分布式数据库中，一致性应该如何定义？

分布式系统由多个物理节点和节点间的网络组成，每一个部分在无故障的情况下可正常工作，系统的可用性和一致性都能被保证。

但是因为出现一些故障，如节点故障、网络故障，所以使得有些节点之间不再连通。当整个网络分成几块区域（分区）时，数据就有可能散布在那些不连通的区域中。若一个数据项只在一个节点中保存，当分区出现后，则节点不连通或此节点故障，就会引发访问不到这个节点上的数据的问题，这种分区就属于不可容忍的分区。而提高分区容忍性的办法之一是，一个数据项提供多个副本[12]，在发生分区后（单副本故障或单副本的网络故障），系统中尚有其他副本可读，从而使分区容忍性得到提高。但是，多副本之间要同步数据，就会为分布式系统中的数据一致性问题带来更大挑战（对于外部一致性来说，还需要考虑副本间数据同步的问题）。

为了保证数据的一致性，每个写操作都需要写全部节点成功，整个写操作才算成功，只有通过这种强同步的方式才能保证写操作写入的数据具有一致性，以及之后读操作读到的数据具有一致性。

同步数据的方式会让等待现象发生，而等待又会带来可用性的问题（时延）。为了提高性能，数据同步的过程应被优化，如采用分布式一致性协议Paxos或异步式主备复制技术等。

总之因为分区，我们不得不容忍多副本的情况发生。数据的副本节点越多，分区容忍度越高，但需要同步的数据就越多，保证数据一致性的难度就越大。为了保证数据一致性，有相同副本的节点间同步数据需要的时间就越长，可用性自然越低。

第三阶段，对CAP提出质疑。

对CAP的质疑主要包括如下几点。

• CAP没有界定适用的范围，适用情景显得模糊混乱，如分区容错概念就容易产生误导。
• 不适用于数据库事务架构（非NoSQL系统）。
• 应该构建不可变模型，避免CAP的复杂性。

典型的质疑是，Michael Stonebraker在2010年发表的参考文献[9][13]，他指出CAP不适合用于分布式数据库系统。Stonebraker认为，不只是CAP理论提及的多节点会因网络分区造成错误，在数据库中还有很多因素会造成错误，比如如下这几个。

• 应用程序错误：应用程序执行一个或多个不正确的更新。对于这样的错误，数据库必须有良好的备份恢复机制，以允许数据库在任何点上做恢复。
• 可重复的DBMS（数据库管理系统）错误：DBMS在处理节点上崩溃。用副本在处理节点上执行相同的事务将导致备份崩溃。
• 不可重复的DBMS错误：DBMS崩溃了，但副本很可能没问题。
• 操作系统错误：操作系统在一个节点上崩溃，如某操作系统经常出现的著名的“蓝屏”现象。
• 本地集群中的硬件故障：包括内存故障、磁盘故障等。
• 本地集群中的网络分区：局域网失败，节点不能互相通信。CAP系统中的P包含这个错误。
• 灾难：本地群集被洪水、地震等毁灭，群集不再存在。
• 将集群连接在一起的WAN中的网络故障：WAN有故障，集群不能互相通信。

在这些错误中，应用程序错误和可重复的DBMS错误一旦发生，一定不能保障系统的可用性，多副本的复制技术无助于解决问题。灾难发生，一个集群中的所有硬件、数据等都会遭到破坏，也就不能具备可用性。即CAP理论不能用于指导解决这些问题。

Stonebraker还认为，在局域网环境下网络是可靠的，分布式数据库系统应该选择CA，这样其实就是CAP都可满足。在WAN中有足够的冗余设计，分区事件是非常少见的，而一旦发生分区，则可以选择多数节点中的部分可用节点继续提供服务，用算法实现此点是容易做到的，所以此种情况下放弃一致性是不明智的。综上，他认为CAP理论是存在问题的。

2. 对CAP的新认知

2012年，Eric Brewer对CAP的传统认知（见参考文献[5]）包括可能会被误解或误用的“三个属性只能选二个”的概念，以及CAP的C与事务特性ACID的C之间存在不同定义等进行了澄清。他认为，实际上只有“在分区存在的前提下呈现完美的数据一致性和可用性”这种很少见的情况是CAP理论不允许出现的。他还认为，软件设计者仍然需要在分区的前提下对数据一致性和可用性做取舍，但具体如何处理分区和恢复一致性，有着许多的变通方案。新的设计应该考虑如何规划分区期间的操作和分区之后的恢复，这样有助于设计人员加深对CAP的认识，突破过去由于CAP理论的表述（不当或至少是不甚清晰）而产生的误解。而对于CAP中的C，Eric Brewer认可了外部一致性的表述（所有节点访问同一份最新的数据副本）。

但是，Eric Brewer依旧认为，CAP的正确性没有发生变化，其适用的场景依然存在。Eric Brewer从CAP和网络延迟的关系出发，讨论了如下问题。

• 系统需要在某段时间内识别出分区是否发生。分区的节点进入分区模式是优化C和A的核心环节。
• 分区发生后，分区的每一侧是否在没有通信的情况下继续可用？现实场景如Yahoo！的PNUTS系统在分区发生时，通过放弃强一致性来避免因保持数据一致性而带来的高延时（以异步的方式维护远程副本，这会带来数据一致性的问题）是有现实意义的。

之后Eric Brewer指出，即使是实现强一致的分布式数据库系统，在单一数据中心内出现分区的概率也极小，但毕竟还是存在的，所以分布式数据库系统还是需要考虑如何在C和A之间进行取舍。放弃一致性的代价较大，其核心是“并发更新问题”，在系统中可能会有较多的不变性约束。如果选择了可用性，需要在分区结束后恢复被破坏的不变性约束，这就要求必须将各种不变性约束一一列举出来，这样的工作挑战性大且容易犯错，所以考虑如何实现“分区后的恢复”以解决“分区两侧的状态最终必须保持一致，且必须补偿分区期间产生的错误”是必要的（这就回到了BASE中提及的最终一致性上）。

Seth Gilbert和Nancy Lynch在2012年所写的论文（见参考文献[12]）中再次论述了CAP理论。首先，论文中讨论了衡量理论价值的3个指标。

• 安全性：若一个算法能确保有更糟糕的事情发生时尚能应对，则可认为此算法是安全的。一致性（外部一致性）就是一个保证安全性的属性。
• 存活性：若不管有什么事情发生，一个系统一直都具备一定的存活能力，则可认为该系统具有存活性。分布式系统的可用性就是一个保证存活性的属性。
• 不可靠性：很多因素会造成系统的不稳定、不可靠，诸如网络分区、操作系统宕机、数据库系统宕机、消息丢失、恶意攻击等。

论文认为，从上述这3个抽象的衡量指标看，CAP提出的“三个属性只能选二个”的概念是合适的。

其次，论文讨论了一致性所依赖的服务场景，共包括如下4种。

• 琐碎的服务（trivial services，本书称之为无协调的服务）：有些服务是微不足道的，因为它们不需要服务器之间相互通信以协调达成一致。例如，如果服务返回π小数点后100位的值，这是不需要服务器之间进行协调的。无协调类的服务不在CAP定理的范围内。
• 弱一致性服务（weakly consistent services）：天然适合CAP的场景，如分布式Web缓存就是一个典型例子。
• 简单服务（simple services）：此类服务具有顺序发生的语义，所以用集中的服务器维护某个状态时，每个请求会按顺序处理，状态更新后对应的读响应也会具有顺序特性（写后立即读能读到最新写入的结果值）。简单服务适合CAP的场景。此类服务是原子性的，从客户的视角看，这就好像所有的操作均由一个集中的服务器执行。弱一致性（如会话一致性、因果一致性等）归属于此类服务。
• 复杂服务（complicated services）：具有复杂语义，其特征是非顺序化、需要有多样的交互和协调，如数据库的事务语义，CAP不关注这些情况。

论文中给出了新的CAP定义：In a network subject to communication failures, it is impossible for any web service to implement an atomic read/write shared memory that guarantees a response to every request.（在通信失败的网络中，任何Web服务都不可能通过实现原子读/写共享内存来保证对每个请求的响应。）

此定义缩小了CAP的适用范围，并且表明：在受通信故障影响的网络中，任何Web服务都不可能保证每个请求响应的原子读/写共享内存。这个定义把分布式数据库排除在外[14]。但是，分布式数据库的架构设计依然需要考虑分区发生时如何应对以确保一致性（分布式一致性和事务一致性）。

3. CAP过时论

Martin Kleppmann在2015年撰文[15]对CAP进行了较为深入、细致的分析，对一些概念进行了比较，甚至对Eric Brewer和Seth Gilbert、Nancy Lynch论述的内容的差异进行了比较，指出现有的分布式系统的研究基本上是集中在20世纪90年代，过时已久[16]。他还建议将CAP归入历史，不应再用于指导分布式系统的设计。而分布式系统的设计和时延/延迟有关，可以证明的是：在不使操作延迟与网络延迟成比例的情况下，某些级别的一致性是不可能实现的。

Martin Kleppmann认为，对于分布式系统来说未来可研究的热点是：

• 对不同并发控制和复制算法的延迟的概率分布建模；
• 对更明确的分布式算法的网络通信拓扑建模。

Martin Kleppmann期望更严格地讨论不同的一致性层次对性能和容错性的影响；期望通过采用简单、正确和直观的术语，指导应用程序开发人员使用最适合场景的（存储）技术[17]。

1.2.3　PACELC理论和CAP新进展

在WAN环境中，网络的不可靠性大，同时满足CA是小概率事件。在现代可靠的局域网环境中，分区事件是较少发生的，因此分布式系统满足CA是一个大概率事件。在这种条件下，更多值得讨论的不再是分区事件发生后如何，而是在分区事件没有发生的情况下，操作从开始到得到结果，中间过程的时延问题，即延迟。而在假定某一定量的时延是不允许的情况下，分区事件可被时延问题替代。

Daniel J. Abadi针对分布式数据库在参考文献[15]和参考文献[16]中提出用PACELC替代CAP。PACELC的含义是：

• 如果发生分区事件（P），那么如何在可用性（A）和一致性（C）间选择？
• 否则（Else），即不发生分区事件，如何在延迟（L）和一致性（C）间选择？

PACELC理论实质讨论了两种情况：第一种情况讨论了CAP理论，第二种情况讨论了无分区发生时因延迟带来的新挑战。但如果延迟的时间较长，延迟的现象类似于分区发生，处理延迟所面临的问题可能同样困难。

Daniel J. Abadi尽管提出了PACELC理论，但没有给出适宜的解决办法[18]，也没有明确给出一致性的定义，没有分析一致性、可用性之间的关系。其理论的价值在于“全面”地提出了分布式数据库所面临的问题，这些问题需要更深入地细化和讨论。

2017年Eric Brewer发表论文Spanner，Truetime and the CAP Theorem，其结合同时实现了一致性和可用性的Spanner系统再一次讨论了CAP，指出：CAP定理关注的是100%可用性，而该论文讨论的是现实高可用性涉及的权衡问题（高可用但不是100%可用，分区依旧可能发生）。尽管有着很高的可用性（大于5个9的可用性，但是一旦分区事件发生，Spanner依旧遵循CAP理论选择了C放弃了A。

所以，从工程实践的角度看，实现尽可能高的可用性是分布式系统的目标，但在一致性和可用性选取上因系统而异。分布式数据库系统，通常会选择C而放弃100%的可用性，但分布式数据库系统的研发者则需要100%处理分区事件以提高系统的健壮性。

所以，目前的研究结果表明：CAP/PACELC理论依旧适用于分布式数据库系统。

---

[1]关于分布式系统的更多信息可参考：https://baike.baidu.com/item/分布式系统/4905336?fr=aladdin。

[2]关于一致性模型的更多信息可参考：https://en.wikipedia.org/wiki/Consistency_model。

[3]BASE即基本可用（Basically Available, BA）、软状态（Soft state, S）、最终一致性（Eventual consistency, E）。

[4]参见CAP Twelve Years Later: How the Rules Have Changed。

[5]参见Spanner, Truetime and the CAP Theorem。

[6]参考文献[211]中的描述：Discussing atomic consistency is somewhat different than talking about an ACID database, as database consistency refers to transactions, while atomic consistency refers only to a property of a single request/response operation sequence. And it has a different meaning than the Atomic in ACID, as it subsumes the database notions of both Atomic and Consistent.

[7]CAP中的C是从“读取”数据的角度出发来讨论一致性的。这种一致性在本书第2章中被定义为次序一致性。但是对于分布式事务型数据库而言，因需要支持事务，这种一致性进一步升华为分布式事务一致性和分布式一致性的融合，此融合在本书称为严格可串行化。在参考文献[29]中，严格可串行化又被称为strong (or strict) one-copy serializability，在参考文献[65]中被称为外部一致性（external consistency）。请注意，该一致性融合了线性一致性（参见2.3.1节的讨论）和可串行化。

[8]更多信息可参考：https://zh.wikipedia.org/wiki/中的内存一致性模型内容。

[9]Eric Brewer是基于Web Services类系统提出CAP假定的，但作者在提出CAP之时就思考、对比过其假定与数据库系统的不同之处。因此Eric Brewer是考虑过CAP对数据库系统的影响的，但是由于研究范围有限，尤其是没有深入研究分布式数据库系统的事务处理子系统，因此CAP提出之际没有深入、全面地论述其对数据库的影响。

[10]注意，这是在同一数据层面上提供的可用性，而同一数据被维护在不同的节点上，所以可称之为节点可用性。但如果同一份数据的所有副本都发生故障或者发生分区事件，则其会彻底丧失高可用性。而同一份数据的部分副本/节点发生故障或者发生分区事件，则可维持一定的可用性（但需要考虑发生故障的副本/节点数目的占比）。

[11]原文：There must exist a total order on all operations such that each operation looks as if it were completed at a single instant. This is equivalent to requiring requests of the distributed shared memory to act as if they were executing on a single node, responding to operations one at a time.

[12]需要注意，对于CAP中的C，Eric Brewer的本意是单拷贝一致性而不是单副本下的一致性。其在参考文献[5]中给出的原文是：the C in CAP refers only to single‐copy consistency。

[13]参见https://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database-systems-eventual-consistecon-and-the-cap-theorem/fulltext?mobile=false。

[14]注意：不意味着CAP不适用于分布式数据库。

[15]参见Martin Kleppmann的A Critique of the CAP Theorem (CoRR abs/1509.05393, 2015)。

[16]原文：We have not proved any new results in this paper, but merely drawn on existing distributed systems research dating mostly from the 1990s (and thus predating CAP).

[17]原文的描述是the storage technologies。但在分布式系统中，只是单纯地理解为讨论的是数据的存储，这有些狭隘了，理解为“提供存储和计算的分布式系统”更为妥当。

[18]原文：The tradeoffs involved in building distributed database systems are complex, and neither CAP nor PACELC can explain them all. Nonetheless, incorporating the consistency/latency tradeoff into modern DDBS design considerations is important enough to warrant bringing the tradeoff closer to the forefront of architectural discussions.