什么是 CAP 定理？

CAP 定理指出，分布式系统只能提供这三个所需特征中的两个：
一致性、可用性和分区容错性（CAP 中的 “C”、“A” 和 “P”）。

您是否见过以“便宜、快速、优质：任选两个”为标题开头的园林设计师、房屋油漆工或其他技工的广告？CAP 定理将类似的逻辑应用于分布式系统。

分布式系统是将数据同时存储在多个节点（实体机或虚拟机）上的网络。由于所有云应用程序都是分布式系统，因此在设计云应用程序时了解 CAP 定理至关重要，以便您可以选择能够提供应用程序最需要的特征的数据管理系统。

CAP 定理也称为 Brewer 定理，因为这是由 Eric A. Brewer 教授 2000 年在一次关于分布式计算的演讲中首次提出的。两年后，麻省理工学院教授 Seth Gilbert 和 Nancy Lynch 发表了对“Brewer 猜想”的证明。

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

一致性

一致性意味着所有客户端无论连接到哪个节点，都能在同一时间看到相同的数据。为此，每当数据写入一个节点时，必须立即将其转发或复制到系统中的所有其他节点，然后才会视之为“成功”写入。

可用性

可用性意味着任何发出数据请求的客户端都会得到响应，即使一个或多个节点发生故障也是如此。换一种说法，分布式系统中的所有工作节点都会对任何请求返回有效响应，无一例外。

分区容错性

分区是分布式系统中的通信中断——两个节点之间的连接丢失或暂时延迟。分区容错意味着尽管系统中的节点之间出现任意数量的通信故障，集群也必须继续工作。

NoSQL 数据库是分布式网络应用程序的理想选择。与垂直可扩展的 SQL（关系）数据库不同，NoSQL 数据库采用水平可扩展和分布的设计，可以在由多个互连节点组成的不断增长的网络中快速扩展。（有关更多信息，请参阅“SQL 与 NoSQL 数据库：有何不同？”。）

如今，NoSQL 数据库根据其支持的两个 CAP 特征进行分类：

• CP 数据库：CP 数据库以牺牲可用性为代价提供一致性和分区容错性。当任意两个节点之间出现分区时，系统必须关闭不一致的节点（即使其不可用），直到分区得到解决。
  
  
• AP 数据库：AP 数据库以牺牲一致性为代价提供可用性和分区容错性。当出现分区时，所有节点仍然可用，但位于分区错误端的节点可能会返回比其他节点更旧的数据版本。（分区解决后，AP 数据库通常会重新同步节点以修复系统中的所有不一致问题。）
  
  
• CA 数据库：CA 数据库在所有节点上提供一致性和可用性。但是，如果系统中任意两个节点之间存在分区，则无法做到这一点，因此无法提供容错功能。

我们将 CA 数据库列在最后是有原因的——在分布式系统中，分区是不可避免的。因此，虽然我们可以在理论上讨论 CA 分布式数据库，但就所有实际目的来说，CA 分布式数据库是不可能存在的。这并不意味着如果需要的话，您不能为分布式应用程序建一个 CA 数据库。许多关系数据库（例如 PostgreSQL）都提供一致性和可用性，并且可以通过复制部署到多个节点。

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

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

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

Apache Cassandra 是由 Apache 软件基金会维护的开源 NoSQL 数据库。它是一个宽列数据库，允许用户在分布式网络上存储数据。然而，与 MongoDB 不同的是，Cassandra 采用无主架构，因此它有多个故障点，而不是单个故障点。

相对于 CAP 定理，Cassandra 是一个 AP 数据库——它提供可用性和分区容错性，但不能始终提供一致性。由于 Cassandra 没有主节点，因此所有节点必须持续可用。然而，Cassandra 通过允许客户端在任何时间写入任何节点并尽快协调不一致来提供最终一致性。

由于数据只有在出现网络分区的情况下才会变得不一致，并且不一致会很快得到解决，因此 Cassandra 提供了“修复”功能来帮助节点同步复制其对等节点。然而，持续的可用性造就了高性能的系统，在许多情况下，这可能是值得的。

微服务是松散耦合、可独立部署的应用程序组件，它们包含自己的堆栈（包括自己的数据库和数据库模型），并通过网络相互通信。由于您可以在云服务器和本地数据中心上运行微服务，因此它们在混合和多云应用程序中已变得非常流行。

在设计从多个位置运行的基于微服务的应用程序时，了解 CAP 定理可以帮助您选择最佳数据库。例如，如果快速迭代数据模型和水平扩展的能力对您的应用程序至关重要，但您可以容忍最终（而不是严格）一致性，那么 Cassandra 或 Apache CouchDB 等 AP 数据库可以满足您的需求并简化您的部署。另一方面，如果您的应用程序严重依赖数据一致性（例如在电子商务应用程序或支付服务中），则可以选择像 PostgreSQL 这样的关系数据库。