看完这篇，保证让你真正明白：分布式系统的CAP理论，java面试需要注意什么

最新推荐文章于 2024-08-30 22:32:28 发布

2401_84002730

最新推荐文章于 2024-08-30 22:32:28 发布

阅读量853

点赞数 27

分类专栏： 2024年程序员学习文章标签： java 面试开发语言

本文链接：https://blog.csdn.net/2401_84002730/article/details/137608447

版权

2024年程序员学习专栏收录该内容

211 篇文章 0 订阅

订阅专栏

这是个什么概念呢？就是她打破了那些既想提供超高质量服务，又想提供超高性能服务的技术人员的幻想。

这本质是在告诉大家，在分布式系统里，需要妥协。

但是，如何妥协？分布式系统里到底应该怎么权衡这种 trade-off？

我们可以想象一下，在 CAP 定理提出之前，没有这些方向性的指引，在设计和实施分布式系统时该有多么混乱。一套分布式系统是由多个模块组成的，这些模块本身可能由不同的开发人员去完成。然而，对于这些人，在公共层面，竟然没有一个原则去指导他们该怎么完成这套功能。

比如，我们在同步两个节点的数据时，如果发生了错误，到底我们应该怎么做呢？如果没有统一的标准和方向，那很可能在一套分布式系统中的不同模块，会出现不同的处理情况。

假设一套系统，由 A、B 两个模块构成。

A 模块的设计理念是：节点间出现了问题，它可能会选择不断的重试，一直等到节点通信恢复。

而 B 的设计理念是：节点间出现了问题，它断开就是了，可能最多就记录下状态，等以后处理。

可是，当 A、B 之间出现了通信怎么办？那会出现 A 往 B 发请求，出问题会不断重试。而 B 往 A 发请求，出问题则直接断开的情况。

当然，在后面我们会说明，CAP 的理念在实际工程中，会允许这种不一致。可是，那种不一致是提前设计好和规划好的，是根据实际数据的重要性和业务需求做的妥协，而不是这种混乱的妥协。

所以，IT 界的人们就一直在摸索，试图找到一些纲领去指导分布式系统的设计，这一找就找了 15 年。

2000 年时，Eric Brewer 教授在 PODC 会议上提出了 CAP 理论，但是由于没有被证明过，所以，当时只能被称为 CAP 猜想。这个猜想引起了巨大的反响，因为 CAP 很符合人们对设计纲领的预期。

在 2002 年后，经过 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP 猜想后，CAP 理论正式成为了分布式系统理论的基石之一。

2. CAP 到底是什么

CAP 定理表达了一个分布式系统里不可能同时满足以下的三个特性：

2.1. C：数据一致性

什么是数据一致性？咋一看真的很让人糊涂，一致性是什么？是指数据能一起变化，是能让数据整齐划一。

那么问题又来了，数据何时会变化？数据怎么才能被称为一起变化？我们现在来回答这些问题，当我们搞清楚了这些问题，那么对数据一致性就会有了清晰的理解。

首先第一个问题，数据何时会一起变化？

答案是：仅且仅当包含数据的服务，收到数据更新请求的时候，数据才会发生变化。而数据更新请求则仅包括数据的增、删、改这三种请求，而这三种请求又被统称为写请求。所以，数据只有在写请求的时候才会发生变化。

那我们来回答第二个问题，数据要怎么样才能被称为一起变化了？即谁来判断数据是最终变化了？是服务器对写请求的返回结果吗？告诉写请求成功，数据就一定发生一致性变化了？

NO，数据发生变化是否一致是需要经过读请求来做检验的。那么读请求判断的依据是什么呢？

假设，我们的分布式存储系统有两个节点，每个节点都包含了一部分需要被变化的数据。如果经过一次写请求后，两个节点都发生了数据变化。然后，读请求把这些变化后的数据都读取到了，我们就把这次数据修改称为数据发生了一致性变化。

但是，这还不是完整的一致性。因为系统不可能永久的正常运行下去。

如果系统内部发生了问题从而导致系统的节点无法发生一致性变化会怎么样呢？当我们这样做的时候，就意味着想看到最新数据的读请求们，很可能会看到旧数据，或者说获取到不同版本的数据。此时，为了保证分布式系统对外的数据一致性，于是选择不返回任何数据。

这里需要注意一下，CAP 定理是在说在某种状态下的选择，和实际工程的理论是有差别的。上面描述的一致性和 ACID 事务中的一致性是两回事。事务中的一致性包含了实际工程对状态的后续处理。但是 CAP 定理并不涉及到状态的后续处理，对于这些问题，后续出现了 BASE 理论等工程结论去处理，目前，只需要明白 CAP 定理主要描述的是状态。

2.2. A：可用性

奥维德曾经说过：“行动被人们遗忘，结果却将永存”。

这句话说明了结果的重要性，而可用性在 CAP 里就是对结果的要求。它要求系统内的节点们接收到了无论是写请求还是读请求，都要能处理并给回响应结果。只是它有两点必须满足的条件：

条件 1：返回结果必须在合理的时间以内，这个合理的时间是根据业务来定的。业务说必须 100 毫秒内返回，合理的时间就是 100 毫秒，需要 1 秒内返回，那就是 1 秒，如果业务定的 100 毫秒，结果却在 1 秒才返回，那么这个系统就不满足可用性。

条件 2：需要系统内能正常接收请求的所有节点都返回结果。这包含了两重含义：

如果节点不能正常接收请求了，比如宕机了，系统崩溃了，而其他节点依然能正常接收请求，那么，我们说系统依然是可用的，也就是说，部分宕机没事儿，不影响可用性指标。
如果节点能正常接收请求，但是发现节点内部数据有问题，那么也必须返回结果，哪怕返回的结果是有问题的。比如，系统有两个节点，其中有一个节点数据是三天前的，另一个节点是两分钟前的，如果，一个读请求跑到了包含了三天前数据的那个节点上，抱歉，这个节点不能拒绝，必须返回这个三天前的数据，即使它可能不太合理。

