差点跪了！阿里3面真题：CAP和BASE理论了解么？能够结合实际案例说下不？

本文节选自我开源的 JavaGuide ：https://github.com/Snailclimb/JavaGuide （Github标星92k+!一份涵盖大部分 Java 程序员所须要掌握的核心知识。准备 Java 面试，首选 JavaGuide！）

经历过技术面试的小伙伴想必对这个两个概念已经再熟悉不过了！

Guide哥当年参加面试的时候，不夸张地说，只要问到分布式相关的内容，面试官几乎是一定会问这两个分布式相关的理论。

而且，这两个理论也能够说是小伙伴们学习分布式相关内容的基础了！

所以，小伙伴们很是很是有必要将这理论搞懂，而且可以用本身的理解给别人讲出来。

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

我的能力有限。若是文章有任何须要改善和完善的地方，欢迎在评论区指出，共同进步！——爱大家的Guide哥

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 （英文，带给你不同的思考）

BASE 理论

BASE 理论起源于 2008 年， 由eBay的架构师Dan Pritchett在ACM上发表。

简介

BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大下降了咱们对系统的要求。

BASE 理论的核心思想

即便没法作到强一致性，但每一个应用均可以根据自身业务特色，采用适当的方式来使系统达到最终一致性。

也就是牺牲数据的一致性来知足系统的高可用性，系统中一部分数据不可用或者不一致时，仍须要保持系统总体“主要可用”。

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。

为何这样说呢？

CAP 理论这节咱们也说过了：

若是系统没有发生“分区”的话，节点间的网络链接通讯正常的话，也就不存在 P 了。这个时候，咱们就能够同时保证 C 和 A 了。所以，若是系统发生“分区”，咱们要考虑选择 CP 仍是 AP。若是系统没有发生“分区”的话，咱们要思考如何保证 CA 。

所以，AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。

BASE 理论三要素

1. 基本可用

基本可用是指分布式系统在出现不可预知故障的时候，容许损失部分可用性。可是，这毫不等价于系统不可用。

什么叫容许损失部分可用性呢？

• 响应时间上的损失: 正常状况下，处理用户请求须要 0.5s 返回结果，可是因为系统出现故障，处理用户请求的时间变为 3 s。
• 系统功能上的损失：正常状况下，用户可使用系统的所有功能，可是因为系统访问量忽然剧增，系统的部分非核心功能没法使用。

2. 软状态

软状态指容许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的总体可用性，即容许系统在不一样节点的数据副本之间进行数据同步的过程存在延时。

3. 最终一致性

最终一致性强调的是系统中全部的数据副本，在通过一段时间的同步后，最终可以达到一个一致的状态。所以，最终一致性的本质是须要系统保证最终数据可以达到一致，而不须要实时保证系统数据的强一致性。

分布式一致性的 3 种级别：

1. 强一致性 ：系统写入了什么，读出来的就是什么。

2. 弱一致性 ：不必定能够读取到最新写入的值，也不保证多少时间以后读取到的数据是最新的，只是会尽可能保证某个时刻达到数据一致的状态。

3. 最终一致性 ：弱一致性的升级版。，系统会保证在必定时间内达到数据一致的状态，

业界比较推崇是最终一致性级别，可是某些对数据一致要求十分严格的场景好比银行转帐仍是要保证强一致性。

总结

ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。

图解计算机基础+我的原创的 Java 面试手册PDF版。

微信搜“JavaGuide”回复“计算机基础”便可获取图解计算机基础+我的原创的 Java 面试手册。