系统设计基础:什么是 CAP 定理?
随着你作为一名开发者的职业生涯不断进步,你需要越来越多地思考软件架构和系统设计。能够设计高效的系统并在规模化的情况下做出权衡至关重要。系统设计是一个庞大的领域,包含许多重要的概念。CAP 定理是系统设计中的一个基本概念。理解 CAP 定理是理解如何设计强大的分布式系统的关键。今天,我们将深入探讨 CAP 定理,解释其含义、组成部分等。
让我们开始吧!
我们将介绍:
什么是 CAP 定理?
CAP定理,又称布鲁尔定理,是系统设计领域的一个基本定理。它最初由加州大学伯克利分校计算机科学教授埃里克·布鲁尔于2000年在一次关于分布式计算原理的演讲中提出。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 允许最终一致性,因为用户可以在分区问题解决后立即重新同步其数据。
CAP 定理和微服务
微服务被定义为松散耦合的服务,可以独立开发、部署和维护。它们包含自己的堆栈、数据库和数据库模型,并通过网络相互通信。微服务在混合云和多云环境中尤为流行,并且在本地数据中心也得到广泛应用。如果您想创建微服务应用程序,可以使用 CAP 定理来帮助您确定最适合您需求的数据库。
总结和后续步骤
恭喜您迈出了学习 CAP 定理和分布式系统的第一步!分布式系统可以实现更低的延迟、更高的可扩展性、更强的互联互通性等等。CAP 定理在分布式系统乃至整个系统设计中都至关重要。虽然我们今天讲了很多,但关于分布式系统还有很多东西需要学习。接下来推荐学习以下主题:
- 分布式数据存储
- 分布式系统算法
- 原子性
要开始学习这些概念及更多内容,请查看 Educative 的课程《面向实践者的分布式系统》。在本实践课程中,您将探索真实分布式系统的设计、如何高效地设计大型系统,以及充分利用分布式系统所需了解的概念。
学习愉快!