2.3. P：分区容忍性

分布式的存储系统会有很多的节点，这些节点都是通过网络进行通信。而网络是不可靠的，当节点和节点之间的通信出现了问题，此时，就称当前的分布式存储系统出现了分区。但是，值得一提的是，分区并不一定是由网络故障引起的，也可能是因为机器故障。

比如，我们的分布式存储系统有 A、B 两个节点。那么，当 A、B 之间由于可能路由器、交换机等底层网络设备出现了故障，A 和 B 通信出现了问题，但是 A、B 依然都在运行，都在对外提供服务。这时候，就说 A 和 B 发生了分区。

还有一种情况也会发生分区，当 A 出现了宕机，A 和 B 节点之间通信也是出现了问题，那么我们也称 A 和 B 发生了分区。

综上，我们可以知道，只要在分布式系统中，节点通信出现了问题，那么就出现了分区。

那么，分区容忍性是指什么？它是说，如果出现了分区问题，我们的分布式存储系统还需要继续运行。不能因为出现了分区问题，整个分布式节点全部就熄火了，罢工了，不做事情了。

3. CAP 怎么选择

我们上面已经知道了，在设计分布式系统时，架构师们在 C、A、P 这三种特性里，只能选择两种。

但是，这道 CAP 的选择题，就像别人在问你“小明的父亲有三个孩子，老大叫大朗，老二叫二郎，请问老三叫什么”一样。在以分布式存系统为限定条件的 CAP 世界里，P 是早已经确定的答案，P 是必须的。

因为，在分布式系统内，P 是必然的发生的，不选 P，一旦发生分区错误，整个分布式系统就完全无法使用了，这是不符合实际需要的。所以，对于分布式系统，我们只能能考虑当发生分区错误时，如何选择一致性和可用性。

而根据一致性和可用性的选择不同，开源的分布式系统往往又被分为 CP 系统和 AP 系统。

当一套系统在发生分区故障后，客户端的任何请求都被卡死或者超时，但是，系统的每个节点总是会返回一致的数据，则这套系统就是 CP 系统，经典的比如 Zookeeper。

如果一套系统发生分区故障后，客户端依然可以访问系统，但是获取的数据有的是新的数据，有的还是老数据，那么这套系统就是 AP 系统，经典的比如 Eureka。

说了这么多，其实 CAP 定理本质很简单，它就是一种分布式系统设计的不同理念概括，包括它说的一致性，可用性和分区容错性。这就类似一个大学的校训，是极度概念化的东西。

所以，大白话来形容下 CAP 吧，CAP 就是告诉程序员们当分布式系统出现内部问题了，你要做两种选择：

要么迁就外部服务，像外包公司。
要么让外部服务迁就你，像银行。

迁就外部服务就是我们不能因为我们自己的问题让外部服务的业务运行受到影响，所以要优先可用性。而让外部服务迁就我们，就要优先一致性。

4. 对 CAP 的常见误解

误解一：分布式系统因为 CAP 定理放弃了 C 或者 A 中的其中一个

很多人在没有对 CAP 做深入了解的情况下，听到很多人说分布式系统必须在 CAP 三个特性里选择两个，就觉得一套分布式系统肯定要么只有可用性要么只有一致性，不存在完整的可用性和一致性功能。

这种理解是大有问题的。因为，P 这种问题发生的概率非常低，所以：

当没有出现分区问题的时候，系统就应该有完美的数据一致性和可用性。

你什么时候见过一个系统，当内部没有问题的时候，会经常让外部请求卡一下的？要么就冷不丁的提供陈旧的老数据？那还能叫系统吗？

误解二：C 和 A 之间的选择是针对整个分布式系统的，只能整体考虑 C 和 A 之间的选择

这个理解也是不对的。当分区发生的时候，其实对一致性和可用性的抉择是局部性的，而不是针对整个系统的。

可能是在一些子系统做一些抉择，甚至很可能只需要对某个事件或者数据，做一致性和可用性的抉择而已。

比如，当我们做一套支付系统的时候，会员的财务相关像账户余额，账务流水是必须强一致性的。这时候，你就要考虑选 C。但是，会员的名字，会员的支付设置就不必考虑强一致性，可以选择可用性 A。

一套分布式系统的运行，就像人生一样，就是一次又一次的选择。在不同阶段，不同的时刻有不同的事件发生的时候，又怎么可能会有完全一样的选择呢？

误解三：CAP 的三个特性只有是和否两种极端选择，而不是一个范围

这种二元性的理解更是极其误导人。

CAP 理论的三种特性不是 Boolean 类型的，不是一致和不一致，可用和不可用，分区和没分区的这类二选一的选项。而是这三种特性都是范围类型。

拿可用性来说，就像我从银行取钱。当我目的是派发压岁钱的时候，我很可能就想全要新票子，但是，新票子很可能就还得多一个步骤，就是需要拿旧票子去换一些新票，此时，我可以多等会儿，能拿到新票子就好。而当我的目的就是做生活花销的时候，票子是新是旧，我根本不那么关心，快点拿到钱就行。这就是可用性的范围需求之一，对时延性的要求。

再比如，分区容错则由于探测机制的问题，可能还得各节点搞投票去协商分区是否存在，当某一台机器出现了问题，可能不影响业务的话，就会被机器投票认为分区不存在。然后一直等到多数机器出现了问题，才会投票确认出现了分区问题。这就好像新冠疫情，还会分低、中、高风险区呢，不是一出现通信故障就都被逻辑认定为分区问题。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。