CAP 定理和微服务

编辑页面封面

随着您作为开发人员的职业发展，您将需要越来越多地考虑软件架构和系统设计。能够设计高效的系统并在规模上进行权衡非常重要。系统设计是一个包含许多重要概念的广阔领域。系统设计中的一个基本概念是 CAP 定理。理解 CAP 定理是理解如何设计强大的分布式系统的关键。今天，我们将深入研究 CAP 定理，解释其含义、组成部分等。

让我们开始吧！

我们将介绍：

什么是CAP定理？

CAP 定理或布鲁尔定理是系统设计领域的基本定理。它于 2000 年由加州大学伯克利分校的计算机科学教授 Eric Brewer 在一次关于分布式计算原理的演讲中首次提出。2002 年，麻省理工学院教授南希·林奇和赛斯·吉尔伯特发表了布鲁尔猜想的证明。CAP 定理指出，分布式系统只能同时提供三个属性中的两个：一致性、可用性和分区容错性。当存在分区时，该定理形式化了一致性和可用性之间的权衡。

分布式系统是一组计算机，它们一起工作以形成供最终用户使用的单台计算机。所有分布式机器都有一个共享状态并同时运行。对于分布式系统，用户必须能够与任何分布式机器进行通信，而无需知道它只是一台机器。分布式系统网络不仅将数据存储在单个节点上，还同时使用多个物理或虚拟机。

CAP定理证明

让我们看一下 CAP 定理的一个简单证明。想象一个由两个节点组成的分布式系统：

分布式系统充当带有变量X值的普通寄存器。存在网络故障，导致系统中两个节点之间出现网络分区。最终用户执行写请求，然后执行读请求。让我们来看看系统的不同节点处理每个请求的情况。在这种情况下，我们的系统有两个选择：

它可能会在其中一个请求中失败，从而破坏系统的可用性
它可以执行这两个请求，从读取请求中返回一个陈旧的值并破坏系统的一致性

系统无法成功处理这两个请求，同时还要确保读取返回写入写入的最新值。这是因为由于网络分区，写入操作的结果无法从节点 A 传播到节点 B。

一致性、可用性和分区容错性解释

现在我们对CAP定理有了一个基本的了解，让我们分解首字母缩写词，讨论一致性、可用性和分区容忍度的含义。

一致性

在一致的系统中，所有节点同时看到相同的数据。如果我们在一致的系统上执行读操作，它应该返回最近写操作的值。读取应该导致所有节点返回相同的数据。所有用户同时看到相同的数据，无论他们连接到哪个节点。当数据写入单个节点时，它会在系统中的其他节点之间复制。

可用性

当分布式系统中存在可用性时，这意味着系统始终保持运行。无论节点的各个状态如何，每个请求都会得到响应。这意味着即使有多个节点宕机，系统也会运行。与一致的系统不同，不能保证响应将是最近的写入操作。

分区容错

当分布式系统遇到分区时，意味着节点之间的通信中断。如果系统是分区容忍的，则系统不会出现故障，无论消息是否在系统内的节点之间被丢弃或延迟。为了具有分区容错性，系统必须跨节点和网络的组合复制记录。

CAP 定理 NoSQL 数据库

NoSQL 数据库非常适合分布式网络。它们允许水平扩展，并且可以跨多个节点快速扩展。在决定使用哪个 NoSQL 数据库时，记住 CAP 定理很重要。NoSQL 数据库可以根据它们支持的两个 CAP 功能进行分类：

CA数据库

CA 数据库支持所有节点的一致性和可用性。不幸的是，CA 数据库无法提供容错能力。在任何分布式系统中，分区都是不可避免的，这意味着这种类型的数据库不是一个很实用的选择。话虽如此，如果您需要，您仍然可以找到一个 CA 数据库。一些关系数据库，例如PostgreSQL，允许一致性和可用性。您可以使用复制将它们部署到节点。

CP数据库

CP 数据库支持一致性和分区容错性，但不支持可用性。当发生分区时，系统必须关闭不一致的节点，直到可以修复分区。MongoDB是 CP 数据库的一个示例。它是一个使用文档进行数据存储的 NoSQL 数据库管理系统 (DBMS)。它被认为是无模式的，这意味着它不需要定义的数据库模式。它通常用于在不同位置运行的大数据和应用程序。CP 系统的结构使得只有一个主节点接收给定副本集中的所有写入请求。从节点复制主节点中的数据，因此如果主节点出现故障，从节点可以替代。

AP数据库

AP 数据库支持可用性和分区容错性，但不支持一致性。在分区的情况下，所有节点都可用，但它们并未全部更新。例如，如果用户尝试从坏节点访问数据，他们将不会收到最新版本的数据。当分区最终解决时，大多数 AP 数据库将同步节点以确保它们之间的一致性。Apache Cassandra 是 AP 数据库的一个示例。它是一个没有主节点的 NoSQL 数据库，这意味着所有节点都保持可用。Cassandra 允许最终一致性，因为用户可以在分区解决后立即重新同步他们的数据。