CAP 定理

menu icon

CAP 定理

在本指南中,我们将探讨 CAP 定义及其在设计分布式应用和选择 NoSQL 或关系数据存储时的相关性。

什么是 CAP 定理?

有没有在广告中看到园林设计师、油漆工或者其他商人展示大字标题:“便宜,快速,优质:3 选 2”?

CAP 定理将类似的逻辑应用于分布式系统,即分布式系统只能提供三个期望特征中的两个: 一致性可用性分区容错(也就是 CAP 中的 CAP)。

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

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

CAP 定理中的“CAP”之解释

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

一致性

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

可用性

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

分区容错

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

CAP 定理 - NoSQL 数据库类型

NoSQL(非关系型)数据库是分布式网络应用的理想之选。 与可垂直扩展的 SQL(关系型)数据库不同,NoSQL 数据库可水平扩展,采用分布式设计 -它们可以在由多个互连节点组成的不断增长的网络中快速扩展。(请参阅“SQL vs. NoSQL 数据库:有何区别?”,以了解更多信息。)

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

  • CP 数据库:CP 数据库提供一致性和分区容错,以牺牲可用性为代价。 在任何两个节点之间发生分区时,系统必须关闭不一致的节点(即,使其不可用),直至解决该分区为止。
  • AP 数据库:AP 数据库提供可用性和分区容错,以牺牲一致性为代价。 当发生分区时,所有节点仍可用,但分区错误端的节点可能会返回较旧版本的数据。(解决分区后,AP 数据库通常会再同步节点,以修复系统中的所有不一致。)
  • CA 数据库:CA 数据库在所有节点间提供一致性和可用性。 如果系统中的任意两个节点之间存在分区,但无法提供容错,就无法实现 CA 数据库。

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

MongoDB 和 CAP 定理 (CP)

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

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

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

Cassandra 和 CAP 定理 (AP)

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

相对于 CAP 定理,Cassandra 是 AP 数据库 - 它提供可用性和分区容错,但无法始终保证一致性。 因为 Cassandra 没有主节点,所以所有节点都必须持续可用。 但是,Cassandra 允许客户端随时写入任何节点并尽可能快速地协调不一致,以提供最终一致性

由于数据仅在网络分区和不一致的情况下变得不一致,因此 Cassandra 提供“修复”功能(链接位于 IBM 外部),以帮助节点再次与同级节点同步。 但是,持续可用性会形成高性能系统,在许多情况下这可能值得进行权衡。

与微服务结合使用

微服务是松散耦合并且可独立部署的应用组件,包含它们自己的技术栈 - 包括自己的数据库和数据库模型,并通过网络相互通信。 由于可在云服务器和本地数据中心上运行微服务,因此它们已成为混合云多云应用的热门之选。

了解 CAP 定理可帮助您在设计从多个位置运行的基于微服务的应用时选择最合适的数据库。 例如,如果快速迭代数据模型和进行水平扩展对应用而言至关重要,但您可以接受最终一致性(而不要求严格的一致性),那么 Cassandra 或 Apache CouchDB 之类的 AP 数据库可以满足您的需求并简化部署。 另一方面,如果应用严重依赖于数据一致性,例如电子商务应用或支付服务,那么您可以选择 PostgreSQL 之类的关系数据库。

CAP 定理和 IBM Cloud

IBM 提供了一整套完全管理型数据库服务。 除了关系数据库管理系统外,您还可以在 IBM Cloud 上运行 MongoDBCloudant(另一种 AP 分布式数据存储)、Elasticsearchetcd 和其他数据库解决方案。

要了解我们完整的数据库选择(没有任何承诺),请注册 IBMid 并创建 IBM Cloud 帐户