本文为翻译的文章，作者James Bryden，原文：
http://nosql-guide.com/cap-theorem-what-does-it-mean-to-you/
CAP理论 – 是，否或者。。。也许
如果你还没有接触过CAP理论，它就像这样。一个分布式计算机系统不能同时满足以下三点：
**一致性。**计算机系统的所有部分在同一时间看到的是同样的数据。
**可用性。**每个对于系统的请求都会收到响应，不论是肯定的还是否定的。
**分区容忍性。**即使有消息丢失或者部分失败，系统仍然可以运行
你可能已经看出来了，这三个标准的首字母组成了单词CAP – 因此就成了这个理论的名字。Eric Brewer在2000年首次提出了CAP理论，他建议，设计的选择应该在这三个CAP属性中的两个当中来进行，也就是CA，AP或者CA。
使用CAP理论对数据库技术进行分类
比如，根据这些CAP属性组合，我们可以对传统的关系型数据库管理系统和某些新生代的NoSQL数据存储进行定位
CA（一致性和可用性）：关系型数据库管理系统（RDBMS）
CP（一致性和分区容忍性）：MongoDB文档存储和Redis KV存储
AP（可用性和分区容忍性）：CouchDB文档存储和Riak KV存储
对于MongoDB和CouchDB复制能力的快速比较表明了它们的定位。MongoDB为提升一致性而提供了单个主服务器的主从复制功能。CouchDB提供了多个主服务器的复制功能，它为更好的可用性和更快的服务器响应而设计。
适用于关系型数据库的ACID
在包含关系型数据库系统的CA类别中，事务具有ACID的特点，ACID指原子性，一致性，隔离性和持久性。换句话说，每个事务都是：要么全部成功，要么全部失败，系统只能从一个有效状态变成另外一个有效状态，不管事务是并行执行还是有序执行，都生成相同的最终结果，并且只要一个事务完成了，那么这个事务就保持在完成的状态。
适用于云系统的BASE
相反，在一个更与AP呼应的弹性的或者云计算环境中，ACID的特点可能就不适用或者甚至毫不相关。在这种上下文中运行的服务常常是需要响应式的，即使内部系统不可访问。Brewer和他的学生们提出了BASE这个首字母缩写的单词，它用来描述这种新的范式。BASE指基本可用，软状态和最终一致性。这可以解读为CAP定义中的可用性，一个系统的状态即使在没输入的时候也可能会改变，并且在一个事务之后，一致性“迟早”会发生，除非系统接收了进一步的输入。换句话说，使用陈腐的数据是可以接受的，并把来源于猜测的估计当成答案也是没问题的。
CAP序列
在Brewer创造CAP理论12年之后，他认为需要额外的描述来澄清一些事情。特别是，如果分区容忍性是一个目标，那么这并不一定意味着在一致性（C）和可用性（A）之间有严格的划分。可以在系统内部、子系统内部来做出C和A的选择，并且这种选择是基于相关的操作或者数据的。这三个特点是连续的而不是离散的。同样的，ACID和BASE也不一定是两种完全不同的状态，而是系统中的一个序列的两个方向，ACID少一点BASE多一点，反之亦然。
设计和运营的选择
随着应用向上扩展，CAP理论的效果也会变得更加显著。事务比较少的时候，分布式数据库能够以较小的延迟恢复一致性，并且对于总体的性能或者用户察觉方面没有明显的影响。对于分布式系统，即使绝对意义上的CAP不可实现，但是明智的设计能够限制负面作用并提升正面效果，让关键的事务得以保证，同时在其他地方优化用户体验。