分布式CAP定理记录

1.CAP原则又称CAP定理

    指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能同时满足其中的2个，CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。

2. 一个栗子🌰

如图所示，假设一个分布式系统正常运转的流程

2.1、Consistency 一致性

一致性指的是所有节点在同一时间的数据完全一致。对用户来说，就好像是操作了同一个数据库的同一个数据一样。

如果用户修改了G1的值v1，但是随后有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是 v0。G1 和 G2 读操作的结果不一致，这就不满足一致性了。

2.2、Availability 可用性

可用性指服务一直可用，而且是正常响应时间。用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1，否则就不满足可用性。(无论请求是否正常，即使发生了异常也要有响应，不能吞了请求)。

2.3、Partition tolerance 分区容错性

分区容错性指在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。比如G1节点和G2节点，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。(某一个区的服务不能正常接收请求的时候，必须能有其他区能接替故障区的服务接收到请求提供正常的响应)。

3、可用性(Availability)和分区容错性(Partition tolerance)的区别：
可用性是指接收到了请求，但是没有响应任何结果(吞了请求)，不给其他区的服务尝试继续提供服务的机会(比如SpringBoot设置接口访问超时时间)。
分区容错性是指某个区的服务不能正常工作时，其他区的服务可以尝试继续提供服务(比如使用eureka等注册中心时，服务中的某台ServiceA重启无法处理请求时，另一台ServiceB可以继续提供服务)。

4. CAP原则权衡

通过CAP理论，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢？

一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错）。

如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性不。

如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。

综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

4.1. CA without P

如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。

4.2. CP without A

如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。

4.3. AP wihtout C

要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

5、BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。