为啥 CAP 定理中的 RDBMS 分区不能容忍，为啥它可用？

Posted 2023-02-16

【中文标题】为啥 CAP 定理中的 RDBMS 分区不能容忍，为啥它可用？

【英文标题】：Why isn't RDBMS Partition Tolerant in CAP Theorem and why is it Available?为什么 CAP 定理中的 RDBMS 分区不能容忍，为什么它可用？

【发布时间】：2016-07-24 02:51:49

【问题描述】：

关于 RDBMS 在 CAP 定理中是 CA 的两点我不明白：

1) 它说 RDBMS 不是 Partition Tolerant 但是RDBMS 比其他技术（如 MongoDB 或 Cassandra）的 Partition Tolerant 少吗？是否存在我们放弃 CA 以使其成为 AP 或 CP 的 RDBMS 设置？

2) CAP 的可用性如何？是通过主从设置吗？就像master死了，slave接管写入一样？

我是 DB 架构和 CAP 定理的新手，所以请多多包涵。

【参考方案1】：

很容易误解 CAP 属性，因此我提供了一些说明以使其更容易。

一致性：查询 Q 将产生相同的答案 A，而与处理请求的节点无关。为了保证完全一致性，我们需要确保所有节点始终同意相同的值。不要与最终一致性相混淆，在这种一致性中，网络会朝着使所有数据一致的方向发展，但在某些时间段内情况并非如此。

可用性：如果分布式系统收到查询 Q，它将始终为该查询生成答案。这不应该与“高可用性”混淆，这不是关于处理更高吞吐量的查询的能力，而是关于不拒绝回答。

分区容差：尽管存在分区，系统仍继续运行。这不是关于“修复”分区的机制，而是关于容忍分区，即尽管有分区但继续。

请注意，以下示例并未涵盖所有可能的情况。考虑以下标题：

CP的示例：

系统具有分区容错性，因为尽管存在分区，它的节点仍继续接受请求；这是一致的，因为唯一提供答案的节点是那些与处理所有写请求的主节点保持连接的节点；它不可用，因为另一个分区中的节点不提供它们收到的查询的答案。

AP 示例：

要么是因为（分别）我们让从节点响应请求，无论它们是否能够到达主节点，或者因为另一个分区中的从节点选择了一个新的主节点，或者因为我们有一个无主集群，所以实现了可用性，因为所有问题正在得到答案 - 一致性被丢弃，因为两个分区都在回复，同时可能产生不同的状态。

CA 示例：

如果我们在分区发生时断开节点，我们可以确保我们最多只有一个分区，这最终意味着网络不再分区，或者根本没有服务。这与分区容错相反，因为系统正在避免分区，而不是尽管它运行。在这些部分或完全断开连接的系统中保持一致性和可用性，因为所有工作节点（如果有）都具有相同的状态，并且所有收到的查询（如果有）都会得到答案 - 关闭节点不会收到查询。

回答问题：

在默认配置下，Cassandra 和 MongoDB 等数据库具有分区容错性，因为它们不会关闭节点来应对分区，而 mysql 等 RDBMS 则可以。

可用性与主/从设置关系不大，例如Cassandra 是无主的并且非常可用，因为哪个节点死亡并不重要。至于主/从设置中的可用性，没有理由在主死时停止响应所有查询，但您可能需要在选择新的时暂停写操作。

【讨论】：

感谢这些图表。我一直在研究这个问题一段时间，你的图表终于帮助我理解它。不过我还是很困惑。特别是关于您如何描述 CP 与 CA。您是说在 CP 中，断开连接的节点会收到查询并以某种“不可用”错误消息进行响应，而在 CA 中，请求会从断开连接的节点重新路由到连接的节点？如果是这样，前者听起来不像是在“处理”分区，而后者似乎确实更好（为什么要选择 CP 而不是 CA？）。

在 CA 中，断开连接的节点会关闭 - 它们不再存在，我不明白您的意思是重新路由吗？一开始就没有路线

在 CP 中，您说节点接受请求，尽管存在分区。但是你也说只有那些连接到主节点（图表的上半部分）的节点才能为他们收到的查询提供一个答案。我不明白接受查询但不提供答案如何被认为是分区容忍的。

@theprogrammer 因为尽管存在分区 (P)，但在任何给定时刻 (C) 中，没有两个节点会对同一问题提供不同的答案

请允许我提供一个额外的视角。如果没有发生分区，则该定理不适用——所有节点都在线并且能够为每个查询提供一致的答案。问题是当一个节点无法联系集群的其余部分时，它只有三个动作：1）回复 2）不回复 3）关闭。这三个选项导致定理暴露的三个权衡

