分布式系统的CAP理论

CAP 定理是加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想。2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了布鲁尔猜想的证明，使之成为分布式计算领域公认的一个定理。

对于设计分布式系统的架构师来说，CAP 是必须掌握的理论。

 

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

 

C:一致性(Consistency)

对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。

第一版的解释“所有的节点在同一时刻都能看到相同的数据”是不严谨的。而第二版强调 client 读操作能够获取最新的写结果就没有问题，因为事务在执行过程中，client 是无法读取到未提交的数据的，只有等到事务提交后，client 才能读取到事务写入的数据，而如果事务失败则会进行回滚，client 也不会读取到事务中间写入的数据。

 

A:可用性(Availability)

非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。

 

P:分区容忍性(Partition Tolerance)

当出现网络分区后，系统能够继续“履行职责”。(能否正常工作)

解释一下分区容忍性：

一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区(这些分区不能互相通信)。当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。

CAP到底该怎么选：

虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A 冲突了，因为 A 要求返回 no error 和 no timeout。因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。

 

例子：

如下图所示，为了保证一致性，当发生分区现象后, 节点1上的数据无法同步到 节点2， 节点2上的数据还是 Y。这时客户端 C 访问 节点2时，节点2 需要返回 Error，提示客户端 “系统现在发生了错误”，这种处理方式违背了可用性（Availability）的要求，因此 CAP 三者只能满足 CP。

 

 

如下图所示，为了保证可用性，当发生分区现象后， 节点1上的数据无法同步到 节点2， 节点2上的数据还是 Y。这时客户端 访问 节点2 时，节点2 将当前自己拥有的数据 Y 返回给客户端，而实际上当前最新的数据已经是 X了，这就不满足一致性（Consistency）的要求了，因此 CAP 三者只能满足 AP。