谈到NoSQL，一定会提及一致性（Consistency），按照CAP定理，有些NoSQL数据库放弃了一致性，但是NoSQL放弃是必然的选择吗？

从1970’s，关系型数据库（RDB，Relational Database）被发明以来，关系型数据库就是构建应用的通常的选择。关系型数据库对用户提供ACID保证，非常方便开发者使用。从1990’s开始，NoSQL系统开始出现。NoSQL系统是一类对立于关系数据库的数据库系统，他们从架构上放弃了传统的关系型数据库的的关系模型和SQL的接口。

与NoSQL系统相伴而来的2个词是BASE和CAP，这2个词对分布式系统有着非常深远的影响。我相信就是在这2个词的影响下，很多NoSQL系统从架构的初始就放弃了一致性（consistency）选择了一种最终一致性（Eventual consistency）和可用性(Availability)。虽然我非常认同CAP和BASE这2个词，但是我不认为在CAP和BASE的作用下，NoSQL系统选择放弃一致性是一个必然的事情。

首先来回顾一下CAP和BASE这2个概念的历史。这2个概念都是由Eric Brewer提出的，Brewer目前是Google公司的基础设施部门（Infrastructure）的副总裁（VP，Vice President）。在1997年，在SOSP(Symposium on Operating Systems Principles)上，名为的演讲[1]总结了Brewer等人的近期工作，演讲中说他们正在工作的集群服务并没有采用当时公认的具有ACID特性的关系型数据库作为架构，而是在架构上放弃了关系型数据库的ACID特性。并且为他们的这个架构选择构造了一个新的词BASE，BASE这个词的选择有刻意为之成分，ACID在英语里有酸性的意思，而BASE有碱性的意思，很明显BASE是与?ACID对立的。

ACID和BASE分别是如下单词的首字母缩写：
ACID：Atomicity, Consistency, Isolation, Durability
BASE: Basically Available, Soft State, Eventual Consistency

BASE主张放弃掉ACID，主要是放弃ACID中的Consistency，并且让系统达到基本可用（Basically Available），柔性状态（Soft State），最终一致（Eventual Consistency）。系统构建者可以不仅仅选择ACID，BASE也称为一种选择，也就是在ACID和BASE中选择其一。本质上来讲，就是在ACID代表的一致性(Consistency)和BASE代表的可用性（Availability）二者之间做出选择。虽然在BASE提出时，还没有明确说明在一致性和可用性间做出架构选择，但是已经为后面CAP的提出做好了伏笔。

到2000年，Brewer在PODC（Principles of Distributed Computing）做了名为 [2]的演讲，演讲的主旨是阐明如何构建健壮的分布式系统。在这次演讲中，Brewer近一步分析比较了ACID和BASE，并且抽象了ACID和BASE的核心特性，也就是ACID的一致性（Consistency），BASE的可用性（Availability），并且扩展了第3个维度，也就是网络分区（Network Partition），从而提出了CAP猜想，这个猜想说：

在分布式系统中，最多能同时满足以下3个属性中的2个：
C （Consistency）, A （Availability）, P （Tolerance to network Partitions）

根据这个猜想，会存在3类系统：

放弃P，系统具有CA特性，这类系统诸如单机数据库
放弃A，系统具有CP特性，这类系统诸如分布式数据库、分布式锁
放弃C，系统具有AP特性，这类系统诸如web caching、DNS

可用性是非常重要的一个特性，特别是在互联网行业中，服务宕机对商业的影响是非常大的，所以依据CAP定理放弃一致性也就是自然的选择了。特别是在Amazon的CTO Werner Vogels详细介绍了Eventually Consistent[5]和Amazon的Dynamo系统的论文[12]发表后，大量追求可用性放弃一致性的NoSQL系统出现。

到了2002年，GilBert和Lynch[3]，重新定义了C\A\P这3个属性（重新定义的属性比Brewer猜想中的属性的范围小了很多），并且证明了CAP这3个属性不能同时达到，从而将CAP猜想变成了CAP定理。

CAP定理中的3个属性定义如下[3,6]：
Consistency: 是指原子一致性（Atomic consistency）或者线性一致性（linearizable consistency），这是一种非常高的一致性级别，很少有系统能够达到。
Availability:是指完全的可用性，也就是每个到达每个没有宕机的节点上的读写请求都能在一个合理的时间返回一个响应。这里的关键点是每个请求到达每个非宕机的节点。这也是一种非常高的可用性水平，也很少有系统能够达到。
Partition Tolerant: 是指系统能够在出现网络分区的情况下，继续正确响应，即保持系统该有的特性，或者说保持一致性或者可用性。

Glibert和Lynch重新定义的CAP定理非常严谨，但是只证明了3个属性不能同时具有。然而Brewer猜想中的3个属性的定义、3选2的描述，3分的分类法（AP,CP,CA3种分类）却不是非常严谨，这也是CAP出现之后，很多人怀疑和挑战CAP的原因。Brewer在2012年重新写了一篇文章[4]，也承认最初的CAP表述非常令人误解。事实上，CAP定理的适用范围是非常小的。虽然CAP从出生开始就有很多问题，但是它仍然推动了NoSQL运动，很多系统架构者依据CAP定理，主动放弃了一致性，但实际上，很多时候这些系统都是不满足CAP定理的适用范围的。

