为什么在CAP定理中没有RDBMS分区容忍以及为什么它可用？

Question

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

1)它说RDBMS 不是 分区容忍但是RDBMS如何比MongoDB或Cassandra等其他技术更少分区容忍？是否存在RDBMS设置,我们放弃CA以使其成为AP或CP？

2)CAP如何可用？是通过主从设置吗？在主机死机时,从机接管写入？

我是DB架构和CAP定理的新手所以请耐心等待.

Answer 1

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

一致性：不管处理请求的节点是什么，查询Q都会产生相同的答案A。为了保证完全一致性，我们需要确保所有节点在任何时候都同意相同的值。不要与最终一致性相混淆，即网络朝着所有数据一致的方向发展，但在某些时间段内并非如此。

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

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

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

CP的示例：

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

接入点示例：

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

CA 的示例：

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

回答问题：

1. 在默认配置下，Cassandra 和 MongoDB 等数据库是分区容错的，因为它们不会关闭节点来处理分区，而 RDBMS（如 MySQL）则可以。

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

Answer 2

现在很多数据库实际上有不同的配置,根据你设置的设置,它可以是CA,CP,AP等,但不能同时实现这三个.一些数据库实际上努力支持所有三个,但仍以某种方式对它们进行优先级排序.

例如,MySQL可以是CP和CA,具体取决于配置.默认情况下,它是CA,因为它遵循主从属范例,该数据被复制到从属数据库.如果一组从站失去与主站的连接,则会牺牲分区容差,因此决定选择一个新的主站创建具有自己的一组从站的两个主站.

但是,MySQL还有另一种配置,它是一种集群配置.它优先考虑CP的可用性,例如.如果没有足够的活动节点来提供所有数据,群集将关闭.

可能有更多的MySQL配置使其满足其他CAP定理组合,但总体而言,我只是想说它取决于您的系统需要什么.有时数据库对于一种配置比另一种配置更好,因此最好看看在使用某种配置时可能出现的问题类型.

至于实现CAP定理,我建议进一步研究不同的数据库以及它们如何实现CAP定理的优先级.实现它们的方式太多了,例如.通常,主从模型用于CA系统,AP系统的哈希环等.

Answer 3

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

\n\n

所以要回答你的问题1）它\xe2\x80\x99s要么是CP要么是AP。它可以按照 Will 提到的进行配置。

\n\n

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

\n\n

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

\n