聊一聊分布式系统中的CAP和BASE理论

偏执的太偏执、 2022-10-15 13:52 119阅读 0赞

### 目录 ###

什么是分布式系统？

在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。

CAP是什么？什么是CAP理论？

CAP理论又被称作布鲁尔定理，是由加州大学伯克利分校的Eric Brewer教授在分布式计算原理研讨会（PODC）上提出。

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

**一致性（C）**：在分布式系统中的所有数据备份能够保证一致（意味着所有节点访问读到的就像是“同一份数据副本”）

其实很简单，G1、G2都可看成保存数据的地方，客户端访问G1，会修改到G1的数据为V1

![21d260f13ed5a03f6f5fe80bac1ff096.png][]

此时，满足一致性的表先就是，G2也会同步更改，即当读G2时，读到的是V1

![c2864f79cd2639b2bd9fb325027d20e3.png][]

**可用性（A）**：保证每个请求不管成功或者失败都有响应，换句话说，是只要收到用户的请求，服务器就必须给出回应。

**分区容忍性（P）**：系统中任意信息的丢失或失败不会影响系统的继续运作。

解释完CAP，说一下**CAP理论**，它是指这三个特性**不可能同时都满足**。

![image-20210219212628526][]

为什么CAP不可以同时满足？

不可以同时满足主要原因是可能通信失败（即出现分区容错），此时一致性C和可用性A不可以同时满足。

若想满足C，一个数据结点被写数据时，另一个数据结点必须同步，即不可以进行读写操作，这样的话就不可以回应任何请求，即不可能满足A。

搞懂上面，下面就好懂了，若想满足A，就无法保证数据同步，即一致性。

所以，事实上，CAP**并不是指单单的3选2，因为不可能出现CA的情况**。

如何权衡C和A？

事实上，如果系统发生“分区容错”，我们要考虑选择 CP 还是 AP,这时才需要权衡C和A。

如果系统没有发生“分区容错”的话，就要思考如何保证 CA。

而选择的关键点事实上取决于业务场景

对于大多数互联网应用来说（如网易门户），因为机器数量庞大，部署节点分散，网络故障是常态，可用性是必须需要保证的，所以只有设置一致性来保证服务的AP，常见的高可用服务一半都是放弃C选择AP。

对于需要确保强一致性的场景，如银行，通常会权衡CA和CP模型，CA模型网络故障时完全不可用，CP模型具备部分可用性，实际的选择需要通过业务场景来权衡（并不是所有情况CP都好于CA，只能查看信息不能更新信息有时候从产品层面还不如直接拒绝服务）

CAP 实际应用案例

我这里以注册中心来探讨一下 CAP 的实际应用。考虑到很多小伙伴不知道是干嘛的，我们以 Dubbo 为中的注册中心说一说。

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

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

![img][]

常见的可以作为注册中心的组件有：ZooKeeper、Eureka、Nacos…。

**ZooKeeper 保证的是 CP。** 任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是， ZooKeeper 不保证每次请求的可用性，比如在 **Leader 选举过程中或者半数以上的机器不可用的时候，服务就是不可用的。**

**Eureka 保证的则是 AP。** Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。 Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。

**Nacos 不仅支持 CP 也支持 AP,他可以进行两种模式的切换**

BASE理论是什么？

与CAP一样,**BASE** 是 **Basically Available（基本可用）** 、**Soft-state（软状态）** 和 **Eventually Consistent（最终一致性）** 三个短语的缩写。

BASE 理论是**对 CAP 中一致性 C 和可用性 A 权衡的结果**，，是基于 CAP 定理逐步演化而来的，虽然基于CAP理论无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

![image-20210219220308026][]

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

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

**最终一致性**：最终一致性强调的是系统中所有的数据副本，在**经过一段时间的同步**后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而**不需要实时保证系统数据的强一致性。**

BASE理论的特点

BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全**不同**于 ACID 的**强一致性**模型，而是通过**牺牲强一致性来获得可用性**，并**允许数据在一段时间是不一致的。**

参考

部分内容参考链接如下，除此之外，非常感谢下面的博文给予了我很大的点拨！

[阮一峰的网络日志—CAP理论][CAP]

[CAP百度百科][CAP 1]

[Github-JavaGuide-CAP][]

[Github-JavaGuide-BASE][]

[21d260f13ed5a03f6f5fe80bac1ff096.png]: /images/20221014/df10014a75184fc38305109e07819bf3.png
[c2864f79cd2639b2bd9fb325027d20e3.png]: /images/20221014/31cd4c3521124f0ab8f58b4f619889c0.png
[image-20210219212628526]: /images/20221014/c7e5426bb8e9431787fba2046bab254d.png
[img]: /images/20221014/bb7b14b040504338a5b662213c1a7f46.png
[image-20210219220308026]: /images/20221014/b4a9156bd04a482aa22277cb578f681a.png
[CAP]: http://www.ruanyifeng.com/blog/2018/07/cap.html
[CAP 1]: https://baike.baidu.com/item/CAP%E5%8E%9F%E5%88%99/5712863?fr=aladdin
[Github-JavaGuide-CAP]: https://gitee.com/SnailClimb/JavaGuide/blob/master/docs/system-design/distributed-system/CAP%E7%90%86%E8%AE%BA.md
[Github-JavaGuide-BASE]: https://gitee.com/SnailClimb/JavaGuide/blob/master/docs/system-design/distributed-system/BASE%E7%90%86%E8%AE%BA.md