CAP 原则是描述一致性、可用性和分区兼容性的理论, 但在实际情况下, 这一原则常常令人困惑。
- 什么样的情况适用于这一原则?
- 先决条件是什么?
- CAP 原则是否真的使分布式系统不一致和可用?
现在, 我将尝试使用一种简单易用的方法来获取前面的分布式问题。
首先, 我们将红色球定义为数据, 蓝色框定义为容器。因此, 分布式问题可以简化为如何将数据放入容器中以及如何访问数据?容器是由 CAP 原则描述的分区。当您要将1个数据放入 n 个分区时, 我们可以使用3种方法将其放入。CPS 的第一种方法, 假设我们有两个容器, 我们将数据分成两部分, 并将它们放在两个容器中。该分布式模型可以保证数据的一致性, 关于数据被拆分为两部分, 数据的歧义不会出现, 那么这个模型就是分区兼容性, 因为它被分成两部分后。
此 "一致性" 是指修改分区中的数据 A 的时间。两个容器中的数据是相同的, 不会出现数据歧义。但是, 当任何分区都无法使用时, 您无法获取所有数据, 从而导致数据显示为不可用。
在第二种类型的 AP 中, 我们将数据的两个副本放入两个分区中。当无法使用 AB 的两个分区时, 还可以使用这些数据来保持数据的可用性。
但是, 当两个容器分别修改数据时, 会导致无法获得一致的数据, 这就是 AP 保持可用性和分区兼容性的方式, 从而牺牲了数据的一致性。
执行 CA 的第三种方法是以牺牲数据分区兼容性为代价来保持数据一致性和可用性。说白了, 你可以把数据放在一个分区里, 然后它就不是一个分布式系统。
好吧, 这就是 CAP 的基本原则。设计分布式系统最基本的考虑因素是如何将数据放入各个分区。因为 CA 不是分布式系统, 所以可以先消除它。剩余 CP 和 AP 中数据的一致性是一个不可避免的选择, 因为无法使用的数据或冲突的数据显然是不可接受的。因此, 我们剩下的唯一选择是 CP 的分布式系统。但是, CP 的问题在于, 任何分区或节点崩溃后数据都不完整, 从而导致数据错误和数据不可用。作为一名互联网工程师, 首先想到的是, 我们是否必须将备份服务器添加到每个分区?CAP 原则表示您不在备份服务中, 但 CAP 原则只是将 CP 转换为 AP 的一种方式。
备份服务器 A1 和 B1 与原始服务器相结合, 形成一个奇怪的 CP 和 AP 混合。虽然增加了可用性, 备份服务器与原始服务器, 因为如果任何意外的原因数据不一致, 使整个系统失去了一致性, 这种组合变成 AP 系统。因此, 我们将备份服务器 A1 放在 A 的背面, 以便用户不能直接修改 A1 服务器。A1 服务器只能由 A 服务器修改。
然后, 分布式系统成为由 CP 曲面和 AP 面组成的矩阵。
在一般情况下, CP 面负责统一的外部通信, 提供统一和分区的数据服务。当用户对用户不可见时, 当 CP 表面损坏或不可用时, 请在 AP 方向上选择一个可用的服务器, 以继续向用户提供服务。只要系统有足够的 AP 服务器可以转换为 CP 服务器来抵消不使用该服务器的概率, 就可以保证整个分布式矩阵 CP & AP。
在这个分布式矩阵中, 不仅可以使用一个表面向外界提供数据服务。AP 节点可用于在系统设计中向用户提供只读服务。这并不局限于 CP 节点或某些曲面, 任何节点实际上都可以提供只读服务。因此, 对于要求较低可靠性的只读服务, 所有节点都相当于二维系统。分布式矩阵相当灵活, 可以根据用户的视图进行不同的剪切。
那么, 现实世界中是否有 CP & AP 系统呢?答案是肯定的, 传统的主从服务器是 C & AP 系统。请注意, C & AP 不是 CP & AP, 因为单人主系统没有分布。但提供分布式服务的主要系统, 如大型网站和亚马逊云数据库, 可以被视为一个完整的 CA & AP 系统。由于 amazon 云的数据库隐式提供主从备份和磁盘备份, 因此它相当于用户和开发人员看不到的 AP 系统。
同样, 目前的区块链技术是一个 C & AP 系统。由由 POW 或 DPOS 选择的 C 提供的单个 C 组成的分布式矩阵, 由整个网络或多个服务器提供 AP 服务。
下一步是讨论一致性定义问题。因为它涉及到 C 容器是否可以划分为 CP 容器的问题?什么样的数据需要一致性?
在上图中, 一个红色的球被分成两个一半和两个容器。当一个容器中的球变成绿色时, 如果它是一个有效的球, 那么我们说球可以被分区, 也就是分区兼容的数据。如果球必须是所有绿色才能有效, 则数据本身就是分区不兼容的数据。
将 C & AP 转换为 CP & AP 的过程是在 C 中找到分区兼容数据。
参考
许可证
本文以及任何关联的源代码和文件, 都是在代码项目开放许可 (CPOL) 下获得许可的