分布式系统中的 CAP 定理 _CAP

【分布式系统中的 CAP 定理】只有系统达到一定的体量，就不得不面临分布式的问题，分布式系统的最大难点，就是各个节点的状态如何同步。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 ** 就可以共存！