令人迷惑的CAP与ACID用语

标签: 迷惑 cap acid | 发表时间:2015-04-17 22:17 | 作者:歪脖大肚子Q
出处:http://www.iteye.com

令人迷惑的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

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [迷惑 cap acid] 推荐:

令人迷惑的CAP与ACID用语

- - 数据库 - ITeye博客
令人迷惑的CAP与ACID用语. CAP和ACID共享相同的词汇表:原子性(Atomic)、一致性(Consistent),诸如此类. 但内有玄机:这些词语虽一样,但它们的意思是完全不同的东西. CAP来自分布式系统理论,而ACID属于数据库系统. 分布式数据库既使用CAP词汇,也使用ACID词汇,这显然造成许多混淆.

CAP 理论

- - 忘我的追寻
CAP理论被很多人拿来作为分布式系统设计的金律,然而感觉大家对CAP这三个属性的认识却存在不少误区. 从CAP的证明中可以看出来,这个理论的成立是需要很明确的对C、A、P三个概念进行界定的前提下的. 在本文中笔者希望可以对论文和一些参考资料进行总结并附带一些思考. CAP原本是一个猜想,2000年PODC大会的时候大牛Brewer提出的,他认为在设计一个大规模可扩放的网络服务时候会遇到三个特性:一致性(consistency)、可用性(Availability)、分区容错(partition-tolerance)都需要的情景,然而这是不可能都实现的.

事务ACID区别【转】

- - 数据库 - ITeye博客
转自:http://blog.sina.com.cn/s/blog_44c594a70101rsgj.html. 1,最容易困惑的是原子性和一致性,先谈这俩:. 原子性:事务的原子性指的是,事务中包含的程序作为数据库的逻辑工作单位,它所做的对数据修改操作要么全部执行,要么完全不执行. 一致性: 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态.

[译]如何“打败”CAP定理

- hikerlive - Fang Jian&#39;s Personal Blog
昨天看到了Nathan Marz这篇《How to beat the CAP theorem》觉得写得很有想法,所以决定把这篇文章翻译成中文,希望能够被更多的人看到,翻译可能不是很准确,如有错误之处欢迎指出. CAP定理指出一个数据库不可能同时满足:一致性(Consistency)、可用性(Availability)和分区容错性(Partition-Tolerance).

NOSQL数据模型和CAP原理

- - 数据库 - ITeye博客
我本来一直觉得NoSQL其实很容易理解的,我本身也已经对NoSQL有了非常深入的研究,但是在最近准备YunTable的Chart的时候,发现NoSQL不仅非常博大精深,而且我个人对NoSQL的理解也只是皮毛而已,但我还算是一个“知耻而后勇”的人,所以经过一段时间的学习之后,从本系列第六篇开始,就将和大家聊聊NoSQL,而本篇将主要给大家做一下NoSQL数据库的综述.

Base: 一种Acid的替代方案-转载

- - 人月神话的BLOG
原文: http://duanple.blog.163.com/blog/static/709717672011631101917811/. 本文是Ebay的架构师在2008年发表给ACM的文章,是一篇解释BASE原则,或者说最终一致性的经典文章. 文中Dan讨论了BASE与ACID原则的基本差异, 以及如何设计大型网站以满足不断增长的可伸缩性需求,期间如何对业务做调整与折衷.

谈正确理解 CAP 理论[转自网络]

- - 互联网 - ITeye博客
转载自:http://www.douban.com/group/topic/11765014/. CAP 理论在搞分布式的程序员中已经是路人皆知了. 但是 CAP 理论就好比是相对论,虽然所有的人都知道,但是却没有多少人真正理解. 要真正理解 CAP 理论必须要读懂它的形式化描述. 形式化描述中最重要的莫过于对 Consistency, Availability, Partition-tolerance 的准确定义.

分布式系统之CAP理论 - DM张朋飞

- - 博客园_首页
  任老师第一节主要讲了分布式系统实现时候面临的八个问题,布置的作业就是这个,查询CAP理论.   笔者初次接触分布式,所以本文主要是一个汇总.   CAP原本是一个猜想,2000年PODC大会的时候大牛Brewer提出的,他认为在设计一个大规模可扩放的网络服务时候会遇到三个特性:一致性(consistency)、可用性(Availability)、分区容错(partition-tolerance)都需要的情景,然而这是不可能都实现的.

hive 3.x 比hive2 性能提高2-50倍,支持增删改查ACID

- - 数据库 - ITeye博客
Apache Hive 3.x 架构介绍. hive 的更新操作一直是大数据仓库头痛的问题,在3.x之前也支持update,但是速度太慢,还需要进行分桶,现在hive 支持全新ACID,并且底层采用TEZ 和内存进行查询,性能是hive2的50倍. 生产建议升级到hive3.1.1版本. 了解Apache Hive 3主要的设计更改,例如默认的ACID事务处理和仅支持瘦配置客户端,可以帮助您使用新功能来满足企业数据仓库系统不断增长的需求.