想成为架构师，你必须知道CAP理论

CAP 理论

第一版解释：

Any distributed system cannot guaranty C, A, and P simultaneously.

简单翻译为：对于一个分布式计算系统，不可能同时满足一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三个设计约束。

第二版解释：

In a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair: Consistency, Availability, and Partition Tolerance – one of them must be sacrificed.

简单翻译为：在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。

对比两个版本的定义，有几个很关键的差异点：

CAP 理论的第二版为了精确界定哪些分布式系统属于其讨论范围，特别强调了两个关键特征：系统间的互联（interconnected）和数据共享（share data）。这种明确性是因为并非所有的分布式系统都涉及这两个方面。例如，Memcache 的集群节点之间既不互联也不共享数据，因此不适用于CAP理论的讨论。相对地，MySQL集群通过节点间的互联和数据复制，符合CAP理论探讨的系统特性。

此外，第二版还特别指出了CAP理论主要关注系统中的读写操作对，而非分布式系统的所有功能。这意味着，像ZooKeeper中的选举机制这类功能，虽然是分布式系统的一部分，却不在CAP理论的讨论范围内。

第二版的这种定义使得理论本身更加精确。尽管第二版定义更严谨、更精细，使得理解和记忆相对困难，许多技术人员在讨论CAP理论时，依然倾向于使用第一版的定义和解释，因为它的表述更为简洁明了，易于理解和记忆。

第二版除了基本概念，三个基本的设计约束也进行了重新阐述，我来详细分析一下。

一致性（Consistency）

在CAP理论的第一版中，一致性被解释为：

All nodes see the same data at the same time.

所有节点在同一时刻都能看到相同的数据。

而第二版中，一致性的解释是：

A read is guaranteed to return the most recent write for a given client.

对于任何特定的客户端，读操作都能保证返回该客户端最近的写操作结果。

这两个版本的主要区别在于观察的视角和用词的精确性：

第一版是从节点（node）的角度来描述一致性，而第二版则是从客户端（client）的角度进行描述。第二版的视角更贴近我们评估和观察系统行为的常用方式。

在第一版中使用的关键词是“see”，而在第二版中则是“read”。在第一版中，“see”这个词并不准确，因为节点拥有数据，而非“看到”数据。如果描述的话，应该用“have”。而第二版则从客户端的读写操作来定义一致性，这使得定义更为精确。

第一版强调所有节点在同一时刻拥有相同的数据，而第二版并没有强调这一点。这表明在实际应用中，节点可能在同一时刻拥有不同的数据，这与我们通常理解的一致性有所差异。这样的改动背后的原因在于，在第一版的更详细解释中已经指出，系统在执行事务过程中可能会进入一个不一致的状态，但如果在事务的任何阶段出现错误，整个事务都会被回滚。

第一版的解释虽然简单明了，但并不够严谨，因为它假设了一个在实际中并不总是成立的情况——所有节点在同一时刻看到相同的数据。而第二版通过强调客户端能够在事务提交后访问到最新的写入数据，从而避开了事务过程中的数据不一致问题，提供了一个更准确的一致性定义。

2. 可用性（Availability）

第一版CAP理论对于可用性的定义是：

Every request gets a response on success/failure.

每个请求都会收到一个关于成功或失败的响应。

而第二版中对可用性的定义为：

A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).

在合理的时间内，任何非故障节点都会返回一个合理的响应（没有错误或超时）。

两个版本在表述上的主要差异体现在以下几点：

第一版使用“每个请求”（every request）的表述，而第二版特别指出了“非故障节点”（a non-failing node）。第一版的表述没有考虑到节点可能存在的故障状态，实际上，只有正常运行的节点才可能满足这种可用性的要求。如果节点已经处于故障状态，那么发往该节点的请求可能无法得到响应。
第一版将响应分为成功（success）和失败（failure），而第二版用了两个“合理”（reasonable）来形容响应和时间，并且明确指出响应不应该包含错误或超时。第一版中的成功与失败定义较为宽泛，几乎涵盖了所有可能的响应情况，包括超时、错误、异常等都被视为失败；即便是成功的响应，也不一定是准确的。例如，理论上应返回100，但如果实际返回了90，这虽然是一种成功的响应，但结果并非准确。相比之下，第二版的定义清晰地排除了错误和超时，强调响应应当是合理的，即使这种响应可能在逻辑上不完全正确，例如应返回100但实际返回90的情况，虽然不准确，但仍可能被视为合理。

