mongodb在CAP定理中代表什么位置？

我到处看，我看到MongoDB是CP。但是当我进行挖掘时，我看到它最终是一致的。使用safe = true时是否为CP？如果是这样，这是否意味着当我使用safe = true进行写入时，所有副本都将在获得结果之前进行更新？

默认情况下，MongoDB是高度一致的-如果您先进行写操作然后进行读操作，那么假设写操作成功，您将始终能够读取刚刚读取的写操作的结果。这是因为MongoDB是单主机系统，默认情况下所有读取都转到主数据库。如果您选择启用从辅助数据库读取，则MongoDB最终将变得一致，从而可以读取过期的结果。

MongoDB还通过副本集的自动故障转移获得了高可用性：http : //www.mongodb.org/display/DOCS/Replica+Sets

我同意卢卡斯的帖子。您不能只说MongoDB是CP / AP / CA，因为它实际上是C，A和P之间的权衡，这取决于数据库/驱动程序配置和灾难类型：这是直观的回顾，下面是更详细的解释。

    Scenario                   | Main Focus | Description
    ---------------------------|------------|------------------------------------
    No partition               |     CA     | The system is available 
                               |            | and provides strong consistency
    ---------------------------|------------|------------------------------------
    partition,                 |     AP     | Not synchronized writes 
    majority connected         |            | from the old primary are ignored                
    ---------------------------|------------|------------------------------------
    partition,                 |     CP     | only read access is provided
    majority not connected     |            | to avoid separated and inconsistent systems

一致性：

当您使用单个连接或正确的“ 写 / 读”关注级别时，MongoDB是高度一致的（这将降低您的执行速度）。一旦您不满足这些条件（尤其是当您从辅助副本读取时），MongoDB最终将变得一致。

可用性：

MongoDB通过副本集获得高可用性。一旦主要节点出现故障或其他节点不可用，则次要节点将确定新的主要节点再次可用。有一个缺点是：这是由旧的主执行，但不是同步到次级将每写回滚并保存到回滚文件，一旦它重新连接到集（旧的主是次要的现在）。因此，在这种情况下，为了可用性而牺牲了一些一致性。

分区容限：

通过使用所述副本集，MongoDB还可以实现分区容限：只要副本集中超过一半的服务器相互连接，就可以选择新的主副本。为什么？为了确保两个分开的网络不能同时选择一个新的主网络。如果没有足够的辅助连接，您仍然可以从中读取（但不能保证一致性），但不能写入。为了保持一致，该集合实际上不可用。

正如一篇精彩的新文章以及Kyle在该领域进行的一些出色实验一样，在将MongoDB和其他数据库标记为C或A时，应格外小心。

当然，CAP可以帮助您毫不费力地追查数据库在数据库中的优势，但是人们经常忘记CAP中的C意味着原子一致性（线性化）。这使我在尝试分类时难以理解。因此，除了MongoDB提供强一致性之外，这并不意味着它是C。通过这种方式，如果人们进行了这种分类，我建议也对它的实际工作方式进行更深入的研究，以免产生疑问。

是的，使用时为CP safe=true。这仅表示数据已将其保存到母版磁盘中。如果要确保它也到达某些副本上，请查看“ w = N”参数，其中N是必须保存数据的副本数。

看到这个和这个以获取更多信息。

我不确定P for Mongo。想象一下情况：

• 您的副本将分为两个分区。
• 新主人当选后，双方继续写作
• 分区已解决-现在再次连接所有服务器
• 发生的情况是选出了新的主服务器-具有最高oplog的主机，但是来自另一个主服务器的数据在分区之前已还原为普通状态，并将其转储到文件中以进行手动恢复
• 所有中学都赶上了新主人

这里的问题是转储文件的大小是有限的，如果您有一个分区很长一段时间，您可以永远丢失数据。

您可以说这不太可能发生-是的，除非在云中这种情况比人们想象的要普遍得多。

这个例子就是为什么在将任何字母分配给任何数据库之前我会非常小心的原因。场景太多，实现也不完美。

如果有人知道在更高版本的Mongo中是否解决了这种情况，请发表评论！（一段时间以来，我一直没有关注所有发生的事情。）

Mongodb绝不允许写入辅助文件。它允许从辅助目录进行可选读取，但不允许写入。因此，如果您的主服务器出现故障，您将无法编写，直到辅助服务器再次成为主服务器。这样，您就牺牲了CAP定理中的高可用性。通过仅保留主要内容的读物，您可以具有很强的一致性。

每当有分区时，MongoDB都会在可用性上选择一致性。这意味着存在分区（P）时，它会选择一致性（C）而不是可用性（A）。

为了理解这一点，让我们了解MongoDB如何执行副本集的工作。副本集具有一个主节点。提交数据的唯一“安全”方法是先写入该节点，然后等待该数据提交到集合中的大多数节点。（发送写操作时，您将看到w =多数的标志）

分区可以在以下两种情况下发生：

• 当“主要”节点发生故障时：在选择新的主要节点之前，系统不可用。
• 当主节点失去与太多辅助节点的连接时：系统变得不可用。其他中学将尝试选举新的小学，而目前的小学将辞职。

基本上，每当发生分区并且MongoDB需要决定要做什么时，它将选择一致性而不是可用性。它将停止接受对系统的写入操作，直到它认为可以安全完成这些写入操作为止。

Mongodb提供了一致性和分区容忍度。

在分布式（NoSQL）数据库的上下文中，这意味着始终需要在一致性和可用性之间进行权衡。这是因为分布式系统总是必须具有分区容忍性（即，如果它不具有分区容忍性，它将根本不是分布式数据库。）

一致性 -系统最终将变得一致。数据迟早会传播到任何地方，但是系统将继续接收输入，并且在移至下一个事务之前不会检查每个事务的一致性。

可用性 -默认情况下，Mongo DB Client（MongoDB驱动程序）将所有读/写请求发送到领导者/主节点。它使系统一致，但由于以下原因而无法使用-如果领导者从群集断开连接，则需要几秒钟的时间来选举新领导者。因此，在此期间无法进行写入和读取。