分布式系统-CAP 理论

在前一篇分布式系统–拜占庭将军问题(The Byzantine Generals Problem) 我们理解了共识问题的背景，这一节主要讨论如何解决或者理解自己系统中的共识问题，通过什么来分辨自己的系统需要哪一种共识。

这个理论就是 CAP 理论，先想下面几个问题：

什么是 CAP，全称是什么，之间的关系是什么？
CAP 之间是什么关系，场景对应是怎样的？
P 跟 A 都保证了可用性，但怎么区分？
如何运用 CAP？

注意，如果是单体系统，不存在什么 CAP 理论，就不存在分区。

定义

属性	全称	中文	描述
C	Consistency	一致性	集群节点要么读到集群最新数据，要么全部都返回读取失败
A	Availability	可用性	任何来自客户端的请求，不管访问哪个非故障节点，都能得到响应数据，但不保证是同一份最新数据
P	Partition Tolerance	分区容错性	当节点间出现任意数量的消息丢失或高延迟的时候，系统仍然在继续工作

从定义可以看到，CAP 就是 3 个属性，分别是一致性，可用性，分区容错性。

一致性

强调的是数据绝对的正确

下图，第一步设置了 x 为 2。但是从节点 2 获取的 x 还是 1。

第三步，节点之间通过通信，同步 x 数据。第四步，从节点 2 拉取到的 x 就是 2。

这样子，不管客服端访问哪个节点，读取到的都是同一份最新写入的数据。

可用性

强调的是服务绝对的正确

不管节点的数据是否一致，只要非故障节点服务器收到请求，就返回 x 的值，那么这个系统的服务就是满足可用性的。

分区容错性

强调的是系统在有错的前提下，依然能够正常运作

可用性和分区容错性看起来很相似，都保证了可用性，但是不要迷惑了。可以这么理解，有分区就有可能出现问题，但是出现问题之后给什么样的反馈，是取决于这个系统设计的人。怎么反馈，反馈成什么样，这就是 C 和 A。

因为分布式系统与单机系统不同，它涉及到多节点间的通讯和交互，节点间的分区故障是必然发生的，所以要提醒的是，在分布式系统中分区容错性是必须要考虑的。

CAP 不可兼得

因为分区容错性是前提，P一定有。可以这么理解，一个蓄水池，恒水位，有一个出水口和入水口。入水口坏了，你是想要这个蓄水池先供水，还是先保证水位正确，不要触发水位报警。这个蓄水池，肯定不能在没有入水的前提下，还能让水位保持恒定。因此，CAP 是不能兼容的。要想兼容，除非这个系统不需要分区。

CAP 不可兼得最初是埃里克·布鲁尔（Eric Brewer）基于自己的工程实践，提出的一个猜想，后被赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）证明，证明过程可以参考论文《Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services》，记住结论就好了。

补充一点：基于证明严谨性的考虑，赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）对指标的含义做了预设和限制，比如，将一致性限制为原子一致性。

如何使用 CAP 理论

有网络交互就一定会有延迟和数据丢失，而这种状况我们必须接受，还必须保证系统不能挂掉。所以就像前面提到的，节点间的分区故障是必然发生的。也就是说，分区容错性 P 是前提，是必须要保证的。

现在就只剩下一致性 C 和可用性 A 可以选择了：要么选择一致性，保证数据正确；要么选择可用性，保证服务可用。

那么 CP 和 AP 的含义是什么呢？

选择了一致性 C ：一定会读到最新的数据，不会读到旧数据，但如果因为消息丢失、延迟过高发生了网络分区，那么这个时候，当集群节点接收到来自客户端的读请求时，为了不破坏一致性，可能会因为无法响应最新数据，而返回出错信息。
选择了可用性 A ：系统将始终处理客户端的查询，返回特定信息，如果发生了网络分区，一些节点将无法返回最新的特定信息，它们将返回自己当前的相对新的信息。

CAP 适用场景

CA：典型的应用是 Etcd，Consul 和 Hbase，zookeeper
AP：Cassandra 和 DynamoDB，服务注册中心

可以看一下运用 CAP 理论分析 redis cluster Redis cluster是AP架构还是CP架构，这一篇文章。每个系统不能绝对地看说是 AP 还是 CP，每个系统里面的子系统或者模块会根据场景去区分，可能一个系统里面会同时出现 AP 和 CP 架构。

资料来源

本文档主要基于极客时间分布式协议与算法实战