分布式-CAP定理

article/2025/9/24 15:53:49

在分布式学习中，我们经常遇到一个概念便是CAP，它是分布式很重要的理论基础。很多分布式算法也是在不断的在解决相关问题，今天就让我们重新学习或者回顾一下这个知识点吧，加深印象打牢基础。

一、简介

CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），由计算机科学家 Eric Brewer 在 2000 年分布式计算原理研讨会上提出。这三个值指的是分布式系统的中，一致性 (Consistency)，可用性 (Availability)，P代表分区容错性 (Partition tolerance)。CAP理论告诉我们C、A、P三者不能同时满足，最多只能满足其中两个。

note: CAP 定理中定义的一致性与 ACID 数据库事务中保证的一致性完全不同。

1.1. Consistency(一致性):
描述: "all nodes see the same data at the time".
解释：即更新操作成功返客户端后，所有节点在同一时间的数据是完全一致的，这就是分布式的一致性(强一致，由于一致性的类别特别多，希望读者在阅读是进行详细区分这样便于理解)
介绍: 一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问是更新过的数据如何获取的问题。从服务端来说，则是更新的数据如何同步到分布式的整个系统中，以保证任何时刻返回的数据的一致。

1.2.Availability(可用性):
描述:"Reads and wirtes always succeed".
解释：即服务一直可用，而且是正常的响应时间。
介绍: 我遇到很多人，在这点上只知道服务的可用，却忽略了正常的响应时间。希望读者在这一点上切记。好的可用性主要指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等不好的用户体验情况。

1.3 Partition tolerance(分区容错性):
解释: 分布式系统在某个节点或者网络分区故障的时候，依然能够堆外提供满足一致性或可用性的服务。
介绍: 尽管节点之间的网络丢弃（或延迟）任意数量的消息，系统仍继续运行。当网络被分区时，从分区的一个组件中的节点发送到另一个组件中的节点的所有消息都将丢失。比如现在的分布式系统中有某一个或几个机器宕机了，其他剩下的机器还能正常运行满足系统需求，对用户而言并没有什么使用上的影响。

二、CAP 三选二

下面举个例子，也方便大家理解为什么CAP只能三选二。

案例:
理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

在存在分区的情况下，剩下两个选项一致性和可用性。
AP（Availability and Partition tolerance）：当可用性高于一致性时，系统将始终处理客户端请求并尝试返回最新可用版本的信息，即使由于网络分区而无法保证它是最新的.

CP（一致性和分区公差）：如果选择一致性而不是可用性，则系统将返回错误或超时，如果由于网络分区或故障而无法更新到其他节点，则该系统将返回错误或超时。

三、深入理解CAP

引用: Eric Brewer argues that the often-used "two out of three" concept can be somewhat misleading because system designers only need to sacrifice consistency or availability in the presence of partitions, but that in many systems partitions are rare。

解释:
Eric Brewer认为，经常使用的“三分之二”概念可能会有些误导，因为系统设计人员只需要在存在分区的情况下,牺牲一致性或可用性，但在许多系统中分区很少见。

介绍:
CAP 定理经常被误解为必须始终在三个保证中选择两个。实际上，只有在网络分区或发生故障时，才需要在一致性和可用性之间进行选择。在没有网络分区或网络故障的情况下，可以同时满足可用性和一致性。即一致性和可用性并不是水火不容，非此即彼的。Paxos、Raft等分布式一致性算法就是在一致性和可用性之间做到了很好的平衡的见证。
关于Paxos的内容，读者可以阅读“分布式算法-Paxos”。