关于分布式:CAP理论解读

经验过技术面试的小伙伴想必对这个两个概念曾经再相熟不过了！

我当年加入面试的时候，不夸大地说，只有问到分布式相干的内容，面试官简直是必定会问这两个分布式相干的实践。

并且，这两个实践也能够说是小伙伴们学习分布式相干内容的根底了！

因而，小伙伴们十分十分有必要将这实践搞懂，并且可能用本人的了解给他人讲进去。

这篇文章我会站在本人的角度对这两个概念进行解读！

CAP 实践

CAP 实践 / 定理起源于 2000 年，由加州大学伯克利分校的 Eric Brewer 传授在分布式计算原理研讨会（PODC）上提出，因而 CAP 定理又被称作  布鲁尔定理（Brewer’s theorem）

2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 发表了布鲁尔猜测的证实，CAP 实践正式成为分布式畛域的定理。

简介

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。

CAP 实践的提出者布鲁尔在提出 CAP 猜测的时候，并没有具体定义 Consistency、Availability、Partition Tolerance 三个单词的明确定义。

因而，对于 CAP 的民间解读有很多，个别比拟被大家举荐的是上面这种版本的解。

在实践计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能能同时满足以下三点中的两个：

• 一致性（Consistence） : 所有节点拜访同一份最新的数据正本
• 可用性（Availability）: 非故障的节点在正当的工夫内返回正当的响应（不是谬误或者超时的响应）。
• 分区容错性（Partition tolerance） : 分布式系统呈现网络分区的时候，依然可能对外提供服务。

什么是网络分区？

分布式系统中，多个节点之前的网络原本是连通的，然而因为某些故障（比方局部节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区。

不是所谓的“3 选 2”

大部分人解释这一定律时，经常简略的表述为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上这是一个十分具备误导性质的说法，而且在 CAP 实践诞生 12 年之后，CAP 之父也在 2012 年重写了之前的论文。

当产生网络分区的时候，如果咱们要持续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的抉择。也就是说分区容错性（Partition tolerance）咱们是必须要实现的。

简而言之就是：CAP 实践中分区容错性 P 是肯定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。

因而， 分布式系统实践上不可能抉择 CA 架构，只能抉择 CP 或者 AP 架构。

为啥无同时保障 CA 呢？

举个例子：若零碎呈现“分区”，零碎中的某个节点在进行写操作。为了保障 C，必须要禁止其余节点的读写操作，这就和 A 发生冲突了。如果为了保障 A，其余节点的读写操作失常的话，那就和 C 发生冲突了。

抉择的关键在于以后的业务场景，没有定论，比方对于须要确保强一致性的场景如银行个别会抉择保障 CP。

CAP 理论利用案例

我这里以注册核心来探讨一下 CAP 的理论利用。思考到很多小伙伴不晓得注册核心是干嘛的，这里简略以 Dubbo 为例说一说。

下图是 Dubbo 的架构图。 注册核心 Registry 在其中表演了什么角色呢？提供了什么服务呢？

注册核心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册核心交互，注册核心不转发申请，压力较小。

常见的能够作为注册核心的组件有：ZooKeeper、Eureka、Nacos…。

1. ZooKeeper 保障的是 CP。 任何时刻对 ZooKeeper 的读申请都能失去一致性的后果，然而，ZooKeeper 不保障每次申请的可用性比方在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。
2. Eureka 保障的则是 AP。 Eureka 在设计的时候就是优先保障 A（可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因而 Eureka 不会像 ZooKeeper 那样呈现选举过程中或者半数以上的机器不可用的时候服务就是不可用的状况。Eureka 保障即便大部分节点挂掉也不会影响失常提供服务，只有有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。
3. Nacos 不仅反对 CP 也反对 AP。

总结

在进行分布式系统设计和开发时，咱们不应该仅仅局限在 CAP 问题上，还要关注零碎的扩展性、可用性等等

在零碎产生“分区”的状况下，CAP 实践只能满足 CP 或者 AP。要留神的是，这里的前提是零碎产生了“分区”

如果零碎没有产生“分区”，节点间的网络连接通信失常的话，也就不存在 P 了。这个时候，咱们就能够同时保障 C 和 A 了。

总结： 如果零碎产生“分区”，咱们要思考抉择 CP 还是 AP。如果零碎没有产生“分区”的话，咱们要思考如何保障 CA。

举荐浏览

1. CAP 定理简化（英文，乏味的案例）
2. 神一样的 CAP 实践被利用在何方（中文，列举了很多理论的例子）
3. 请进行呼叫数据库 CP 或 AP（英文，带给你不一样的思考）
4. java 基础教育