为什么 MongoDB 一致不可用而 Cassandra 可用不一致？

Question

蒙戈

从这个资源我明白为什么 mongo 不是A(Highly Available)基于下面的陈述

MongoDB 支持“单主”模型。这意味着您有一个主节点和许多从节点。如果 master 宕机，其中一个 slave 会被选为 master。此过程会自动发生，但需要时间，通常为 10-40 秒。在这个新的leader选举期间，你的副本集宕机了，无法写入

是否出于同样的原因，据说 Mongo 是Consistent（因为写入没有发生，所以返回系统中的最新数据）而不是Available（不可用于写入）？

直到重新选举发生并且写操作处于挂起状态，从机返回是否可以执行读操作？选择 master 后，用户是否再次重新启动写入操作？

但我从另一个角度不明白为什么 Mongo 是highly consistent 如上所述mongodb 在 CAP 定理中的立场？,

Mongo 是consistent默认情况下所有读取都转到主服务器的情况。

但事实并非如此。如果在主/从模式下，所有读取都将转到主服务器，那么从服务器有什么用？它进一步说 If you optionally enable reading from the secondaries then MongoDB becomes eventually consistent where it's possible to read out-of-date results.这意味着 mongo 可能与主/从不一致（前提是我在返回之前没有配置对所有节点的写入）。如果所有读取和写入都进行主要操作，那么说 mongo 是一致的对我来说是没有意义的。在这种情况下，每个其他数据库（如 cassandra）也将是一致的。不是吗？

Cassandra 从这个资源 我明白为什么 CassandraA(Highly Available )基于下面的陈述

Cassandra 支持“多主”模型。单个节点的丢失不会影响集群的写入能力——因此您可以实现 100% 的写入正常运行时间

但我不明白为什么 cassandra 不是Consistent？是否因为节点不可写入（因为协调节点无法连接）可用于读取，从而返回陈旧数据？

Answer 1

通读：MongoDB、Cassandra 和 CAP 中的 RDBMS，以便更好地理解该主题。

简要定义Consistency和availability。

一致性只是意味着，当您在系统/分布式系统中写入一条数据时，您应该从系统的任何节点读取它时获得的数据相同。

可用性意味着，系统应始终可用于读/写操作。

注意：大多数系统不是，仅可用或仅一致，它们总是提供两者兼而有之

有了上面的定义，让我们看看 MongoDB 和 Cassandra 在 CAP 中的位置。

MongoDB

正如您所说，MongoDB 是highly consistent在读取和写入到同一个节点时（默认情况）。此外，您可以在 MongoDB 中选择从其他辅助节点读取，而不是仅从领导者/主要节点读取。

现在，当您尝试从二级读取数据时，您的一致性将完全取决于您希望如何读取数据：

• 您可以询问最大的数据，例如 5 秒陈旧，或者，
• 您可以说，majority为您的select语句从节点返回数据。

同样，当您从客户端写入 Mongo 领导者时，您可以说，如果数据被复制到或存储在majority服务器上，则写入成功。

显然，从上面可以看出，根据您读/写数据的方式，MongoDb 可以是高度一致的或最终一致的。

现在，可用性如何？MongoDB 几乎始终可用，但是，只有当领导者宕机时，MongoDB 才能接受写入，直到它找出新的领导者。因此，不highly available

因此，MongoDB 被归类在 CP 之下。

卡桑德拉呢？

在 Cassandra 中，没有领导者，任何节点都可以接受写入，因此即使某些节点宕机，Cassandra 集群始终可以进行写入和读取。

Cassandra 的一致性如何？ 与 MongoDB 相同，Cassandra 可以根据您读/写数据的方式最终一致或高度一致。

您可以在读/写操作中提供一致性级别，例如：

• 从一个节点读/写数据
• 从大多数/法定节点等读取/写入数据

假设您在读/写操作中将一致性级别设置为 1。因此，一旦数据写入一个副本，您的写入就成功了。现在，如果您的读取请求恰好转到数据尚未更新的另一个副本（可能是由于高网络延迟或任何其他原因），您最终将读取旧数据。

因此，Cassandra 是高度可用的，但具有可配置的一致性级别，因此并不总是一致的。

总之，在它们的默认行为中，MongoDB 在 AP 中属于 CP 和 Cassandra。

Answer 2

CAP范式中的一致性还包括MongoDB支持的“最终一致性”。与 ACID 系统相比，CAP 系统中的读取并不能保证安全返回。

简而言之，这意味着您的 Master 可以有更新的值，但如果您确实从 Slave 读取数据，它不一定返回更新的值，并且按设计不具有此更新的值也没关系。

最终一致性的概念在此处的一个很好的答案中得到了解释。

从架构上来说，Cassandra 应该是一致的；它提供了一种称为“可调一致性”的最终一致性的特殊实现，这意味着客户端应用程序可以选择处理此问题的方法 - 它甚至提供低级别的多数据中心一致性支持！Cassandra 中行不一致的大多数问题都来自这样一个事实：Cassandra 使用客户端时间戳来确定哪个值是最新的，而不是服务器端的值，这在一开始可能有点难以理解。

我希望这有帮助！