GuilinDev
Cap Theorem
11 July 2020
CAP定理也称为Brewer定理，是由计算机科学家Eric Brewer在2000年分布式计算原理研讨会上提出的。 在CAP定理中，分布式系统有三个指标:
- Consistency 一致性
- Availability 可用性
- Partition tolerance 分区容忍性
一致性
每次读取都会收到最新的写入或错误，也就是在写操作完成之后开始的任何读操作都必须返回该值，或之后写操作的结果。 在保持一致性的系统中，客户端将值写入任何服务器并获得响应后，它期望从其读取的任何服务器中获取该值（或更新鲜的值）。
需要注意，CAP定理中定义的一致性与数据库事务中保证的ACID一致性完全不同。
可用性
系统中非故障节点收到的每个请求都必须产生响应。无论clients想读还是写，都会得到一些回复。 在可用性系统中，如果我们的客户端向服务器发送请求并且服务器没有崩溃，则服务器最终必须响应客户端。不允许服务器忽略客户端的请求。
分区容错性
区间通信可能失败，也就是尽管节点之间的网络丢掉或延迟了任意数量的消息，但系统仍能继续运行。 在对网络进行分区时，从该分区的一个组件中的节点发送到另一组件中的节点的所有消息都丢失。
理解
CAP定理指出，分布式系统不可能同时提供以上三个保证中的两个以上。
设想，假设我们有一个非常简单的分布式系统，其中只有两个服务器S1和S2，并且假定我们的分布式系统同时是“一致的”，“可用的”和“分区容错的”。
假设存在网络故障，因为我们的系统可以分区容错，因此它可以正常工作。在网络故障期间，客户端向服务器S1发送写请求。 S1将收到请求并进行处理。 同时我们的系统是一致的，因此S1必须在向客户端确认之前更新S2中的值，但是S1无法更新S2，因为存在网络故障。在这种情况下，对S1的请求将超时，这意味着我们的系统不可用。 而如果我们的系统可用，则S1将响应客户端，而无需等待S2中的更新。如果任何客户端向S2发出读取请求以获取相同的信息，它将收到较旧的值，而不是最近写入的结果。 这意味着我们的系统在可用时无法保持一致。
所以，这证明了分布式系统不可能同时提供一致性，可用性和分区容错性。
分布式系统应用
所有分布式系统都需要提供分区容错性，因为没有分布式系统可以完全防止网络故障。在存在分区容错性的情况下，我们可以从一致性和可用性中选择一个。
CAP定理经常被误解为必须一直选择三个中的两个，但实际上，只有在网络分区或发生故障时，才必须在一致性和可用性之间进行选择。 而如果在没有网络分区或网络故障的情况下，可用性和一致性都可以满足。
在存在分区错误的情况下，选择一致性或可用性的情况：
AP（可用性和分区容错性）：当选择可用性而不是一致性时，系统将始终处理客户端请求并尝试返回信息的最新可用版本，即使由于网络分区而造成了返回的结果不一定是最新的。
CP（一致性和分区容错性）：当选择一致性而不是可用性时，如果由于网络分区或故障而无法将特定信息更新到其他节点，则系统将对客户请求返回错误或超时的信息。
提供ACID特性设计的数据库系统(RDBMS)通常选择一致性而不是可用性，而使用BASE(Basically Available, Soft state, Eventual consistency)设计原则的系统与ACID相反， 选择可用性而不是一致性(是最终一致性)。这样起名的原因是在化学中，简写ACID指酸性物质，BASE则是碱性物质。