MongoDB：可用性与一致性
MongoDB遵循主从架构。数据写入主节点，然后复制到从节点。据说Mongo提供了可用性的一致性，考虑到这一点，差异可以解释为：
当master关闭时，从节点必须决定选择哪个作为master，这需要时间，因此系统在该时间窗口不可用。
另一个原因可能是：在复制期间，节点被锁定，以便将数据复制到所有从机以获得高一致性，如果我们使用从机进行读取，那么锁定意味着不可用。
但是这可能会根据Mongo允许配置从属角色的配置而有所不同。我们可以将它们仅用于副本目的（在这种情况下，可能不需要从属锁定，因为读取请求仅由master提供，并且复制可以异步发生）或者我们也可以为读取操作使用从属（在这种情况下，当写入发生时可能需要锁定，以便保持一致性）。
所以我发现有很多可能的变化。
那么，我们有基本的规则来定义所有这些吗？
共有1个答案
MongoDB允许您根据您的用例需求定制行为，您可以通过以下设置调整一致性/可用性/性能：
读取首选项可能值：
["primary","primaryPreferred","secondary","secondaryPreferred","nearest"]
写下可能的值：
["majority",0,1,2,n]
阅读关注可能的值：
["local","available","majority","linearizable","snapshot"]
记录可能的值：
["true","false"]
此外，这个问题之前已经在这里详细讨论过了
-
我被couchDB和MongoDB的不同答案弄糊涂了（例如http://blog.scottlogic.com/2014/08/04/MongoDB-vs-couchdb.html这个博客告诉MongoDB是CP，couchDB是AP)，但是这个答案告诉MongoDB是AP，couchDB是CP。） 谁能解决我的困惑吗？
-
蒙戈 从这一资源中，我理解了为什么mongo不是基于以下陈述的 MongoDB支持“单主”模型。这意味着您有一个主节点和多个从节点。如果主人倒台，其中一个奴隶被选为主人。这个过程会自动进行，但需要时间，通常为10-40秒。在新领导人选举期间，您的副本集已关闭，无法进行写入 是否出于同样的原因，Mongo被称为（因为写入没有发生，所以返回系统中的最新数据），但不是（不适用于写入）？ 在重新选择和写入
-
使用CQRS和事件存储，微服务之间的编排提供了最终的一致性，其中一个微服务中的更改需要一点时间传播到其他相关的下游系统(本质上是其他微服务)。如果数据非常关键，以至于两个微服务都应该具有很强的数据一致性，那么有什么选择呢？我能想到的一个选择是像数据网格那样的直写缓存，但这非常脆弱，特别是在分布式系统中。
-
如果缓存一致性是在硬件级别实现的，为什么我们需要volatile？任何核心/处理器都应该获得最新的值？ 还是它完全在处理一个不同的问题？
-
大家都说mongoDB是CAP定理中的CP！但通过使用主从复制，它也具有高可用性（如果主复制失败，其余成员将自动尝试选择新的主复制）。我的问题是，在什么情况下（以及如何）它可以有AP（最终的一致性）？
-
好死不如赖活着—— Jay Kreps, 关于Kafka与 Jepsen的若干笔记 (2013) [TOC] 正如第8章所讨论的，分布式系统中的许多事情可能会出错。处理这种故障的最简单方法是简单地让整个服务失效，并向用户显示错误消息。如果无法接受这个解决方案，我们就需要找到容错的方法—— 即使某些内部组件出现故障，服务也能正常运行。 在本章中，我们将讨论构建容错分布式系统的算法和协议的一些