CAP定理：为什么完美的分布式系统不存在？

欢迎大家来到IT世界,在知识的湖畔探索吧!

想象一下一个 Web 服务在北京和上海的数据中心之间复制其数据。北京访问北京数据中心并进行写入，上海用户尝试从上海数据中心读取数据。

欢迎大家来到IT世界,在知识的湖畔探索吧!

根据CAP：

• C 表示上海用户看到北京用户的最新写入。
• A 意味着上海数据中心立即向用户返回某些内容，即使不一致。
• P 表示即使北京-上海链路出现故障，Web 服务仍会继续工作。

CAP 代表什么？

CAP 定理是分布式系统如何工作的基本指南。在详细介绍之前，我们先解释一下 CAP 中的每个字母代表什么：

一致性
在一致性系统中，所有节点同时看到相同的数据。换句话说，当新数据添加到一个节点时，该更新必须快速与系统中的所有其他节点共享。

这意味着只有当系统中的所有节点都更新时，写入操作才算完成。

可用性
系统应该始终可以保持保持响应，每个读或写请求都能得到回复，确保系统保持功能正常且易于交互。

返回的数据可能并不是最新的，重要的是即使某些节点遇到问题，系统中的所有工作节点都正常响应。

分区容错性
分区容错就是节点出现问题（例如丢失消息或节点关闭），系统仍然保持运行。

简单来说，它是系统管理节点之间通信中断的方式，这在任何分布式系统中都必然会发生。

这就是为什么分区容错性是“必须具备”的因素。

CAP定理

分布式系统只能同时满足 3 个关键条件中的 2 个，但不可能同时满足全部三个。通常必须在一致性和可用性之间做出选择，分区容错是“必须具备的”的条件。

首先，让我们来解释一下什么是“网络分区”。

当系统中节点之间的通信不顺畅时就会发生这种情况。在这种情况下，很难说一个节点是完全崩溃还是面临其他问题。

由于这些通信问题必然会发生，因此拥有一个能够持续运行的系统至关重要。没有人希望他们的整个系统停止工作。

为什么只能满足2个？

在现实场景中，可以实现具有一致性的分区容错性，或具有可用性的分区容错性，但不能同时实现这三者，尤其是在出现网络问题时。

例子

假设我正在处理发生网络分区并且节点 A 没有响应或延迟的情况。它现在与节点 B、C 和 D 不同步，在这种情况下，它需要时间来赶上恢复并同步成功最新数据。

选择一致性

因此，如果优先考虑一致性，现在不会将请求路由到节点 A（系统应该返回错误或拒绝访问节点 A 的请求）。

我们希望所有节点同时显示相同的数据，因为这就是一致性的全部内容。这里的权衡是可用性，节点 A 在此期间不会响应客户端请求。

• 延迟：确保一致性会增加延迟，因为写入必须传播到所有副本节点才能被视为完成，这会使响应变慢。
• 吞吐量降低：由于等待所有节点的写入传播和确认，在较高的一致性下，整体系统吞吐量会降低。
• 可用性较低：在节点之间的网络故障期间，一致的系统可用性较低，因为某些请求被拒绝或超时以防止不一致。
• 成本增加：确保节点之间及时传播和协调所需的额外资源和基础设施增加了成本。

选择可用性

另一方面，如果可用性更重要，节点 A 将继续处理客户端请求并显示其拥有的最新数据。

缺点是这些数据可能与节点 B、C 和 D 上的数据不匹配，这违反了一致性规则：

• 不一致：在高可用性的情况下，如果更新尚未传播到所有节点，则读取可能会返回旧或不一致的数据，这违反了一致性。
• 冲突写入：冲突/覆盖写入的风险较高，因为允许异步写入而无需协调。
• 无错误处理：专注于响应所有请求，因此无法正确处理错误和异常。
• 无限制的陈旧性：通常，可用系统中返回的数据的陈旧程度没有限制，这就是为什么某些读取可能返回非常旧的数据的原因。
• 困难的冲突解决：如果没有强有力的协调，解决冲突的写入会更加困难。
• 数据完整性降低：如果没有一致的读/写，则强制约束和维护完整性变得更加困难，并且数据可能会损坏。

选择哪一种

不同的分布式系统对 CAP 定理的优先级不同，我们分解一下：

• CP（一致性，分区容错性）：像HBase这样的数据库优先考虑在所有节点上拥有最新的数据，可以放弃一些可用性。
• AP（可用性、分区容错性）：像 eureka这样的服务注册中心框架，它们的目标是即使在节点间的一致性可能滞后的情况下也能保持平稳运行，所以用AP。

如果您正在处理财务记录等重要数据，希望所有节点显示相同的信息，想象一下，一个节点显示余额是 1000 元，而另一个节点显示是 200元 ，那就不好了。所以，在这种情况下，选择 CP 是合适的。

但是，如果更关心流畅的用户体验，并且应用程序主要处理读取数据，那么 AP 更合适，尤其是当数据不重要且有点过时也没关系时。

但是，在 MongoDB、NACOS 这样的系统中，这不是一刀切的情况，这些系统的设计都是灵活的。我们可以根据关键操作选择强一致性，以及在快速响应更重要的情况下选择更宽松的设置。

这样，不必为整个系统坚持使用一种方法，不同的部分可以根据要求以不同级别的一致性或可用性运行。