mongodb在CAP定理中的位置是什么？
Glu*_*luz 107 database mongodb nosql cap-theorem
无论我到哪里,我都看到MongoDB是CP.但是当我深入挖掘时,我发现它最终是一致的.当你使用safe = true时它是CP吗？如果是这样,这是否意味着当我使用safe = true写入时,所有副本将在获得结果之前更新？
Tim*_*rez 121
这应该有助于回答这个问题,以及其他NoSQL和其他持久性存储系统.
- 请注意,这个图像过于简单,没有CA分布式系统 - 了解这一点请阅读:https://codahale.com/you-cant-sacrifice-partition-tolerance/ (7认同)
- 这看起来很有趣,但有没有引用或原创博客被取消？我想读完整件事. (3认同)
stb*_*ody 92
默认情况下,MongoDB非常一致 - 如果您执行写操作然后执行读操作,假设写入成功,您将始终能够读取刚刚读取的写入结果.这是因为MongoDB是一个单主系统,默认情况下所有读取都转到主系统.如果您可以选择启用从辅助节点读取,那么MongoDB最终会在可以读取过期结果的地方保持一致.
MongoDB还通过副本集中的自动故障转移获得高可用性:http://www.mongodb.org/display/DOCS/Replica+Sets
- 根据https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads,即使您从副本集中的主节点读取,也可能会收到过时或脏的数据.所以MongoDB强大一致吗？ (9认同)
- 只是为了记录,MongoDB v3.4通过了Kyle设计的测试,所以是的,即使使用ReplicaSet和Sharding,MongoDB仍然非常一致:https://www.mongodb.com/mongodb-3.4-passes-jepsen-test (4认同)
- 凯尔很棒的实验.它真的杀死了mongo.我想知道是否有生产系统,例如使用MongoDB进行支付交易？如果它只是一个个人网站,那么谁会关心强大的一致性. (3认同)
- 这个答案可能有点过于简单,因为MongoDB可能会根据配置不时牺牲可用性.JoCa更好地解释了CA/CP/AP的行为情况 (2认同)
- 郑重声明，我不再完全坚持 9 年前的原始评论。CAP 理论是推理此类系统的一种糟糕方法，因为它对现实进行了极大的简化。存在网络分区时的一致性和可用性是一个有很多小权衡的范围，而不是单一的二进制。虽然这篇文章中的所有答案都有点过于简单化，包括我的答案，但 JoCa 的答案可能最接近完整的情况。 (2认同)
JoC*_*oCa 27
我同意Luccas的帖子.你不能只说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也实现了分区容错:只要副本集的一半以上的服务器相互连接,就可以选择新的主服务器.为什么？要确保两个独立的网络不能同时选择新的主要网络.如果没有足够的辅助设备彼此连接,您仍然可以从它们读取(但不保证一致性),但不能写入.为了保持一致性,该组几乎不可用.
小智 6
只要存在分区，MongoDB 就会选择一致性而不是可用性。这意味着当存在分区（P）时，它会选择一致性（C）而不是可用性（A）。
为了理解这一点，让我们了解 MongoDB 的副本集是如何工作的。副本集有一个主节点。提交数据的唯一“安全”方法是写入该节点，然后等待该数据提交到集合中的大多数节点。（发送写入时您将看到 w=majority 的标志）
分区可能发生在以下两种情况：
- 当主节点出现故障时：系统将变得不可用，直到选择新的主节点。
- 当主节点与太多辅助节点失去连接时：系统变得不可用。其他辅助节点将尝试选举新的主节点，当前的主节点将下台。
基本上，每当发生分区并且 MongoDB 需要决定做什么时，它都会选择一致性而不是可用性。它将停止接受对系统的写入，直到它相信它可以安全地完成这些写入。