【参考方案2】：

CAP 定理是有问题的，它只适用于分布式数据库系统。当您拥有分布式数据库时，可能会发生网络分区和节点崩溃。当发生网络分区时，您必须具有分区容差（CAP 的 P）。

所以回答你的问题 1) 是 CP 或 AP。可以按照 Will 所说的进行配置。

更多关于为什么分区容错是必须的： https://codahale.com/you-cant-sacrifice-partition-tolerance/

更多关于 CAP 定理的问题： https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

【参考方案3】：

我同意 RDBMS 可以拥有 CAP 的所有属性。我已经开始研究 noSQL DB，并且之前有使用 IBM DB2 的经验。

IBM DB2 如何满足所有 3 个 CAP 属性

C：一致性：由于 RDBMS 的事务性质，每个关系数据库都满足这一点。

A : 可用性 : 可用性意味着当查询一个存在的数据时，它应该被返回。同样，关系数据库旨在轻松完成此操作。

P：分区容差：这是最有趣的一个。从 DB2 的角度来看，在我正在处理的应用程序中，我们有 2 个数据库分布在不同的数据中心。一个是主要的，并通过心跳与次要通信。这些主数据库和辅助数据库中的每一个都有 12 个物理实例，其中数据基于一些预定义的逻辑进行分布。如果主节点出现故障，辅助节点会检测到这一点并取代主节点。由于主要和次要始终保持同步，因此数据也保持一致。

这就是我认为 RDBMS 满足 CAP 定理的所有 3 个属性的方式。

我可能错了，欢迎讨论。

【讨论】：

当其中一个数据中心出现故障时如何保证可用性？

您的 DB2 设置听起来像是主从设置。这意味着，如果我错了，请纠正我，它应该有某种停机时间来将奴隶提升为主人。那是对的吗？另外，CAP 中的可用性是否意味着当一个节点出现故障时绝对没有停机时间？

抱歉，没有任何分布式解决方案可以在任何给定时间拥有全部 3 个，这是不可能的。 youtube.com/watch?v=K12oQCzjPxE&feature=youtu.be&t=183 您可以拥有一个系统，该系统可配置为您拥有的两者中的哪一个，您可以拥有一个尝试缓解的系统。但最终，您必须做出最终牺牲的选择。

【参考方案4】：

现在很多数据库实际上有不同的配置，根据你设置的设置，可以是CA、CP、AP等，但不能同时实现这三个。一些数据库实际上努力支持所有这三个，但仍以某种方式优先考虑它们。

例如，根据配置，MySQL 可以是 CP 和 CA。默认情况下，它是 CA，因为它遵循主从范式，将数据复制到从属。如果一组 slave 失去与 master 的连接，因此决定选择一个新的 master 创建两个拥有自己的 slave 集的 master，则会牺牲分区容限。

然而，MySQL 也有另一种配置，即集群配置。它将 CP 优先于可用性，例如。如果没有足够的活动节点来提供所有数据，集群将关闭。

MySQL 可能有更多配置可以满足其他 CAP 定理组合，但总的来说，我只想说这取决于您的系统需要什么。有时数据库更适合一种配置而不是另一种配置，因此最好看看在使用某种配置时可能会出现哪些类型的问题。

关于实现 CAP 定理，我建议进一步研究不同的数据库以及它们如何实现 CAP 定理的优先级。有太多不同的方式来实现它们，例如。一般CA系统使用主从模型，AP系统使用hash ring等。

【讨论】：

你说Partition tolerance is sacrificed in the event that a set of the slaves loses the connection to the master and therefore decides to elect a new master creating two masters with their own set of slaves。我没明白，如何用自己的一组从属创建两个主控会牺牲分区容限？

@emilly 抱歉这么晚才回来。它不满足分区容错性，因为网络分区会使主节点表现得像单独的集群，它们将通过各自的写入和更新继续前进，而无需从另一个主节点获得最新数据。

@WillC 您似乎根本不了解分区容差的含义。分区容错意味着即使存在分区，您的集群也能继续工作。如果没有分区容错，这意味着一旦发生网络分区，系统就会停止工作。

@hey_you 即使系统在分区下“运行”，如果系统没有办法解决这种有两个主控的情况，那么它绝对不是分区容错的——如果你声称如果它是分区容错的，那么它就不会是一致的，因为两个主服务器会有自己的数据库版本，系统无法解析。

@hey_you 你在理论上是正确的。但是，如果没有一致性保证（最低是均匀的），那么您可以拥有一个“AP 系统”，其中您在一个连接下只有两个独立的数据库。这样的系统是没有用的。所有 AP 系统都有某种方式以某种方式解决或最小化冲突。