Mongo CP，Cassandra AP？

Question

我在网上读了很多文章，但仍然很困惑为什么 Mongo CP、Cassandra AP、RDBMS CA ？将解释我的理解和疑问。

蒙戈

考虑这样一个场景，我有一个主人和两个奴隶。考虑

1. 写请求到达并发送给主设备。
2. 它仅在主设备上提交，但主设备在写入从设备之前就关闭（崩溃）
3. 直到重新选举master为止，写请求需要等待，系统不可用
4. 一旦前一个节点（在步骤 2 中崩溃的节点）返回，来自该节点的待处理写入将被写回从属节点。这称为最终一致性。

根据我的理解，由于步骤 3 和 4，Mongo 被称为 CP，其中 C 代表最终一致。正确的 ？

卡桑德拉

这里没有主/从模型，每个节点根据分片键接收其共享的写入和读取请求。

1. 写请求到达任意节点（称为协调节点）。
2. 协调节点根据分片键重定向到其中一个节点
3. 它已提交，但在写入其他复制节点之前节点已关闭（崩溃）。
4. 再次使用相同的分片键写入请求，现在协调节点将其立即重定向到副本节点（崩溃节点的副本）
5. 一旦前一个节点（在步骤 3 中崩溃的节点）返回，来自该节点的待处理写入将被写回到副本节点。那么 cassandra 似乎也是最终一致的？

步骤 4 解释了为什么 cassandra 具有高可用性，但步骤 5 也描述了其最终一致性。因此，根据我的理解，cassandra 提供了最终一致性和可用性。那为什么说它不提供一致性呢？

Answer 1

C代表最终一致。正确的 ？

CAP定理中的一致性是指强一致性，即每次读取都收到最近的写入或错误。默认情况下，MongoDB 驱动程序将所有读取和写入定向到副本集的主副本，这是强一致的。

CAP 定理断言，在发生网络分区时，分布式系统必须在一致性和可用性之间进行选择。MongoDB 的副本集方法使用单个主数据库来实现写入一致性 (CP)，而 Cassandra 的复制策略则偏向于写入可用性 (AP)。网络分区不可能实现强一致性，因为如果分区的两侧都更新相同的数据，则可能会发生冲突。为了保持写入可用性，AP数据库系统需要一个解决冲突的解决方案，这是与最终一致性分开考虑的。

然而，CAP 是现实世界行为的简化：MongoDB 和 Cassandra 都具有可调的读取和写入一致性级别。例如：MongoDB 具有写入关注点来确定写入操作所需的确认级别，读取首选项用于将请求路由到副本集的成员，以及读取关注点来控制从复制集读取的数据的新近度、一致性和隔离属性分片部署。

CAP 定理的作者 Eric Brewer 在 2012 年以更细致的方式重新审视了这一点：CAP 十二年后：“规则”如何改变。

3. 直到重新选举master为止，写请求需要等待，系统不可用

没有主数据库就无法写入，但副本集仍然具有读取可用性。MongoDB 3.6 添加了可重试写入功能，可以帮助应用程序更好地处理副本集选择和瞬时网络错误。

4. 一旦前一个节点（在步骤 2 中崩溃的节点）返回，来自该节点的待处理写入将被写回从属节点。

如果 MongoDB 副本集中的主节点不可用，并且存在符合条件的辅助节点和投票成员的法定人数，则副本集的其余成员将选择新的主节点。在您的示例中，投票多数将是副本集的 2/3 成员。前主节点接受的、未写入大多数副本集成员的任何写入都将回滚（保存到磁盘），以便前主节点从与当前主节点的历史记录一致的状态恢复同步。