蒙哥布在 CAP 定理中处于什么位置？

小开

是的，当使用 safe=true时它是 CP。这只是意味着，数据到达了主盘。如果您希望确保它也到达了某个副本上，请查看‘ w = N’参数，其中 N 是必须保存数据的副本数。

有关详细信息，请参阅这个和这个。

小开

最佳答案

MongoDB 在默认情况下是强一致的——如果你先写，然后再读，假设写是成功的，你总是能够读取刚才读取的写的结果。这是因为 MongoDB 是一个单主系统，默认情况下所有读操作都会进入主系统。如果您可以选择启用从辅助服务器读取，那么 MongoDB 在可以读取过时结果的地方最终会变得一致。

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

小开

由于出现了一个很棒的新文章以及该字段中的一些很棒的实验，所以在将 MongoDB 和其他数据库标记为 C 或 A 时应该小心。

当然，CAP 有助于在没有太多词汇的情况下跟踪数据库的优势，但是人们常常忘记 CAP 中的 C 意味着原子一致性(例如可线性化)。这让我在分类的时候感到很痛苦。因此，除了 MongoDB 提供了很强的一致性之外，这并不意味着它就是 C。通过这种方式，如果一个人做了这个分类，我建议在它实际上是如何工作的方面给予更多的深度，不要留下怀疑。

小开

我不确定 P 代表 Mongo 想象一下:

您的复制品被分成两个分区。
随着新的大师的选举，双方的书信仍在继续
分区已解决-所有服务器现在再次连接
发生的情况是，选择了新的主服务器——具有最高 oplog 的主服务器，但是来自另一个主服务器的数据在分区之前恢复到公共状态，并将其转储到一个文件中进行手动恢复
所有的中学都赶上了新老师

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

你可以说这不太可能发生——是的，除非在云中，这种情况比人们想象的更常见。

这个例子说明了为什么我在将任何字母分配给任何数据库之前都要非常小心。有太多的场景和实现并不完美。

如果有人知道这个场景是否已经在 Mongo 的后续版本中解决了，请评论！(我已经有一段时间没有关注发生的所有事情了。.)

小开

我同意卢卡斯的观点。你不能仅仅说 MongoDB 是 CP/AP/CA，因为它实际上是一个 C、 A 和 P 之间的权衡取决于数据库/驱动程序配置和灾难类型: 这里是一个可视化的概述，下面是一个更详细的解释。

场景	主要焦点	描述
没有分区	CA	该系统是可用的，并提供了很强的一致性
分区，多数连接	美联社	未同步的来自旧主服务器的写操作将被忽略
分区，多数未连接	CP	只提供读访问，以避免分离和不一致的系统

一致性:

当您使用单个连接或正确的写作/阅读关注级别(这会降低你的执行速度)时，MongoDB 是强烈一致的。一旦您不满足这些条件(特别是当您从一个二级副本中读取数据时) ，MongoDB 就会变得最终一致。

可用性:

MongoDB 通过 abc0获得高可用性。一旦主服务器关闭或者其他服务器不可用，那么辅助服务器将确定一个新的主服务器再次可用。这样做有一个缺点: 每一次由旧主服务器执行但没有同步到二级服务器的写操作都将是后退，并且一旦它重新连接到集合(旧主服务器现在是二级服务器) ，就会被保存到一个回滚文件中。因此，在这种情况下，为了可用性而牺牲了一些一致性。

分区容差:

通过使用上述的 Replica-Set MongoDB 也实现了分区容忍: 只要一个 Replica-Set 的一半以上的服务器相互连接，可以选择一个新的初选。为什么？确保两个分离的网络不能同时选择一个新的主网。当没有足够的辅助设备相互连接时，您仍然可以从它们读取(但不能保证一致性) ，但不能写入。为了保持一致性，该集实际上是不可用的。

小开

Mongodb 从不允许写到次级。它允许从辅助设备进行可选的读操作，但不允许写操作。因此，如果你的主要下降，你不能写，直到一个次要成为主要再次。这就是为什么在 CAP 定理中牺牲高可用性。通过保持您的阅读只从主要您可以有很强的一致性。

小开

MongoDB 在有分区的情况下选择一致性优于可用性。它的意思是，当有一个分区(P)时，它选择一致性(C)而不是可用性(A)。

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

可以在以下两种情况下进行分区:

当主节点关闭时: 系统将不可用，直到出现新的初选已选定。
当主节点从太多次要节点: 系统变得不可用。其他次要节点将尝试选举一个新的小学，当前的小学将下台。

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

小开

蒙哥布放弃了。当我们在 CAP 定理的上下文中讨论可用性时，它是关于避免可能下降的单点故障。在蒙戈德布。有一个主路由器主机。如果出了问题，在它选择一个新的替代服务器代替它的时候会有一些停机时间。实际上，这很快就会发生。我们确实有一些热门的备用设备。所以一旦系统检测到主路由主机故障它就会立刻切换到新的路由主机。从技术上讲，它仍然是单点故障。当这种情况发生时，仍然存在停机的可能性。

有一个配置服务器，它是主服务器，我们有一个应用程序服务器，它在任何给定时间都是主服务器。即使我们有多个备份，如果那些服务器中的任何一个出现故障，都会有短暂的停机时间。系统必须首先检测到有一个中断，然后剩余的服务器需要重新选择一个新的主主机来取代它的位置。这可能需要几秒钟，这就足以说明 mongodb 正在牺牲可用性