2000 年时，Eric Brewer 教授在 PODC 会议上提出了 CAP 理论，但是由于没有被证明过，所以，当时只能被称为 CAP 猜想。这个猜想引起了巨大的反响，因为 CAP 很符合人们对设计纲领的预期。在 2002 年后，经过 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP 猜想后，CAP 理论正式成为了分布式系统理论的基石之一。

1、基本概念

Consistency（一致性）：指数据在多个副本之间能够保持一致的特性（严格的一致性）。
Availability（可用性）：指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应（不保证获取的数据为最新数据）。
Partition tolerance（分区容错性）：分布式系统在遇到任何网络分区故障的时候，仍然能够对外服务，除非整个网络环境都发生了故障。

以上是对CAP三个性质的简单说明，除此以外还有一种说法：分布式系统，CAP三者不能同时满足，只能选择其中两个。对于这种说法，将三者各自分析后，再来尝试理解。

2、一致性——Consistency

在分布式中，一致性严格上来说是指所有节点相同部分的数据的完全一致，广义上来说是指对客户端维护了集群的一致。一致性分为两种：读一致和写一致。

所谓读一致，就是客户端在同一时刻，向集群请求同一个数据，都能得到该数据的完全一致的响应。这里的响应可以是数据的值，也可以是一个空数据。这里就涉及到因为读请求的一致性而约束了数据的写一致性。

在理论情况下，数据从客户端到集群某个节点，再到所有节点的过程是不需要任何时间的，显然在目前的现实工程中是无法实现的。在真实的集群中，节点之间通讯需要时间，可能呢出现节点之间网络故障、节点不可用和节点写入数据失败等一系列问题。对于一个写请求，简单来说，当整个集群完全写入之后，写请求也可以获得写入成功的响应，读请求可以获取到最新的数据值。而如果写入过程中，因为某些原因无法完成所有节点对数据的写，那么就应该返回写入失败，如果此时已经写入数据的节点不能做到恢复数据，那么集群出于读一致性的要求，对于写请求可以返回一个空数据。

在实际工程中，写请求即便在集群各节点中以最快的方式传播并且不出错，也会导致集群出现短时间的不一致。所以，在实现一致性的时候，都只能做到最终一致，但是对于集群达成一致的条件限制，如时间和达成一致的节点数等，又将一致性分成强一致性和弱一致性。强弱一致并没有定量的标准，只是相对的概念，有时候也把弱一致性称为最终一致性。

3、可用性——Availability

系统的节点收到了任意请求都能处理并给出响应结果。主要包含两点要求：

节点应当在指定时间内响应，响应时间由具体业务决定。如果响应时间要求在200ms以内，结果在300ms后才返回，该系统就不满足可用性。
集群内所有能够正常接收请求的节点都能返回结果。对于已经停机或者处于其他故障下的节点，允许其不对请求响应。其它节点仍能做出响应，则集群依然具备可用性。在节点接收到请求后，不能因为自身数据不合理，就拒绝响应，必须返回数据。

4、分区容错性——Partition tolerance

对于分区容错性，CAP理论一直说的不清楚，许多文章博客也没有对这一点解释说明，所以这一点应该是最让人迷惑的。

分区指的是节点之间通信异常。造成通信异常可能是网络不通产生的网络分区，也能是节点故障产生的分区。而容错性就是指，出现了分区的异常，集群仍然能够向外提供服务。这一点看起来和可用性好像差不多，其实二者还是有区别的。因为可用性注重的是节点对请求的准时响应，而分区容错性则是指集群部分节点异常后不影响正常功能。

比如说，当数据分散在存储在不同的节点上时，某一个节点不可达（不论出于哪种原因），那么集群就丢失了这一部分数据，此时就说该集群分区容错性低。如果想要提高分区容错性，那么就要将同样的数据在不同节点上复制，最好是每个节点都具有完整的数据，这样的分区容错性最高。但是如果这样做的，为了就需要等待数据的复制，可能会影响节点对请求的响应，即影响其可用性。

5、对于CAP三选二的理解

首先根据以上对CAP的理解，三者是否无法共存是要看对可用性的要求。如果我们对集群响应请求的要求很低，那么某种程度上可以同时达成CAP，只不过一次请求可能需要等待非常长的时间才能得到结果，在实际项目，显然这一点是无法接受的。由于，分布式系统中，分区是必须要考虑的情况，所以满足分区容错性，并且尽可能提高分区容错性是必要的。

那么，如果选取一致性，那么就要求数据的备份复制必须在必要的节点相同，那么复制的时间就会增加，一致性必然降低。反之，选择可用性，那么对于数据的复制可能不需要所有节点相同，对于一致性来说就会下降，读请求可能在同一时间得到同一数据的不同值。

对CAP来说，不存在完全选取其中两种，而完全抛弃第三种。我们在实现CAP时，是对三者程度的一种取舍，实际上，一个优秀非分布式系统/协议/算法，在集群正常运行的情况下应当尽可能保证三者。比如说Raft算法，是一种CP算法，当进行选举的时候集群完全不可用，而且Raft使用多数派的共识，这也就意味着虽然它是相对强一致的算法，但也不能保证整个集群绝对一致，随着集群规模的扩大，为了达成多数派和维持Leader的身份，会产生大量的网络通讯，这样一致性会变差。再看Gossip协议，通过反熵传播和谣言传播随机进行数据的传递，在一致性上显然比起Raft要低了很多，这也被称为最终一致性/弱一致性，但是这样对集群的可用性会提高很多，即便是集群规模扩大，每个节点都只会向附近节点传播，极大地降低了网络通信，可以保证相对较高的可用性。Raft和Gossip为了保证分区容错性，都是将集群数据完整地复制在每个节点上。

6、总结

首先实际情况中，目前都只能最终一致，达不到瞬时的完全一致。CAP三者在现实中，都是对其程度强弱的取舍，一个分布式系统中在正常运行的过程中，都应当同时保证一定程度的CAP。