只有 系统 达到一定的体量，就不得不面临分布式的问题，分布式系统的最大难点，就是各个节点的状态如何同步。 CAP 定理就是这方面的基本定理，由加州大学的计算机科学家 Eric Brewer 于 1998 年提出。
定理的主要内容
Eric Brewer 认为 分布式系统有三个指标
- C : Consistency 一致性
- A : Availability 可用性
- P : Partition tolerance 分区容错性 并且 Eric Brewer 认为这三个指标不可能同时做到！这个结论就叫做 CAP 定理。
我们先来看下这三个指标是什么意思
Partition tolerance
Partition tolerance 直译 分区容错性， 我们将 Partition tolerance 拆开来理解。
Partition(分区)： 分布式、分布式，系统分部在不同的地方才叫分布式， Eric Brewer 将"系统分部在不同的地方"这个概念取了个名字叫 Partition(分区) ,这就是分区的含义
tolerance(容错): 既然分布式一定是 Partition(分区) 的，那么就会带来一个问题，不同区域之间通信会有延迟甚至是失败。比如一台服务器在 齐齐哈尔 一台服务器在 上海长距离通信可能导致超时或失败
总的来理解，就是 分布式系统的不同分区之间会产生“隔阂”
通常来讲一个分布式系统一定(有“隔阂”)满足 Partition tolerance(分区容错性)
Consistency
Consistency 中文叫做"一致性"
假设有如下分布式系统
G1、G2 是同一个服务的两个实例，分部在不同的区域
- 客户端发送一个请求被网关转发到 G1 上，将 G1 的 u0 改为了 u1
- 客户端想查看修改结果，于是又发送一个请求，这次被网关转发到 G2 上，结果发现还是 u0
上面的例子值在 G1 上是 u1, 在 G2 上是 u0，就不符合Consistency(一致性)
那么样才能满足 Consistency(一致性) 呢，可以让 G1 和 G2 同步
如图，G1 发生变化后同步到 G2， 这样 G1 和 G2 就一样了。
但问题并没有解决，上一章我们讲到 分布式系统的不同分区之间会产生“隔阂”，这意味着同步不是瞬间完成的而是有个过程的，甚至可能还会失败。假如在同步过程中，client 访问 G2 得到还是 u0
怎么解决这个问题呢？
答案是，在同步完成之前，不让 G2 对外提供服务，同步完成之后，在对外提供服务
经过上面的一系列操作，终于完成了 Consistency(一致性)
Availability
Availability 中文叫做"可用性" ，顾名思义指的是 分布式系统中，服务必须可以使用(访问)。
这一点实现起来比较简单，只有你的服务不挂，并且对外提供服务就可以了。
Consistency 和 Availability 难以共存
Consistency 那节提到，为了保证同步过程中的数据一致，我们让G2不对外提供服务。此时 G2就处于 不可用状态。 不满足Availability(可用性) 的条件。
但是我们如果不这么做，有无法保证 Consistency(一致性)
因此说 Consistency 和 Availability 难以共存
Consistency 和 Availability 难以共存的根本原因
Consistency 和 Availability 难以共存的根本原因是因为 Partition tolerance(分区容错性)
回到 Consistency 那一小节，我们为什么要让 G2 停止对外提供服务，是因为同步需要一个过程。 哪为什么同步需要一个过程呢？是因为 分布式系统的不同分区之间会产生“隔阂”，相互通信可能会有延迟或失败
等哪一天，通信技术发达了从中国到美国也能做的通信0延迟，分布式系统的不同分区之间就不会产生“隔阂”了。分区之前同步瞬间完成，我们也不需要让 G2 对外停止服务了。**Consistency 和 Availability ** 就可以共存！
