前言
CAP定理是在分布式环境下对于现实情况的一种认识，关系数据库的ACID也是CAP定理的一种特殊情况，有了这个理论后，分布式系统架构设计师可以放开了手脚，根据系统的应用场景进行调整，以在一致性、可用性、系统扩展性方面取得平衡。
定理的历史
该定理最初是由Brewer在2000年PODC大会上演讲时阐述的，在当时只是一个猜想，他认为Consistency,Availablity,Partition Tolerance这三个核心需求在分布式系统中不可能同时被满足。Brewer并没有给出证明，猜想是基他在UC Berkley的理论工作以及主持Inktomi 期间的观察，以及在如何构建高伸缩性系统时与其他人所做出的各种折衷方案的讨论（例如：SOSP（Symposium on Operating System Principles）的1997年的Cluster-Based Scalable Network Service 和1999年的Harvest, yield, and scalable tolerant system ）。2002年，麻省理工（MIT）的Seth Gilbert 和Nancy Lynch ，理论上证明了Brewer猜想是正确的，就此Brewer定理诞生了。
定理的描述
系统的前提是在share-data的系统中，3个核心的需求是：Consistency ，Availability 和Partition Tolerance ，为了理解这个定理就一定要知道这三个需求的内涵。
- Consistency
这个一致性不同与关系数据理论中的一致性，即ACID中的“C”，那个里面的一致性是一种强一致性，是一种特例。在分布式系统里面的一致性是指一个操作是一个完整操作或完全不操作（A service that is consistent operates fully or not at all），其内涵有两点：一是操作必须是原子的，二是不同的操作有一个总体上的顺序。Gilbert 和Lynch在他们的证明中使用“atomic”而不是consistent，技术上来讲更准确。
- Availabiliy
指一个请求必然会得到响应，也就是该系统使用的任何算法必须最终终止。看似是简单的条件，当同时要求分区容忍性时，这是一个很强的定义：即使是严重的网络错误，每个 请求必须终止。
- Partition Tolerance
如果应用和数据库运行在一个机器上，服务器是作为一种原子处理单元：要么工作要么不工作，一旦开始将数据和逻辑分布在不同的节点上，就有形成partition的风险。这里就是指对于这种风险的容忍度。有一个“脑裂”的概念，与这个是类似的。在关系数据库集群上（如：RAC），要求严格的ACID，所以对数据的partition是不能容忍的。
定理的证明
网络中的两个节点N1，N2。他们共享同一数据V，其值为V0。N1上有一个算法A，可以认为A是安全，无bug，可预测和可靠的；N2上有一个类似的算法B。在这个例子中，A写入V的新值而B读取V的值。
正常情况的处理过程如下：(1)A写入新的V值V1。(2)N1发送信息给N2，更新V的值。(3)现在B读取的V值将会是V1。
网络断开（partions）（意味着从N1无法发送信N2）那么在第3步的时候，N2就会包含一个不同的V值（不一致）。
1、如果满足一致性（C），而且请求都会返回（A），那么当网络断开的时候B会返回错误，那么就是无法容忍Partition（违反P）。
2、如果满足一致性（C），也可以容忍数据Partition，那么可能B请求无法返回（违反A）。
3、如果可以容忍数据Partion，而且请求都会返回，那么A写的数据和B读的数据值不同，
定理的应用
根据应用，分布式系统设计的时候在C、A、P之间做取舍，下面的图比较清楚的说明了这一点，可惜是日文的，但不影响阅读.
