mongodb在CAP定理中站在哪里？
在我看来，我看到MongoDB是CP。 但是当我深入挖掘时，我发现它最终是一致的。 当你使用safe = true时，它是CP吗？ 如果是这样，这是否意味着当我用safe = true写入时，所有副本将在得到结果之前被更新？
MongoDB在默认情况下是非常一致的 – 如果您执行写操作然后进行读操作，假设写操作成功，您将始终能够读取刚刚读取的写操作的结果。 这是因为MongoDB是一个单主系统，默认情况下所有的读取都会转到主系统。 如果您可以select启用从辅助数据读取，那么MongoDB最终会在读取过时结果的地方变得一致。
MongoDB还通过副本集中的自动故障转移获得高可用性： http : //www.mongodb.org/display/DOCS/Replica+Sets
这应该有助于回答这个问题，以及其他NoSQL和其他持久性存储系统。
作为一篇出色的新文章 ，Kyle在这个领域也进行了一些非常棒的实验，在将MongoDB和其他数据库标记为C或A时应该小心。
当然，CAP可以帮助追踪数据库中关于它的优势，但是人们经常会忘记CAP中的C意味着primefaces一致性（线性化）。 这使我在分类时很难理解。 所以，除了MongoDB强大的一致性之外，这并不意味着C就是这样，如果做这个分类的话，我也build议在实际工作中加深一点，不要留下疑虑。
是的，在使用safe=true时是CP。 这只是意味着，数据把它交给主盘。 如果你想确保它也到达了一些副本，看看'W = N'参数，其中N是数据必须保存在副本的数量。
看到这个和这个更多的信息。
我同意卢卡斯的职位。 你不能只是说MongoDB是CP / AP / CA，因为它实际上是C，A和P之间的权衡：
一致性：
当您使用单个连接或正确的写 / 读关注级别 （ 这将花费您的执行速度 ）时，MongoDB是非常一致的。 只要你不符合这些条件（尤其是当你从辅助副本读取），MongoDB变得最终一致。
可用性：
MongoDB通过副本集获得高可用性。 一旦主服务器出现故障，或者其他服务不可用，则副服务器将确定新的主服务器再次可用。 这样做有一个缺点：只要重新连接到集合，旧主节点执行的每个写操作都将被回退并保存到回滚文件（旧主节点是辅助节点现在）。 所以在这种情况下，为了可用性牺牲了一些一致性。
分区容差：
通过使用所述副本集，MongoDB也实现了分区容忍度：只要一个副本集的一半以上的服务器相互连接， 就可以select一个新的主副本。 为什么？ 确保两个分离的networking不能同时select一个新的主networking。 当没有足够的辅助人员相互连接时，仍然可以从中读取（但不能保证一致性），但不能写入。 为了保持一致性，该组几乎不可用。
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
我不确定P是否适合Mongo。 想象一下情况：
- 您的副本被分成两个分区。
- 当新的主人当选时，继续写双方
- 分区已解决 – 所有服务器现在都重新连接了
- 会发生什么情况是，新的master被选中 – oplog最高的一个，但另一个master的数据在分区之前被恢复到通用状态，并被转储到一个文件进行手动恢复
- 所有的辅助人员赶上新的主人
这里的问题是转储文件的大小是有限的，如果你有一个很长一段时间的分区，你可以永远丢失你的数据。
你可以说这不太可能发生 – 是的，除非在云中比人们想象的更普遍。
这个例子就是为什么在给任何数据库分配任何字母之前，我会非常小心的。 有这么多的场景和实现并不完美。
如果有人知道这个场景是否已经在Mongo的后续版本中解决了，请评论！ （我没有跟踪一段时间以来发生的一切..）
