CAP定理 —— 一个不可能的选择

“便宜、快速、好：选择其中两个”？

CAP定理：你不能同时拥有蛋糕并吃掉它。

• 一致性：蛋糕始终是同样的口味。
• 可用性：蛋糕始终可以被吃掉。
• 分区容错性：蛋糕可以被切成块并共享。

CAP定理将类似的推理方法扩展到分布式系统中；具体而言，它指出分布式系统只能提供三个中的两个理想特性：一致性、可用性和分区容错性（CAP中的字母’C’，’A’和’P’）。

将数据同时保存在多个节点上的网络，无论这些节点是实际的还是虚拟的计算机，都被称为分布式系统。

在开发云应用程序时，了解CAP定理非常重要，因为所有云应用程序都是分布式系统。

CAP的基本概念

让我们更深入地了解CAP定理对分布式系统的三个特性的概念。

一致性

无论客户端连接到哪个节点，它们总是同时看到相同的数据，这就是一致性。

为了实现这一点，每次将数据写入一个节点时，必须立即将其发送或复制到系统中的所有其他节点，然后才能认为写入已经“成功完成”。

可用性

任何请求数据的客户端都会获得响应，即使网络中的一个或多个节点不可用。这就是可用性。

换句话说，分布式系统中的每个运行节点都将毫无例外地对每个请求提供合法的答案。

分区容错性

分布式系统内部的通信中断称为分区。这可以被看作是系统中两个节点之间的连接丢失或暂时延迟。

术语“分区容忍性”是指尽管在构成系统的各个节点之间的通信中出现任意数量的故障，集群的功能仍必须得到维护。

不同NoSQL数据库的CAP原则

img

NoSQL数据库是在分布式网络上运行的应用程序的最佳选择。与垂直可扩展的SQL（关系型）数据库相比，NoSQL数据库是水平可扩展且分布式设计的。这意味着它们能够在由多个链接节点组成的发展网络上快速扩展。

现在，NoSQL数据库根据它们提供的两个CAP原则进行分类，这两个原则分别是：

CP数据库提供一致性和分区容忍性，但以牺牲可用性为代价。如果在任意两个节点之间发生分区，系统需要将非一致的节点停止（即使其无法访问），直到分区问题得到解决。

AP数据库在数据的一致性方面存在牺牲，但提供可用性和分区容忍性。当分区发生时，网络中的所有节点仍然可访问，但靠近分区开头或结尾的节点可能提供比其他节点更旧的数据版本。（一旦分区问题得到解决，AP数据库通常会重新同步节点，以纠正可能引入到系统中的任何不一致性。）

CA数据库确保数据在系统中的所有节点之间保持一致和可访问。然而，如果系统中的任意两个节点之间存在分区，它无法完成这个任务，因此无法提供容错性。

由于分区在分布式系统中是不可避免的，我们故意将CA数据库类型放在列表的最后。因此，虽然可以在理论上讨论CA分布式数据库的概念，但实际上，这样的数据库根本不存在。然而，如果你觉得你的分布式应用需要CA数据库，并不意味着你不能拥有这样一个数据库。

包括PostgreSQL在内的各种关系型数据库都可以提供一致性和可用性，并可以在多个节点上进行复制以进行分布式部署。

CAP定理和MongoDB

MongoDB将数据存储为BSON（二进制JSON）文档，使其成为常见的NoSQL数据库管理系统。它广泛用于大规模、实时、分布式应用。

MongoDB是一个CP数据存储，因为它能够在保持数据一致性的同时解决网络分区问题，但以牺牲可用性为代价，正如CAP定理所描述的那样。

在MongoDB中，一个复制集（replica set）只能有一个主节点来处理所有写操作。复制集中的次要节点复制主节点的事务日志，并使用它来更新自己的数据副本。客户端默认从主节点读取数据，但可以通过设置读偏好来更改这一行为。

如果原始节点故障，最近操作日志最多的次要节点将被提升为主节点。只要所有从节点都赶上了新的主节点，集群就会恢复可访问性。在此期间，没有客户端可以发送写请求，因此数据在整个网络上是同步的。

CAP定理（AP）和Cassandra

Apache软件基金会开发和分发Cassandra，这是一个自由开源的NoSQL数据库。它以宽列数据库的形式进行分布式数据存储。由于其无主节点的设计，Cassandra没有像MongoDB那样的单点故障。

Cassandra是一个AP数据库，因为它满足了一些但不是所有的一致性、可用性和分区容忍性（CAP）要求。由于缺乏主节点，Cassandra集群中的所有节点始终处于运行状态至关重要。另一方面，Cassandra通过允许客户端随时向任何节点写入数据并迅速解决不一致性问题来提供最终一致性。

Cassandra具有“修复”功能，以帮助节点赶上其对等节点，因为只有在网络分裂的情况下数据才会变得不一致，并且不一致性会迅速得到纠正。然而，持续的可用性会产生高性能的系统，在某些情况下可能值得付出代价。

结论

如果你正在创建基于微服务的分布式项目，了解CAP定理可以帮助你选择合适的数据库。例如，如果你可以接受最终一致性（而不是严格一致性），但需要快速迭代数据模型并进行水平扩展，那么像Cassandra或Apache CouchDB这样的AP数据库可能能满足你的需求并简化部署。

另一方面，如果你的应用程序的成功取决于数据的可靠性，例如电子商务或支付服务，那么关系型数据库如PostgreSQL可能是最佳选择。