什么是CAP 定理

CAP 定理将类似的逻辑应用于分布式系统，即分布式系统只能提供三个期望特征中的两个：一致性、可用性和分区容错。一致性表示所有客户端同时看到相同的数据，无论它们连接到哪个节点。可用性表示发出数据请求的任何客户端都会得到响应，即使一个或多个节点宕机。分区是分布式系统中的通信中断 – 两个节点之间的丢失连接或连接临时延迟。

一、什么是CAP 定理

CAP 定理将类似的逻辑应用于分布式系统，即分布式系统只能提供三个期望特征中的两个： 一致性、可用性和分区容错（也就是 CAP 中的 C、A 和 P）。

分布式系统是一个网络，同时在多个节点上存储数据（物理机器或虚拟机）。由于所有云应用都是分布式系统，因此在设计云应用时了解 CAP 定理至关重要，这样您就可以选择适当的数据管理系统，以提供应用最需要的特性。

CAP 定理也称为布鲁尔定理 (Brewer’s Theorem)，因为它是由 Eric A Brewer 教授在 2000 年所作的分布式计算演讲中首先提出的。两年后，麻省理工学院的教授 Seth Gilbert 和 Nancy Lynch 发表了“布鲁尔猜想”的证明。

让我们详细了解一下 CAP 定理所指出的三个分布式系统特征。

1、一致性

一致性表示所有客户端同时看到相同的数据，无论它们连接到哪个节点。要做到这一点，每当数据写入一个节点时，就必须立即将其转发或复制到系统中的所有其他节点，然后写操作才被视为“成功”。

2、可用性

可用性表示发出数据请求的任何客户端都会得到响应，即使一个或多个节点宕机。可用性的另一种状态：分布式系统中的所有工作节点都返回任何请求的有效响应，而不会发生异常。

3、分区容错

分区是分布式系统中的通信中断 – 两个节点之间的丢失连接或连接临时延迟。分区容错意味着集群必须持续工作，无论系统中的节点之间有任何数量的通信中断。

二、CAP 定理与NoSQL 数据库

NoSQL（非关系型）数据库是分布式网络应用的理想之选。与可垂直扩展的 SQL（关系型）数据库不同，NoSQL 数据库可水平扩展，采用分布式设计 -它们可以在由多个互连节点组成的不断增长的网络中快速扩展。

目前，NoSQL 数据库根据它们所支持的两个 CAP 特征进行分类：

1、CP 数据库

CP 数据库提供一致性和分区容错，以牺牲可用性为代价。在任何两个节点之间发生分区时，系统必须关闭不一致的节点（即，使其不可用），直至解决该分区为止。

2、AP 数据库

AP 数据库提供可用性和分区容错，以牺牲一致性为代价。当发生分区时，所有节点仍可用，但分区错误端的节点可能会返回较旧版本的数据。（解决分区后，AP 数据库通常会再同步节点，以修复系统中的所有不一致。）

3、CA 数据库

CA 数据库在所有节点间提供一致性和可用性。如果系统中的任意两个节点之间存在分区，但无法提供容错，就无法实现 CA 数据库。

我们将该类型列在最后的原因在于，在分布式系统中，无法避免分区。因此，虽然我们可以在理论上讨论 CA 分布式数据库，但出于所有实际目的，CA 分布式数据库不可能存在。但是，这并不意味着如果您需要一个 CA 数据库，不能为分布式应用部署此类数据库。许多关系数据库可以实现一致性和可用性，并且可使用复制功能部署到多个节点中。

三、MongoDB 和 CAP 定理

MongoDB 是热门的 NoSQL 数据库管理系统，它将数据存储为 BSON（二进制 JSON）文档。它经常用于在多个不同位置运行的大数据和实时应用。相对于 CAP 定理，MongoDB 是 CP 数据存储 – 它通过保持一致性而牺牲可用性来解决网络分区问题。

MongoDB 是单主系统 – 每个副本集（链接位于 IBM 外部）只能有一个可接收所有写操作的主节点。同一副本集中的所有其他节点都是复制主节点的操作日志并将其应用于自己的数据集的辅助节点。默认情况下，客户端还从主节点读取数据，但它们也可以指定允许从辅助节点读取数据的读取优选项（链接位于 IBM 外部）。

当主节点不可用时，将选择具有最新操作日志的辅助节点作为新的主节点。一旦所有其他辅助节点都与新的主节点同步，集群将再次可用。由于客户端在此时间间隔内无法进行任何写请求，因此数据在整个网络中保持一致。