CAP理论
C: Consistency (一致性)
理解：
1.从客户端角度来看，主要关注多线程并发读和写，如何保证每次都读到最新的数据。
2.从服务端角度来看，各结点任何时候都要保持相同的数据集（“all nodes see the same data at the same time”）
三种一致性：
1. 强一致性：变更发生后，所有的读操作必需读取到最新数据，传统数据库就是这么做的。
2. 弱一致性：变更发生后，可以容忍后续部分或全部仍然读到老数据。
3.最终一致性：变更发生后一段时间，要求所有都要读到最新数据。
CAP里不能同时满足的一致性指的是强一致性。
A: Availability(可用性)
理解：
1. “Reads and writes always succeed”
2. 一定时间内可以正常的响应请求（如果超时严重，或者频繁发生服务端原因的错误，就不叫高可用了）
P: Partition tolerance(分区容错性)
理解：
1.“the system continues to operate despite arbitrary message loss or failure of part of the system”
2.把系统切分成等价的部分，每部分都能够完成整个系统的所有职能。当一个节点失效时，必须确保不会对系统其余部分产生影响。只要能联上系统至少一个节点，整个系统的功能就应该是完好的，当失效的节点重新上线后，还必须确保其与系统保持同步。
CAP理论核心思路：
在分布式系统的设计中，没有一种设计可以同时满足 Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）3个特性，这三者不可得兼。
CA(一致性+可用性）without P（容错性）
不考虑分区（P）的情况下，只有一个分区（副本），副本的一致性自不必说，自然是一致的；可用性方面，一个节点的写入不需要同步到其他节点，可以高效完成。如果增加多个分区（提高分区容错性），数据的写入需要同步到多个节点（强一致性，所有节点同步成功后再返回用户），增加了同步时间和同步失败的可能性，降低了可用性；如果采用弱一致性，即写入操作在主节点成功后即返回用户结果，再通过异步方式同步到多个分区，那么会增加同步失败和数据丢失的几率，降低了一致性。
案例：单机的Mysql和Oracle；
CP(一致性+容错性）without A（可用性）
不考虑可用性（A）的情况下，多个分区之间可以采用强一致性的机制，保证数据的高度一致性（要么都成功要么都失败）。比如某个分区出现了故障或者分隔，分区没有了响应，由于放弃了可用性，所以可以无限等待并不断重试直到网络恢复，分区可用后将副本数据同步到所有节点。
案例：分布式的数据库（如Redis，HBase，Zookeeper）
任何时刻对ZooKeeper请求能得到一致的数据结果:当master节点网络故障，会进行选举机制，选举时集群不可用。但是它不能保证每次服务请求的可用性，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果。
AP(可用性+容错性）without C（一致性）
不考虑一致性（C)的情况下，多个分区和副本可以提供高可用性。分区越多，用户越能就近访问，提供响应速度；放弃了一致性后，副本的写入操作可以写入主节点成功后即可返回成功，获得搞可用性，然后通过异步的方式将副本同步到多个分区节点上。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，导致全局数据的不一致性。
案例1-12306买票：购买的时候提示你是有票的（但是可能实际已经没票了），但是过了一会系统提示你下单失败，余票不足。其实舍弃的只是强一致性。退而求其次保证了最终一致性。
案例2-Eureka：各个节点平等；有节点挂掉，会立刻换至其他节点，保证服务可用，只不过查到的信息可能不是最新的。在网络稳定后，当前实例新的注册信息会被同步到其他节点中。
在分布式系统中，保证分区容错P是必然要求，那么只能考虑CP或者AP。
CAP选择
当处理 CAP 的问题时，你会有几个选择。最明显的是：
放弃 Tolerance of network Partition。如果你想避免分区问题发生，你就必须要阻止其发生。一种做法是将所有的东西（与事务相关的）都放到一台机器或者一个机架上。这样还是有可能部分失败，但你不太可能碰到由分区问题带来的负面效果。当然，这个选择会严重影响系统的扩展。
放弃 Availability。相对于放弃 Tolerance of network Partition 来说，其反面就是放弃 Availability。一旦遇到分区事件，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务。在多个节点上控制这一点会相当复杂，而且恢复的节点需要处理逻辑，以便平滑地返回服务状态。
放弃 Consistency。放弃一致性，你的系统可能返回不太精确的数据，但系统将会变得“最终一致”，即使是网络发生分区的时候也是如此。
下面是一个使用 CAP 理论的生态系统的分布图：
CAP理论的缺陷
CAP没有考虑不同的基础架构、不同的应用场景、不同的网络基础和用户需求，而C、A、P在这些不同场景中的含义可能完全不同，这种无视差异化的定义导致了非常大的概念模糊，同时也变成CAP被质疑的源头。
因此也出现了BASE这种 CAP和实践相结合的理论，BASE理论解决CAP理论提出了分布式系统的一致性和可用性不能兼得的问题。BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
CAP参考资料：
CAP 定理的含义
分布式系统CAP理论 / 分布式事务一致性
分区容错性
分布式系统中为什么CAP不能兼得
CAP 理论十二年回顾："规则"变了