这种变化在第二版中提供了更加明确和严格的定义，使得CAP理论在实际应用中更为实用，特别是在考量系统设计时对于异常处理和响应时间的预期管理上。

3. 分区容忍性（Partition Tolerance）

第一版CAP理论中对分区容错性的描述是：

System continues to work despite message loss or partial failure.

系统即便在消息丢失或部分故障的情况下也能继续运作。

而第二版中对此的描述是：

The system will continue to function when network partitions occur.

当网络分区发生时，系统将继续正常功能。

这两个版本在表述上的主要差异可以从以下几点观察：

第一版使用“运作”（work），而第二版使用“正常功能”（function）。在第一版中，“运作”可能仅仅意味着系统仍然处于活动状态，哪怕是返回错误或者拒绝服务也算是“运作”。而第二版中的“正常功能”则暗示系统不仅活跃，还需有效地履行其职责，提供合理的响应，这与可用性的定义更为吻合。这使得第二版的描述在表达上更为严谨和明确。

关于分区的表述，第一版用“消息丢失或部分失败”来描述导致的状况，而第二版则直接使用“网络分区”。第一版的描述比较侧重原因——即消息丢失作为触发网络分区的一种情况，但这种描述较为狭隘，因为消息丢失只是网络故障中可能的多种情况之一。第二版的描述从现象上定义问题，即不论导致网络分区的具体原因是什么，不管是由于消息丢失、连接中断还是网络拥塞，只要出现了网络分区，都包含在内。这样的描述更全面，也更符合实际系统可能遇到的各种网络问题。

这种表述的改变提供了更精确的理解，使得CAP理论在实际应用中更加明确，帮助系统设计者和开发者更好地理解和处理网络分区带来的挑战。

CAP 应用

在CAP理论中，三个要素—一致性（C）、可用性（A）和分区容忍性（P）中，只能同时满足两个。然而，在分布式系统的实际应用中，我们通常必须选择P（分区容忍）因为网络本质上无法保证百分之百的可靠性，分区故障是不可避免的。如果我们选择CA而不选择P，当网络分区发生时，为了维持一致性（C），系统可能需要阻止数据写入操作。这时，如果有写入请求，系统将不得不返回错误（如，“系统当前不接受写入”），这会与可用性（A）的要求发生冲突，因为A要求系统不返回错误且没有超时。因此，在理论上，分布式系统无法实现CA架构，只能选择CP（一致性和分区容忍性）或AP（可用性和分区容忍性）架构。

1.CP – Consistency/Partition Tolerance

如下所示，当网络分区发生导致N1节点上的数据更新为y，但因N1和N2之间的复制通道中断，更新的数据无法同步至N2，使得N2上的数据仍为x。此时，若客户端C尝试访问N2，N2会因为无法提供最新数据而返回错误，提示“系统当前存在故障”。这种做法违背了可用性（Availability）的原则，因此在CAP理论中，系统只能满足CP（一致性和分区容忍性）。

2.AP – 可用性/分区容忍性

如图所示，为了确保系统的可用性，在网络分区后，尽管N1节点的数据已更新为y，N1与N2之间的数据同步因中断而未能执行，导致N2节点上数据仍然是x。此时，若客户端C访问N2，N2会返回其当前所持有的旧数据x给客户端C。虽然这不是最新的数据y，但仍然是一个合理的返回，因为x是之前的有效数据，不是错误或混乱的数据。这种情况下，系统不满足一致性（Consistency）要求，因此CAP理论中只能满足AP（可用性和分区容忍性）。