CAP的故事到此并未完结，2017年，Brewer已经是Google公司的基础设施（Infrastructure）部门的副总裁（VP，Vice President）了，并且这时Google公司的第一代Spanner系统已经诞生[9]。Brewer写了一篇文章讲述了Google公司的Spanner系统[7]，并且近一步阐述了按照CAP定理Spanner是一个什么样特性的系统。在文中，Brewer指出Spanner系统说是"实际上的CA"（effectively CA）系统。从架构上来讲，Spanner是一个CP系统，也就是说当出现网络分区时，Spanner选择的是保证数据的一致性，放弃可用性的。但实际上，Spanner是具有非常高可用性效果的一个系统，从架构上Spanner没有达到CAP定理要求的那种完全可用性，但是也达到非常高的可用性，由于采用多副本的设计，个别副本出现网络分区，并不影响用户能感知到的可用性。按CAP定理的定义，当这些个别副本出现网络分区时，这些节点是不可用的，也就是系统没有达到完全可用性。但是此时的用户请求是可以被其他副本服务的，此时服务是可用的，也就是说用户仍然感知到Spanner是可用的。所以说用户感知的可用性和CAP定理中的可用性不是一个概念。我们追求的应该是用户感知的可用性。

用户可感知的可用性，通常用SLA来表示，也就是我们通常说的几个9的可用性。Brewer在文章中也给出了Google关于Spanner系统的SLA的数据，从数据我们可以看到，由于网络分区导致的服务可用的比例是比较小的，有很大一部分导致服务不可用的原因是诸如软件bug、配置错误、运维误操作等导致的。也就是说，即便在架构上采用了达到CAP定理要求的可用性，实际用户可感受到的服务可用性，也就SLA也不会提高多少。这也是我从业这么多年的一个体会，系统的不稳定更多来自系统开发者的日常失误，加强代码质量，加强开发流程规范，加强生产运维规范，更能大大提高系统的可用性。所以，在架构层面，因为可用性放弃一致性往往是得不偿失的。

云计算的大潮下，不放弃一致性也是非常明智的。一个托管在云上的数据存储服务，如果你放弃了一致性选择可用性，用户是感受不明显，因为使用者不会对架构设计采用达到的CAP定理的可用性而买单，用户只会为你的服务达到SLA买单。然而数据存储服务是否具有一致性，用户是能够非常明显的感受到的。Amazon公司的内部的Dynamo[12]在架构上是可以达到CAP定理中的可用性要求的，但是Amazon在AWS云上售卖的DynamoDB并不是采用的这一架构，也许就是出于这个原因[10]。

那么我们选择一致性得到的好处是什么那？很多时候，说到一致性时，都会拿金融和钱相关的例子来说明一致性的必要性，但是我相信金融行业并不强依赖一致性[10]。我认为一致性给我带来的是开发的方便性。Brewer虽然提出了BASE概念，但是他并没有详细阐述这个概念。2008年EBay公司的Dan Pritchett，写了一遍文章[8]，通过举例详细阐述了在放弃了ACID以后，如何采用BASE架构实现相同的需求，向我们推荐了BASE这种架构模式。通过这篇文章，我们我可以看到如果放弃了ACID而选择BASE的话，本来一个非常简单的功能，需要加入消息队列等手段才能让系统达到最终一致性，应用的整体架构复杂了很多。

类似于Pritchett文章中说明的一样，使用不具有一致性的NoSQL系统，你需要仔细甄别你的使用场景，判断你的使用场景是否可以让你放弃一致性。即便你要使用BASE架构，也不是简单地采用一个具有最终一致性的NoSQL系统，替换掉ACID数据库就好了，你需要设计好各种手段，处理掉具有最终一致性的NoSQL系统带来的异常，让你的整个应用达到柔性状态和最终一致。BASE中所说的最终一致和很多NoSQL系统所具有的最终一致有些细微的差别。这个差别简单来说是，BASE中所说的最终一致是保证系统状态是正确的；而很多NoSQL系统最终一致只保证最终一致，但是不保证这个状态是你想要的正确的状态[11]。

最后，个人的一个观点是，如果一个NoSQL系统做为缓存使用，为了追求低延时，可以放弃一致性，大数据和离线计算的场景类似于这种场景，很多NoSQL系统是非常适用的；但是如果NoSQL系统作为数据库来用，那么这个NoSQL系统最好不要因为可用性放弃一致性，同时通过多副本技术和良好运维达到实际的高可用性，即达到实际上的CA（effectively CA），这样可以大大降低使用者的使用负担。

由于篇幅所限，本文中关于一致性、CAP、BASE、ACID的很多技术细节的阐述未能详尽，拟另行成文讨论。成文仓促，有错漏之处欢迎各位大神指正。

作者简介：陈东明，饿了么北京技术中心架构组负责人，负责饿了么的产品线架构设计以及饿了么基础架构研发工作。曾任百度架构师，负责百度即时通讯产品的架构设计。具有丰富的大规模系统构建和基础架构的研发经验，善于复杂业务需求下的大并发、分布式系统设计和持续优化。个人微信公众号dongming_cdm。

1.Cluster-Based Scalable Network Services, A. Fox et al., 1997.
2.Towards Robust Distributed Systems, E. Brewer, 2000.
3.Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services, Seth Gilbert, Nancy Lynch, 2002
4.CAP twelve years later: How the “rules” have changed, Eric Brewer, 2012
5.Eventually Consistent - Revisited, Werner Vogels, 2008
6.Understanding the CAP Theorem, Akhil Mehra, https://dzone.com/articles/understanding-the-cap-theorem
7.Spanner, TrueTime & The CAP Theorem, Eric Brewer, 2017,https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45855.pdf
8.Base: An Acid Alternative，Dan Pritchett, https://queue.acm.org/detail.cfm?id=1394128
9.Spanner: Google’s Globally-Distributed Database，2012
10.Designing Data-Intensive Applications, Martin Kleppmann
11.Jepsen: Cassandra，Kyle Kingsbury，https://aphyr.com/posts/294-jepsen-cassandra
12.Dynamo: Amazon’s Highly Available Key-value Store, Giuseppe DeCandia et al., 2007

创作场景

NoSQL 数据库不应该放弃 Consistency