总结
概念
技巧💡
“一致性”和“可用性”都应该站在 client 侧去审视；而“分区容忍性”则是集群 node 侧在遇到网络分区的问题时，选择如何去影响 client 侧感知到的“一致性”和“可用性”
CAP2版解释介绍
第一版解释 不严谨版
CAP 定理指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、 Partition tolerance（分区容错性），三者不可兼得。
- 一致性（C）：所有节点在同一时刻都能看到相同的数据。 分布式系统中多个主机之间是否能够保持数据一致的特性。即，当系统数据发生更新操作后，各个主机中的数据仍然处于一致的状态。
- 可用性（A）：系统提供的服务必须一直处于可用的状态，即对于用户的每一个请求，系统总是可以在有限的时间内对用户做出响应。
- 分区容错性（P）：分布式系统在遇到任何网络分区故障时，仍能够保证对外提供满足一致性或可用性的服务。
第二版解释， 严谨版
在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
- 因为分布式系统并不一定会互联和共享数据。最简单的例如 Memcache 的集群，相互之间就没有连接和共享数据，因此 Memcache 集群这类分布式系统就不符合 CAP 理论探讨的对象；而 MySQL 集群就是互联和进行数据复制的，因此是 CAP 理论探讨的对象
- CAP 关注的是对数据的读写操作，而不是分布式系统的所有功能。例如，ZooKeeper 的选举机制就不是 CAP 探讨的对象。
- 一致性: 对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。
- 第一版从节点 node 的角度描述，第二版从客户端 client 的角度描述。
- 第一版强调同一时刻拥有相同数据（same time + same data），第二版并没有强调这点。也就是可以 same time + different data
- 可用性: 非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）
- 第一版是 every request，第二版强调了 A non-failing node。
- 分区容错性: 当出现网络分区后，系统能够继续“履行职责”。即只要能返回一个合理的响应。这里合理，但是不一定是正确的。
CAP细节
- CAP关注的粒度是数据，而不是系统，系统中往往需要根据模块业务特性来选择是AP还是CP
- CAP是忽略网络延迟的，在存在延迟的情况下，没有绝对的CP，都是某种意义上的最终一致性
- 在没有分区出现的情况下，是可以同时满足CA的，并不是说在分区出现的情况下，可以牺牲掉C或者A，而是要在分区恢复的时候能够自愈
- BASE理论是对AP的延伸，达到最终一致性
为什么AP和CP不可兼得
对于分布式系统，网络环境是相对不可控的。出现网络分区是不可避免的，因此系统必须具备分区容错性(P)。所以系统要么是AP，要么是CP。
是因为数据同步是需要时间的。如果要数据一致，要等同步完，那就是强一致性，但是此时其它客户端肯定不能访问。要么其它客户端能访问，那么数据就一定不是实时的。即保证了可用性。
- 在同步期间，若允许 client 访问，则 client 从不同节点 读取到的数据就可能是不相同的，即牺牲了一致性保证了可用性；AP
- 若不允许 client 访问，则 client 在同步期间无法获取服务，但一段时间后再访问系统，无论访问到的是哪个节点，读 取到的数据一定都是相同的。即牺牲了可用性保证了一致性.CP
CP: CP 模型，采用 CP 模型的分布式系统，一旦因为消息丢失、延迟过高发生了网络分区，就影响用户的体验和业务的可用性。因为为了防止数据不一致，集群将拒绝新数据的写入，典型的应用是 ZooKeeper，Etcd 和 HBase。
AP: AP 模型，采用 AP 模型的分布式系统，实现了服务的高可用。用户访问系统的时候，都能得到响应数据，不会出现响应错误，但当出现分区故障时，相同的读操作，访问不同的节点，得到响应数据可能不一样。典型应用就比如 Cassandra 和 DynamoDB
一致性的分类
从一致性内容**同步的时间**角度来说- 实时一致性：只要数据发生变更，其它副本数据立即就会同步完成。在生产环境中是无法实现的，仅是一种理论状态。
- 最终一致性：经过一段时间的同步后，最终能够达到一个一致的状态。
从 client 获取到的一致性内容角度来说，不管时间问题:
- 强一致性：也称为严格一致性。要求 client 访问到的数据一定是更新过的数据。注意的强一致，在分布式场景说，不管系统内部节点可以存在不一致的状态，但从系统外部看来，不一致的情况并不会被观察到。
- 弱一致性：允许 client 访问不到部分或全部更新过的数据.