在 理论计算机科学中, CAP定理(CAP theorem), 又被称作 布鲁尔定理(Brewer's theorem), 它指出对于一个 分布式计算系统 来说,不可能同时满足以下三点:
一致性(Consistency) (所有节点在同一时间具有相同的数据)
可用性(Availability) (保证每个请求不管成功或者失败都有响应)
分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项。
在任何数据库设计中,一个Web应用至多只能同时支持上面的两个属性,不可能三者兼顾。对于分布式系统来说,分区容错是基本要求,所以必然要放弃一致性。对于大型网站来说, 分区容错和可用性的要求更高,所以一般都会选择适当放弃一致性。对应CAP理论,NoSQL追求的是AP,而传统数据库追求的是CA,这也可以解释为什么 传统数据库的扩展能力有限的原因。
ACID解决方案
ACID数据库事务极大地简化了应用开发人员的工作.正如其缩写标识所示,ACID事务提供以下几种保证:
Atomicity(原子性),事务中的所有操作,要么全部成功,要么全部不做.
Consistency(一致性)在事务开始与结束时,数据库处于一致状态.
Isolation(隔离性) 事务如同只有这一个操作在被数据库所执行一样.
Durability(持久性). 在事务结束时,此操作将不可逆转.(也就是只要事务提交,系统将保证数据不会丢失,即使出现系统Crash,译者补充).
数据库厂商在很久以前就认识到数据库分区的必要性,并引入了一种称为2PC(两阶段提交)的技术来提供跨越多个数据库实例的ACID保证
BASE解决方案
Basically Available(基本可用)
Soft-state( 软状态/柔性事务)
Eventual Consistency(最终一致性)
BASE模型是传统ACID模型的反面,不同与ACID,BASE强调牺牲高一致性,从而获得可用性,数据允许在一段时间内的不一致,只要保证最终一致就可以了。
对于web应用程序,最多只能支持两种特性,而Partition tolerance是scale out的根本之一,所以我们只能从一致性和可用性之间做一下tradeoff.有的业务需要我们放弃可用性来保持一致性,而很多业务又需要我们放弃一致性而更多的考虑可用性。Web应用应该更多的考虑可用性。所以我们的架构应该更多的思考BASE而不是ACID.简单来讲就是为了满足高负载的用户访问,我们可以容忍短暂的数据不一致。我们平常经常能够碰到这种情形。例如很多后台cache机制导致我们的更新过一段时间才能够有效。这显然不是ACID模式的特性。但是有的时候我们必须使用ACID的模式,例如我从卡里支付了5000块钱,如果你等半个小时才扣掉,这显然有问题啊。