关于CAP

后知后觉仍然比不知不觉好一点,虽然我们努力最求的是先知先觉。

在阅读了Eric A. Brewer的keynote at the PODC和Gilbert and Lynch的Brewer's Conjecture and the Feasibility of Consistent,Available,Partition-Tolerant Web Service后,对CAP有了些初步的认识,也尝试弄清楚一些基本的问题。

1. 为什么我们需要知道CAP

记得当初学习数学科学(例如微分方程)的时候,如果求解一个问题,首先我们需要证明这个解的存在性。(没学过微分方程也可以回忆一下哥尼斯堡七桥问题

现实生活中,我们往往面临的是非常具体(甚至琐碎)的问题,我们也在不断付出巨大的努力的尝试解决它们。如果问题棘手,发现一时无法走出的困境后,往往会寻求新的设计方案来解决问题。每一个方案(系统)设计之初,参与设计者往往对未来这个方案充满了憧憬,事实上,新方案也一般能解决现有系统的瓶颈。但是新方案运行一段时间后,我们又会重新发现,我们绕过了一些问题,面对的是一些新的困境。

为了避免这种情况,在设计新方案的时候,我们需要尝试弄清楚我们现在系统解决了哪些问题,没有解决哪些问题,无法解决哪些问题;设计新系统,我们能够解决哪些,无法解决哪些。

CAP理论(也许不能说是严格理论,因为我们往往在C、A、P之前寻求平衡)便是基于这样的思考,产生的理论。

2. 什么是CAP

即使是现在,我仍然不是很理解CAP,所以本文也无法清楚的阐述"什么是CAP",这里将列出我的认识,和看到并觉得靠谱的认识。

CAP是Eric A. Brewer在PODC上首次提出,Brewer的一部分工作便设计大型的分布式系统设计与实现,例如Global Search Engines、Distributed Web Caches等。所以CAP理论也是基于分布式(Distributed Systems)的系统,所以下面全部的内容,都需要放到分布式系统的中去理解,否则你会迷失。

Consistency是容易理解的;关于Availability和Partition tolerance,Jeff Darcy在文章Availability and Partition Tolerance做了如下阐述CAP是指Consistency, availability and partition tolerance的缩写,不过理解这三个概念并不容易。CAP理论指出,这三者不可兼得。

“Availability is sacrificed if certain nodes are forced to wait for unbounded time because of a failure. This includes the common approach of forcing non-quorum nodes down, which Brewer alludes to.”

“Partition tolerance is sacrificed if certain requests are forced to wait for unbounded time because of a failure. This is most often the case when a node holding a lock cannot be reached, and quorum loss is not used to break the lock.”

虽然看起来很晦涩,不过这已经是能够看到最清晰的解释了。(如果你仔细看这篇文章后面的评论,还有发现很多有意思的东西)

3. Sample of CAP

符合CAP设计哲学中,两个最典型的案例便是:Google的BigTable和Amazon的Dynamo。前者是一个CA系统,后者则是一个AP系统。

4. CAP 和 MySQL

这里以MySQL Replication(Master-Slave)方案为例。在MS结构中,节点M和节点S,都可以对外提供服务,当其中的一个节点故障,另一个节点仍然能够对外提供服务,所以MS方案认为是满足Availability的;目前MS结构仍然是异步的方式运行,即当主库写入时,备库未必一定也写入了,备库甚至允许短暂和主库断开连接,而且当主库处理请求时,也无需确认备库的状态,所以MS结构是满足Partition tolerance的;但是由于MS结构的异步特性,我们看到主备的数据是可能不一致的,即不满足Consistency。

Semi-sync Replication则是在Consistency要求更严格,同时在部分失去Partition tolerance;如果MySQL使用DRBD(严格模式) 做HA方案,则实现了Consistency,就失去了Partition tolerance。

时间: 2024-09-16 04:55:13

关于CAP的相关文章

关于CAP定理的个人理解

CAP定理简介 在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点: 一致性(Consistency):同一个数据在集群中的所有节点,同一时刻是否都是同样的值. 可用性(Availability):集群中一部分节点故障后,集群整体是否还能处理客户端的更新请求. 分区容忍性(Partition tolerance):是否允许数据的分区,分区的意思是指是否允许集群中的节点之间无法通

分布式系统设计权衡:CAP

写在最前: 1.为什么学习并记录分布式设计理念一系列相关的东西 在日常工作中系统设计评审的时候,经常会有一些同事抛出一些概念,高可用性,一致性等等字眼,他们用这些最基本的概念去反驳系统最初的设计,但是很多人理解的可用性,一致性等等问题,都是自己拍脑袋想的,或者根本和最原始表达的意思就不是一个东西,在这种情况下PK,就像不再一个频段的人在交流,除了争论,没有任何实质性的进展,所以有必要熟悉其理论基础,以免贻笑大方.(其实类似的例子还有很多,国内的技术人员都喜欢把一些此词模糊化,混淆而谈.例如XX云

关于CAP理论的一些笔记

CAP的概念 2000年,Eric Brewer 教授在 ACM 分布式计算年会上指出了著名的 CAP 理论: 分布式系统不可能同时满足一致性(C: Consistency),可用性(A: Availability)和分区容错性(P: Tolerance of network Partition)这三个需求.大约两年后,Seth Gilbert 和 Nancy lynch 两人证明了CAP理论的正确性. 三者的含义如下: Consistency:一致性,一个服务是一致的完整操作或完全不操作(A

ACID与CAP定理

ACID:RMDB的4个基本要素         ACID,指数据库事务正确执行的四个基本要素的缩写.包含:原子性(Atomicity).一致性(Consistency).隔离性(Isolation).持久性(Durability).一个支持事务(Transaction)的数据库系统,必需要具有这四种特性,否则在事务过程(Transaction processing)当中无法保证数据的正确性,交易过程极可能达不到交易方的要求.     原子性         整个事务中的所有操作,要么全部完成,

CAP的相对论

CAP是什么? CAP理论,被戏称为[帽子理论].CAP理论由Eric Brewer在ACM研讨会上提出,而后CAP被奉为分布式领域的重要理论[1] . 分布式系统的CAP理论:首先把分布式系统中的三个特性进行了如下归纳:  一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值.(等同于所有节点访问同一份最新的数据副本)  可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求.(对数据更新具备高可用性) 分区容忍性(P):以实际效果而言,分区相当于对通信的时

CAP原理和BASE思想

分布式领域CAP理论,Consistency(一致性), 数据一致更新,所有数据变动都是同步的Availability(可用性), 好的响应性能Partition tolerance(分区容错性) 可靠性 定理:任何分布式系统只可同时满足二点,没法三者兼顾.忠告:架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍. 关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区:Atomicity原子性:一个事务中所有操作都必须全部完成,要么全部不完成.Consiste

How to beat the CAP theorem

http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html http://kb.cnblogs.com/page/124567/   面对大数据, 提出一种不同的思路 传统的方法在保证可用性的前提下, 必须用很复杂的逻辑来保证数据的最终一致性, 比如Dynamo的方案, 矢量时钟(vector clock)记录数据的版本历史合并... 作者认为复杂的原因不是 CAP 系统,而是数据增量算法和数据的可变状态 所以他的solution是,

《解读NoSQL》——2.7 基于Brewer的CAP定理进行权衡

2.7 基于Brewer的CAP定理进行权衡 为了能在系统故障时做出最好的决策,你需要考虑基于不可靠的网络的分布式系统的一致性和可用性属性. Eric Brewer在2000年首次提出CAP定理.CAP定理表明了任何分布式数据库系统最多只能满足以下3个期望属性中的2个. 一致性--对于所有客户端,具有唯一的.最新的.可读的版本的数据.这和前面讨论的ACID的一致性不太一样.这里的一致性主要关注的是多个客户端从多个复制分区读取相同的内容并得到一致的结果.高可用性--我们知道分布式数据库总是允许数据

《NoSQL权威指南》——1.5 CAP定理

1.5 CAP定理 2000年,Eric Brewer在ACM分布式计算原理主题研讨会做了主题演讲,并介绍了CAP定理(也称Brewer定理).2002年,在麻省理工学院的Seth Gilbert和Nancy Lynch的努力下进行了修订和修改,后来又有很多人参与. 这个定理是针对分布式计算系统的,而传统并发模型会假设有中央并发管理机制.悲观并发模型有一个"交通警察",乐观并发模型有一个"服务领班".CAP代表一致性(consistency).可用性(availab

CAP – Consistency, Availability, Partition Tolerance

---------------------------------------------------------------------------------------------------------------------- http://blog.nahurst.com/visual-guide-to-nosql-systems 相当不错的ppt: http://www.slideshare.net/jboner/scalability-availability-stability