共计 1628 个字符，预计需要花费 5 分钟才能阅读完成。
定义
在理论计算机科学中，CAP 定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点
选项
具体意义
一致性（Consistency）
所有节点访问同一份最新的数据副本
可用性（Availability）
每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据
分区容错性（Partition tolerance）
分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障
而 CAP 指的就是上述三个指标的首字母
分别解释每个指标
一致性（Consistency）
在写操作完成后开始的任何读操作都必须返回该值，或者后续写操作的结果也就是说，在一致性系统中，一旦客户端将值写入任何一台服务器并获得响应，那么之后 client 从其他任何服务器读取的都是刚写入的数据
用如下系统进行解释
客户端向 G1 写入数据 v1，并等待响应
此时，G1 服务器的数据为 v1，而 G2 服务器的数据为 v0，两者不一致
接着，在返回响应给客户端之前，G2 服务器会自动同步 G1 服务器的数据，使得 G2 服务器的数据也是 v1
一致性保证了不管向哪台服务器（比如这边向 G1）写入数据，其他的服务器（G2）能实时同步数据
G2 已经同步了 G1 的数据，会告诉 G1，我已经同步了
G1 接收了所有同步服务器的已同步的报告，才将“写入成功”信息响应给 client
client 再发起请求，读取 G2 的数据
此时得到的响应是 v1，即使 client 从未写入数据到 G2
可用性（Availability）
系统中非故障节点收到的每个请求都必须有响应在可用系统中，如果我们的客户端向服务器发送请求，并且服务器未崩溃，则服务器必须最终响应客户端，不允许服务器忽略客户的请求
分区容错性（Partition tolerance）
允许网络丢失从一个节点发送到另一个节点的任意多条消息，即不同步也就是说，G1 和 G2 发送给对方的任何消息都是可以放弃的，也就是说 G1 和 G2 可能因为各种意外情况，导致无法成功进行同步，分布式系统要能容忍这种情况。
CAP 三者不可能同时满足
假设确实存在三者能同时满足的系统
那么我们要做的第一件事就是分区我们的系统，由于满足分区容错性，也就是说可能因为通信不佳等情况，G1 和 G2 之间是没有同步
接下来，我们的客户端将 v1 写入 G1，但 G1 和 G2 之间是不同步的，所以如下 G1 是 v1 数据，G2 是 v0 数据。
由于要满足可用性，即一定要返回数据，所以 G1 必须在数据没有同步给 G2 的前提下返回数据给 client，如下
接下去，client 请求的是 G2 服务器，由于 G2 服务器的数据是 v0，所以 client 得到的数据是 v0
很明显，G1 返回的是 v1 数据，G2 返回的是 v0 数据，两者不一致。其余情况也有类似推导，也就是说 CAP 三者不能同时出现。
CAP 三者如何权衡
我们权衡三者的关键点取决于业务
放弃了一致性，满足分区容错，那么节点之间就有可能失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会容易导致全局数据不一致性。对于互联网应用来说（如新浪，网易），机器数量庞大，节点分散，网络故障再正常不过了，那么此时就是保障 AP，放弃 C 的场景，而从实际中理解，像门户网站这种偶尔没有一致性是能接受的，但不能访问问题就非常大了。
对于银行来说，就是必须保证强一致性，也就是说 C 必须存在，那么就只用 CA 和 CP 两种情况，当保障强一致性和可用性（CA），那么一旦出现通信故障，系统将完全不可用。另一方面，如果保障了强一致性和分区容错（CP），那么久具备了部分可用性。实际究竟应该选择什么，是需要通过业务场景进行权衡的（并不是所有情况都是 CP 好于 CA，只能查看信息但不能更新信息有时候还不如直接拒绝服务）
参考 CAP 原则 (CAP 定理)、BASE 理论分布式理论 (一) – CAP 定理 CAP 定理 An Illustrated Proof of the CAP Theorem
