CAP定理是分布式事务的基础理论，对理解和使用分布式事务十分重要，而初学者往往对这俩个东西进行模糊淡化，这篇博客我将对其进行一个通俗的解释，快速把握与理解。
CAP定理
概述
2000 年的时候，Eric Brewer 教授提出了 CAP 猜想，2年后，被 Seth Gilbert 和 Nancy Lynch 从理论上证明了猜想的可能性，从此，CAP 理论正式在学术上成为了分布式计算领域的公认定理。并深深的影响了分布式计算的发展。提出分布式系统有三个指标：
- Consistency（一致性）
- Availability（可用性）
- Partition tolerance （分区容错性）
在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
Consistence（一致性）
CAP 理论中的一致性是指强一致性（ Strong Consistency ），又叫线性一致性（ Linearizable Consistency ），它要求多节点组成的分布式系统，能像单节点一样运作，如果一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有的读操作都不能读到这个数据。
一致性指 “all nodes see the same data at the same time”，即所有节点在同一时间的数据完全一致。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。
- 强一致性: 当更新操作完成之后，在任何时刻所有的用户或者进程查询到的都是最近一次成功更新的数据。强一致性是程度最高一致性要求，也是最难实现的。
- 弱一致性: 当数据更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。
- 最终一致性: 在某一时刻用户或者进程查询到的数据可能都不同，但是最终成功更新的数据都会被所有用户或者进程查询到。简单理解为，就是在一段时间后，数据会最终达到一致状态。
比如现在包含两个节点，其中的初始数据是一致的：
当我们修改其中一个节点的数据时，两者的数据产生了差异：
要想保住一致性，就必须实现node01 到 node02的数据 同步：
Availability （可用性）
CAP 理论对可用性的定义，指的是要求系统提供的服务必须处于 100% 可用的状态，对于用户的每一个操作请求，系统总能够在有限的时间内返回结果。
用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。 可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺：我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。
有三个节点的集群，访问任何一个都可以及时得到响应：
Partition Tolerance（分区容错性）
Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务
由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。
在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。
可用性针对节点出现故障，系统可用；分区容错性针对网络出现问题，系统可用
保证P，为什么无法同时满足AC？
下面用一个例子来演示为什么在保证P的情况，无法让AC同时实现。
如下图有俩个分布式服务，在系统运行开始前，俩个系统保持正常工作：
现在一个修改请求到达第一条服务器，将key修改为v1。
按照道理，第一台服务器会向第二台服务器进行数据同步，但是现在假设一种极端情况，第一台服务器跟第二台服务器之间的网络断开了，但我们仍要支持这种网络异常，也就是满足分区容错性，
在这段时间内，有有一个获取请求请求到了第二台服务器。即获取key的值
由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据 V1，怎么办呢？有二种选择，第一，牺牲数据一致性，响应旧的数据V0给用户；第二，牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作完成之后，再给用户响应最新的数据V1。
第一种也就是AP，如下图显示
第二种也就是CP，如下图显示
也就是说，在P一定会出现的情况下，A和C之间只能实现一个。
CP与AP如何取舍
满足CP舍弃A，也就是满足一致性和容错性，舍弃可用性。如果你的系统允许有段时间的访问失效等问题，这个是可以满足的。就好比多个人并发买票，后台网络出现故障，你买的时候系统就崩溃了。
满足AP舍弃C，也就是满足可用性和容错性，舍弃一致性。这也就是意味着你的系统在并发访问的时候可能会出现数据不一致的情况。
在我们架构师开发分布式系统时，是需要根据业务进行权衡的。在我们大型互联网公司，因为机器数量庞大，网络故障是常态，一般选择AP原则，牺牲掉数据一致性。（一些金融产品对数据一致性要求很高的，就会选择CP）。
- Redis中间件 ----> AP
- RocketMQ中间件 -----> AP
- 分布式事务-2pc ----> CP
- 分布式事务-最大努力尝试 ---> AP
- Eureka ---> AP
