在 理论计算机科学中,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块钱，如果你等半个小时才扣掉，这显然有问题啊。