令人迷惑的CAP与ACID用语
CAP和ACID共享相同的词汇表：原子性（Atomic）、一致性（Consistent），诸如此类。但内有玄机：这些词语虽一样，但它们的意思是完全不同的东西。CAP来自分布式系统理论，而ACID属于数据库系统。分布式数据库既使用CAP词汇，也使用ACID词汇，这显然造成许多混淆。当某人讲：“我们不能放弃一致性”，他谈到的一致性是什么？让我们来看一看【Atomic-Consistent-Isolated-Durable】和【Consistent-Available-Partition-tolerant】的定义。
ACID & CAP - 一个提醒
ACID属性在70年代被确定，然后术语ACID被创造于1983年：
· A for Atomicity ： 原子性
· C for Consistency ： 一致性
· I for for Isolation ： 隔离性
· D for Durability ： 持久性
提醒：ACID特性定义于70年代的加利福尼亚
CAP由Eric Brewer猜想于2000年，由Seth Gilbert和Nancy Lynch证明于2002年：
· C for Consistency ： 一致性
· A for Availability ：可用性
· P for Partition-tolerance. ：分区容错性
?
CAP and ACID 用语 - 迷惑概括
首先，让我们看下全画面
|
词语 |
数据库 |
CAP |
迷惑? |
|
事务 |
一组操作 |
不使用这个词语和概念 |
否 |
|
持久化 |
“一旦事务成功，其对状态的更改，即使系统出现故障也不受影响” [D2] |
不使用这个词语和概念 |
否 |
|
一致性 |
数据完整性约束 (数据类型, 关系, …) |
对于CAP，一致性是“原子一致性”的简称。原子一致性是个一致性模型，稍后详述 |
同一个词 不同概念 |
|
隔离性 |
“尽管多个事务并发执行，但看上去好象，对于每个事务T，其它事务要么在T之前、要么在T之后执行”. [D2] |
CAP不使用这个词语，但ACID定义的隔离性在CAP词汇中是个一致性模型 |
不同的词 相同概念 |
|
原子性 |
所有更改要么发生，要么全部不发生 |
对于CAP，原子性是个一致性模型，在CAP证明中被使用 |
同一个词 不同概念 |
|
可用性 |
概念不经常使用，如果有，定义可能不同于CAP中的，即可用性也许不要求所有的非故障节点都响应 |
“被系统中非故障节点接收到的每个请求必须产生一个响应” [C2] |
同一个词 相同概念 不同定义 |
|
分区容错性 |
概念不经常使用，如果有，定义与CAP中一致 |
两组节点被分区时，它们之间的所有消息都将丢失 |
否 |
现在，让我们深入一些细节：我们将发现，有一些额外的迷惑源自分布式数据库。
事务(只存在于ACID)
一个事务是一组操作。这组操作的任何一个可以读写多个数据。ACID是给予这组操作相同的属性，就好像它是一个唯一的操作。这不是CAP的目标。CAP是关于多个操作使用相同数据的（可能的）属性，这个属性可能是复制。
持久化(只存在于ACID)
“一旦事务成功，其对状态的更改，即使系统出现故障也不受影响”意思很清楚的，但把故障描述留给物理部署处理。主要取决于冗余：单节点多磁盘 及/或 多节点 及/或 多中心。 “幸免于”并不暗示任何可用性的概念： 它的意思是它至少可以稍后恢复数据。
CAP本身没有提及持久化。CAP中的持久化是隐式的：CAP是有关分区，而不是节点故障。
CAP中的可用性
在CAP中，可用性意味着，若系统被分区，所有的非故障节点继续服务于请求。许多分布式系统认为它们是具有可用性的，这些系统当出现分区时，一部分非故障节点继续服务于请求。这样的系统并非具有CAP中的可用性。
CAP中的一致性与CAP中的原子性
CAP中的一致性是原子一致性的简称。原子一致性是一个一致性模型。一致性模型描述系统中各操作以什么样的顺序执行。有哪些操作因系统而异，例如，若要定义一个事务处理系统的一致性模型，那么“commit”就应是操作之一。用于证明CAP理论的分布式共享内存模型（Lynch定义于[V6]），使用的操作有read、write、ack。
选择一个一致性模型远不那么简单。有很多的一致性模型，因为存在许多可能的权衡：
· 一致性模型易用性如何。这也取决于应用本身：某些一致性模型可能对一些应用是易用的，而对其它应用就不易用。
· 内存模型的实现是否高效。这也取决于硬件和物理部署。
用于ACID与CAP的一致性模型其实是简单的：
· 顺序一致性，由Lamport定义[V9]：“程序的行为好像是，所有处理器的内存访问是交叉的，然而是按顺序执行的。”
· 原子一致性（也被称为线性一致性）是顺序一致性加上实时约束：“与顺序一致性不同，线性一致性假设在所有处理器之间存在全局时间的概念。各操作被间隔所建模，间隔是由调用和响应之间一段时间组成，每个操作假定是在间隔内的某点瞬间生效。”[V7]
一致性“是原子一致性：它只是个简称。CAP中的原子性（操作顺序执行）与ACID中的原子性（全部完成或什么都不做）根本就不是一件事。
ACID中的一致性
ACID中的一致性与数据完整性相关。例如：通常可能在SQL数据库中实现这样的规则：
· 字段不能为空值
· 字段必须是数字型
· 字段是对另外一张表中字段的引用
数据库不允许提交违反约束的事务。这就是ACID中的一致性约束。定义与CAP的不相同。
重要的是要记住，一个数据库（SQL或非SQL），并未实现所有的一致性约束。
ACID中的原子性
?"全部完成-或者-什么都没有”的行为十分直观：例如，有这样个事务，用伪代码模拟两账号间转账：
|
begin val1 = read(account1) val2 = read(account2) newVal1 = val1 - 100 newVal2 = val2 + 100 write(account1, newVal1) write(account2, newVal2) commit |
原子性是说两账号都被更新或者没有一个被更新。如果写入账号1成功，然后写入账号2失败，这两个写入操作将被回滚。
然而，ACID中的原子性并不说明这个事务隔离于其他事务。换句话讲，你可以宣称自己达成ACID中的原子性，甚至当：
· 在事务提交前，写入的值能被其它事务所见。
· 读到的值可能是被其它事务正修改的。若多次读取同一个值，可能会得到不同的结果。
例如，使用上面提到的事务，你能预期很多SQL数据库的行为：
· 开始，账户1有1000，账户2是0
· 同时并行两笔转账（如上面代码）
· 当你预期账户1是800、账户2是200时，你却从账户1上看到是900。
这是因为在ACID中，原子性不同于隔离性：原子性/全部完成-或-什么都不做，不代表是被隔离的。
Isolation隔离性
Gray和Reuter在[D2]中给出的隔离性定义是：“虽然多个事务并发执行，但看上去好象：对于每个事务T，其它事务是在T之前或在T之后执行”。这定义了一个一致性模型，就如CAP的一致性。有了这个定义，任何事务都是完全隔离的。很容易理解与使用。
理论上的隔离性：由于可序列化属性，开发人员什么都不用做
然而，这是难以高效实现的，所以各数据库已经放松了限制。做为结果，数据库中的隔离性带有几个程度，即“可序列化（serializable）”, “可重复读（repeatable read）”, “读取已提交数据（read committed）”和“读取未提交数据（read uncommitted）”。
经常被默认使用的是“读取已提交数据”：一个事务只看到已经被（其它事务）提交的数据。
虽然看起来简单，但有几点隐情：
1. 正如Hellerstein、Stonebraker和Hamilton所说[D1] : “全以微妙的方式依赖于一个假设：有一个用于并发控制的锁机制，而不是一个乐观锁或多版本并发机制。这意味着提出的语义是不明确的。”
2. 对于一个给定的隔离度，所有的数据库不一定有相同的行为。这点由Martin Kleppmann解释于[D4]。
3. 隔离性不仅影响功能正确性，也影响技术正确性： 大多数据库在后台使用锁。并发执行时可能会产生死锁：独立事务间意料之外的或者不受控的依赖产生一种情况，所有事务均需其它事务释放占用的资源。 在这种情况下，其中一个事务会被数据库引擎终止并且失败， 即使这个事务其功能与语法都是正确的。
数据库用户需要了解的远远超过数据库一致性模型：他们需要了解他们所用数据库的引擎实际上如何实现它。
让我们再看下上面的那个例子。如果在“读已经提交数据”（通常是默认的）数据库上运行，我们可能会得到一个不正确的结果。我们实际上可能生成钱（多出钱来）。可通过显式锁定数据来修正，伪代码如下：
|
begin val1 = readAndLock(account1) val2 = readAndLock(account2) newVal1 = val1 - 100 newVal2 = val2 + 100 write(account1, newVal1) write(account2, newVal2) commit // release all locks |
随之到来的复杂性，已经在并发编程语言中遇到过，比如：Java。数据库实际上增加了一个额外的复杂度，就是锁的范围可以扩大（页、表、......），并能被数据库引擎动态调整（升级）。此外，死锁或者性能要求可能导致某些使用“读取未提交数据”隔离度，它假定读取的都是不可变数据。这也许会引出复杂问题，如果系统运行时，有人在某个地方（比如：客户网站上的专业服务专家）修改了理论上的不可变数据。
我们看到CAP的‘C‘与ACID的‘I‘十分相似。但CAP是应用到模型的一个理论，而性能限制迫使数据库中添加多个级别的参数，并迫使数据库用户了解隔离度如何实际执行。
结论
四个字母缩写的ACID，其中有3个有着与CAP中不同的含义，难怪这是令人迷惑的。而且，迷惑不仅来自于用语上的重叠， 也来自于探究实现细节去理解现实中并发应用上的不同。在实践中，这是导致许多人（包括我）看“NoSQL”世界的难点之一。
参考
[C2] Gilbert and Lynch. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News (2002)
[C6] Michael Stonebraker, Clarifications on the CAP Theorem and Data-Related Errors, 2010
[D1] J. M. Hellerstein, M. Stonebraker, J. Hamilton, Architecture of a Database System, Foundations and Trends in Databases Vol. 1, No. 2 (2007) 141–259
[D2] J. Gray and A. Reuter, Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1993.
[D4] M. Kleppmann, “Hermitage: Testing the “I” in ACID”, blog post, 2014
[V6] Nancy Lynch, Distributed Algorithms, Morgan Kaufmann, 1996
[V7] Kourosh Gharachorloo, “Memory Consistency Models for Shared-Memory Multiprocessors,” Stanford Technical Report, 1995
[V8] M. Herlihy, J. Wing “Linearizability: A Correctness Condition for Concurrent Objects”, ACM, 1990
[V9]Leslie Lamport, "How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs", IEEE Trans. Comput. C-28,9 (Sept. 1979), 690-691.
原文链接： http://blog.thislongrun.com/2015/03/the-confusing-cap-and-acid-wording.html