CAP理论对分布式系统的特性做了高度抽象，将其抽象为一致性、可用性、分区容错性。 并对特征间的冲突做了总结：CAP不可能三角。

CAP三指标

• 一致性（Consistency）
• 可用性（Availability）
• 分区容错性（Partition Tolerance）

一致性

客户端的每次读操作，不管访问哪个节点，要么读到的都是同一份最新的数据，要么读取失败。一致性强调的是各节点的数据一致，而不是数据完整。
例子：2 个节点的 KV 存储，原始的 KV 记录为“X = 1”

随后，客户端向节点1发送写请求“SET X= 2“

如果节点 1 收到写请求后，只将节点 1 的 X 值更新为 2，然后返回成功给客户端，这个时候节点 2 的 X 值还是 1，那么两个节点是非一致性的。

如果节点 1 收到写请求后，通过节点间的通讯，同时将节点 1 和节点 2 的 X 值都更新为2，然后返回成功给客户端，那么在完成写请求后，两个节点的数据就是一致的了，之后，不管客户端访问哪个节点，读取到的都是同一份最新数据。

一致性是分布式系统非常重要的一个特性，强调的是数据的一致。在客户端看来，集群和单机在数据一致性上是一样的。

• 弊端：当发生分区故障的时候，有时不能仅仅因为节点间出现了通讯问题，节点中的数据会不一致，就拒绝写入新数据，之后在客户端查询数据时，就一直返回给客户端出错信息。

可用性

任何来自客户端的请求，不管访问哪个节点，都能得到响应数据，但不保证是同一份最新数据。强调的是服务可用，但不保证数据的一致。
例：用户可以向节点1和2发起读请求，如果不管节点间的数据是否一致，只要节点服务器收到请求，就响应X的值，那个2个节点是满足可用性的。

分区容错性

当节点间出现任意数量的消息丢失或高延迟的时候，系统仍然可以继续提供服务。不管集群内部出现什么样的数据同步问题，集群会一直运行，对外提供服务。强调的是集群对分区故障的容错能力。

上图如果节点1和节点2之间的通信出现故障时，集群仍然能够对外提供服务，则此时集群具备分区容错性。如果此时不能对外提供服务，则此时不具备分区容错性。

CAP不可能三角

CAP 不可能三角说的是对于一个分布式系统而言，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）3 个指标不可兼得，只能在 3 个指标中选择 2 个。

P存在的必要性

只要有网络交互就一定会有延迟和数据丢失，而这种状况我们必须接受，还必须保证系统不能挂掉。所以就像我上面提到的，节点间的分区故障是必然发生的。也就是说，分区容错性（P）是前提，是必须要保证的。

在不存在网络分区的情况下，也就是分布式系统正常运行时（这也是系统在绝大部分时候所处的状态），就是说在不需要 P 时，C 和 A 能够同时保证。只有当发生分区故障的时候，也就是说需要 P 时，才会在 C 和 A 之间做出选择。而且如果各节点数据不一致，影响到了系统运行或业务运行（也就是说会有负面的影响），推荐选择 C，否则选 A。
上述理论作为理解，一般情况下分布式系统设计必须考虑分区容错性，也就是分区故障的影响。

• 单击版的MySQL可以理解为CA模型，但此时已经不是分布式系统了。

CP理论

选择了一致性（C）的时候，如果因为消息丢失、延迟过高发生了网络分区，部分节点无法保证特定信息是最新的，那么这个时候，当集群节点接收到来自客户端的写请求时，因为无法保证所有节点都是最新信息，所以系统将返回写失败错误，也就是说集群拒绝新数据写入。

CP 模型的分布式系统，一旦因为消息丢失、延迟过高发生了网络分区，就影响用户的体验和业务的可用性。因为为了防止数据不一致，集群将拒绝新数据的写入

• ZooKeeper，Etcd 和 HBase

AP理论

选择了可用性（A）的时候，系统将始终处理客户端的查询，返回特定信息，如果发生了网络分区，一些节点将无法返回最新的特定信息，它们将返回自己当前的相对新的信息。

AP 模型的分布式系统，实现了服务的高可用。用户访问系统的时候，都能得到响应数据，不会出现响应错误，但当出现分区故障时，相同的读操作，访问不同的节点，得到响应数据可能不一样。

• 典型应用就比如 Cassandra 和 DynamoDB。