分布式系统中的 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 中文叫作"一致性"

假设有以下分布式系统

G一、G2 是同一个服务的两个实例，分部在不一样的区域

1. 客户端发送一个请求被网关转发到 G1 上，将 G1 的 u0 改成了 u1
2. 客户端想查看修改结果，因而又发送一个请求，此次被网关转发到 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 ** 就能够共存！

参考

• CAP 定理的含义