CAP 定理
cloud leadspace
什么是 CAP 定理?

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

您是否见过那种标题上写着“要价低、干活快、技术好:任选其二”的关于园艺师、油漆工或其他技工的广告?

CAP 定理将类似的逻辑应用于分布式系统——也就是说,分布式系统只能提供三个所需特性中的两个:一致性可用性分区容错性(即 CAP 定理中的 “C”、“A”和“P”)。

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

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

 

特色产品

Cloudant

DataStax

IBM Cloud Databases for MongoDB


CAP 定理中的"CAP"之解释

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

一致性

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

可用性

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

分区容错性

分区是分布式系统中的通信中断,即两个节点之间断开连接或连接临时延迟。 分区容错性是指无论系统中节点之间的通信出现多少故障,集群都必须持续工作。


CAP 定理 - NoSQL 数据库类型

NoSQL(非关系型)数据库是分布式网络应用的理想选择。 与可垂直扩展的 SQL(关系型)数据库不同,NoSQL 数据库可水平扩展,并采用了分布式设计——它们可以在由多个互连节点组成的不断增长的网络中快速扩展。 (了解更多信息,请参见“SQL 与 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.com 外部)只能有一个接收全部写入操作的主节点。 同一副本集中的所有其他节点都是复制主节点的操作日志并将其应用于自己的数据集的辅助节点。 默认情况下,客户端还从主节点读取数据,但它们也可以指定读取首选项 (链接位于 IBM 外部),允许从辅助节点读取数据。

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


Cassandra 和 CAP 定理 (AP)

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

关于 CAP 定理方面,Cassandra 是一种 AP 数据库——它提供了可用性和分区容错性,但无法保证一致性。 因为 Cassandra 没有主节点,所以所有节点都必须持续可用。 然而,通过允许客户端在任何时间写入到任何节点,并尽最快速度调解不一致,Cassandra 提供了最终一致性

由于数据仅在网络分区的情况下才会变得不一致,并且不一致很快就会得到消除,因此 Cassandra 提供了“修复”功能 来帮助节点再次与其对等节点同步。 但是,持续的可用性也会形成高性能系统,在许多情况下,这可能值得权衡。


与微服务结合使用

微服务是松散耦合并且可独立部署的应用组件,它们合并了自己的堆栈,包括自己的数据库和数据库模型,并通过网络相互通信。 由于微服务可以在云服务器和本地数据中心上运行,它们在混合多云应用中非常受欢迎。

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


CAP 定理和 IBM Cloud

IBM 提供了一整套管理全面的数据库服务。 在 IBM Cloud 上,您可以运行关系数据库管理系统,以及

欲详细了解我们的整个数据库选项,请注册 IBMid 并创建您的 IBM Cloud 帐户


相关解决方案

IBM Cloud 上的云数据库

了解 IBM 提供的一系列云数据库,这些数据库支持各种用例,包括任务关键型工作负载、移动和 Web 应用以及分析功能。


IBM Cloudant

IBM Cloudant 是基于 Apache CouchDB 的可扩展分布式云数据库,用于 Web、移动、IoT 和无服务器应用。


DataStax Enterprise with IBM

即刻从 IBM 获取 DataStax Enterprise——一种基于 Apache Cassandra 构建的云本地 NoSQL 数据库,具备可扩展性、高可用性,这是您购买、部署和支持的唯一来源。


IBM Cloud Databases for MongoDB

MongoDB 即服务面向企业构建,并与 IBM Cloud 原生集成。


IBM Cloud Databases for Elasticsearch

了解关于 Databases for Elasticsearch 的更多信息——一种包含丰富数据的强大工具,可以使用全文搜索引擎和 JSON 文档数据库索引。


IBM Cloud Databases for etcd

了解有关 IBM Cloud Database for etcd 的更多信息,它提供了企业就绪、完全托管的键值储存,保存用于管理服务器集群的数据。