本文节选自我开源的 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…。
- ZooKeeper 保障的是 CP。 任何时刻对 ZooKeeper 的读申请都能失去一致性的后果，然而， ZooKeeper 不保障每次申请的可用性比方在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。
- Eureka 保障的则是 AP。 Eureka 在设计的时候就是优先保障 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因而 Eureka 不会像 ZooKeeper 那样呈现选举过程中或者半数以上的机器不可用的时候服务就是不可用的状况。 Eureka 保障即便大部分节点挂掉也不会影响失常提供服务，只有有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。
- Nacos 不仅反对 CP 也反对 AP。
总结
在进行分布式系统设计和开发时，咱们不应该仅仅局限在 CAP 问题上，还要关注零碎的扩展性、可用性等等
在零碎产生“分区”的状况下，CAP 实践只能满足 CP 或者 AP。要留神的是，这里的前提是零碎产生了“分区”
如果零碎没有产生“分区”的话，节点间的网络连接通信失常的话，也就不存在 P 了。这个时候，咱们就能够同时保障 C 和 A 了。
总结：如果零碎产生“分区”，咱们要思考抉择 CP 还是 AP。如果零碎没有产生“分区”的话，咱们要思考如何保障 CA 。
举荐浏览
- CAP 定理简化 （英文，乏味的案例）
- 神一样的 CAP 实践被利用在何方 （中文，列举了很多理论的例子）
- 请进行呼叫数据库 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 种级别：
- 强一致性 ：零碎写入了什么，读出来的就是什么。
- 弱一致性 ：不肯定能够读取到最新写入的值，也不保障多少工夫之后读取到的数据是最新的，只是会尽量保障某个时刻达到数据统一的状态。
- 最终一致性 ：弱一致性的升级版。，零碎会保障在肯定工夫内达到数据统一的状态，
业界比拟推崇是最终一致性级别，然而某些对数据统一要求非常严格的场景比方银行转账还是要保障强一致性。
总结
ACID 是数据库事务完整性的实践，CAP 是分布式系统设计实践，BASE 是 CAP 实践中 AP 计划的延长。
图解计算机根底+集体原创的 Java 面试手册PDF版。
微信搜“JavaGuide”回复“计算机根底”即可获取图解计算机根底+集体原创的 Java 面试手册。
