CAP 和 BASE 理论重构

Snailclimb · Snailclimb · commit d14744c08879 · 2020-11-24T22:14:57.000+08:00
diff --git a/docs/system-design/high-availability/BASE理论.md b/docs/system-design/high-availability/BASE理论.md
@@ -1,10 +1,16 @@
-## 简介
+## BASE 理论
+
+[BASE 理论](https://dl.acm.org/doi/10.1145/1394127.1394128)起源于 2008 年， 由eBay的架构师Dan Pritchett在ACM上发表。
+
+### 简介
 
 **BASE** 是 **Basically Available（基本可用）** 、**Soft-state（软状态）** 和 **Eventually Consistent（最终一致性）** 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。
 
-## BASE 理论的核心思想
+### BASE 理论的核心思想
+
+即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
 
-即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。
+> 也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。
 
 **BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。**
 
@@ -16,11 +22,11 @@ CAP 理论这节我们也说过了：
 
 因此，AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。
 
-## BASE 理论三要素
+### BASE 理论三要素
 
 ![BASE理论三要素](https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAxOC81LzI0LzE2MzkxNDgwNmQ5ZTE1YzY?x-oss-process=image/format,png)
 
-### 1. 基本可用
+#### 1. 基本可用
 
 基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。
 
@@ -29,22 +35,24 @@ CAP 理论这节我们也说过了：
 - **响应时间上的损失**: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
 - **系统功能上的损失**：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。
 
-### 2. 软状态
+#### 2. 软状态
 
 软状态指允许系统中的数据存在中间状态（**CAP 理论中的数据不一致**），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
 
-### 3. 最终一致性
+#### 3. 最终一致性
 
 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
 
 > 分布式一致性的 3 种级别：
 >
 > 1. **强一致性** ：系统写入了什么，读出来的就是什么。
+>
 > 2. **弱一致性** ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
+>
 > 3. **最终一致性** ：弱一致性的升级版。，系统会保证在一定时间内达到数据一致的状态，
 >
-> 业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。
+> **业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。**
 
-## 总结
+### 总结
 
 **ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。**
diff --git a/docs/system-design/high-availability/CAP理论.md b/docs/system-design/high-availability/CAP理论.md
@@ -1,26 +1,44 @@
-![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-11/cap.png)
+经历过技术面试的小伙伴想必对这个两个概念已经再熟悉不过了！
+
+Guide哥当年参加面试的时候，不夸张地说，只要问到分布式相关的内容，面试官几乎是必定会问这两个分布式相关的理论。
+
+并且，这两个理论也可以说是小伙伴们学习分布式相关内容的基础了！
+
+因此，小伙伴们非常非常有必要将这理论搞懂，并且能够用自己的理解给别人讲出来。
+
+这篇文章我会站在自己的角度对这两个概念进行解读！
+
+*个人能力有限。如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！——爱你们的Guide哥*
+
+## CAP理论
+
+[CAP 理论/定理](https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86)起源于 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 三个单词的明确定义。
+![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-11/cap.png)
+
+CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细定义 **Consistency**、**Availability**、**Partition Tolerance** 三个单词的明确定义。
 
 因此，对于 CAP 的民间解读有很多，一般比较被大家推荐的是下面 👇 这种版本的解。
 
-在理论计算机科学中，CAP 定理（CAP theorem），又被称作 **布鲁尔定理（Brewer’s theorem）**，它指出对于一个分布式系统来说，当设计读写操作时，只能能同时满足以下三点中的两个：
+在理论计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能能同时满足以下三点中的两个：
 
 - **一致性（Consistence）** : 所有节点访问同一份最新的数据副本
-- **可用性（Availability）**: 非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。
+- **可用性（Availability）**: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
 - **分区容错性（Partition tolerance）** : 分布式系统出现网络分区的时候，仍然能够对外提供服务。
 
-CAP 仅适用于原子读写的 NOSQL 场景中，并不适合数据库系统。现在的分布式系统具有更多特性比如扩展性、可用性等等，在进行系统设计和开发时，我们不应该仅仅局限在 CAP 问题上。
-
 **什么是网络分区？**
 
 > 分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区。
 
-## 不是所谓的“3 选 2”
+![partition-tolerance](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-11/partition-tolerance.png)
+
+### 不是所谓的“3 选 2”
 
 大部分人解释这一定律时，常常简单的表述为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上这是一个非常具有误导性质的说法，而且在 CAP 理论诞生 12 年之后，CAP 之父也在 2012 年重写了之前的论文。
 
@@ -36,7 +54,7 @@ CAP 仅适用于原子读写的 NOSQL 场景中，并不适合数据库系统。
 
 **选择的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证 CP 。**
 
-## CAP 实际应用案例
+### CAP 实际应用案例
 
 我这里以注册中心来探讨一下 CAP 的实际应用。考虑到很多小伙伴不知道注册中心是干嘛的，这里简单以 Dubbo 为例说一说。
 
@@ -52,13 +70,17 @@ CAP 仅适用于原子读写的 NOSQL 场景中，并不适合数据库系统。
 2. **Eureka 保证的则是 AP。** Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。 Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。
 3. **Nacos 不仅支持 CP 也支持 AP。**
 
-## 总结
+### 总结
+
+在进行分布式系统设计和开发时，我们不应该仅仅局限在 CAP 问题上，还要关注系统的扩展性、可用性等等
 
 在系统发生“分区”的情况下，CAP 理论只能满足 CP 或者 AP。要注意的是，这里的前提是系统发生了“分区”
 
-如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。因此，**如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。**
+如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。
+
+总结：**如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。**
 
-## 推荐阅读
+### 推荐阅读
 
 1. [CAP 定理简化](https://medium.com/@ravindraprasad/cap-theorem-simplified-28499a67eab4) （英文，有趣的案例）
 2. [神一样的 CAP 理论被应用在何方](https://juejin.im/post/6844903936718012430) （中文，列举了很多实际的例子）
