CouchDB与MongoDB关于CAP（一致性、可用性、分区）原则的比较
我被couchDB和MongoDB的不同答案弄糊涂了（例如http://blog.scottlogic.com/2014/08/04/MongoDB-vs-couchdb.html这个博客告诉MongoDB是CP，couchDB是AP)，但是这个答案告诉MongoDB是AP，couchDB是CP。）
谁能解决我的困惑吗？
共有1个答案
摘自http://guide.couchdb.org/draft/consistency.html
我认为混淆可能来自这样一个事实，即您可以将couchDB作为单个节点来讨论，也可以将couchDB作为节点集群来讨论。当您将couchDB作为单个节点使用时，它将是一致的，但对于MongoDB也是如此。但是，当您将couchDB作为一个集群来使用时，一致性是首先要考虑的问题，您可能会得到不同版本的文档，这取决于您从哪个节点请求它。
-
MongoDB遵循主从架构。数据写入主节点，然后复制到从节点。据说Mongo提供了可用性的一致性，考虑到这一点，差异可以解释为： 当master关闭时，从节点必须决定选择哪个作为master，这需要时间，因此系统在该时间窗口不可用。 另一个原因可能是：在复制期间，节点被锁定，以便将数据复制到所有从机以获得高一致性，如果我们使用从机进行读取，那么锁定意味着不可用。 但是这可能会根据Mongo允许配置
-
主要内容：CouchDB vs. MongoDBCouchDB与MongoDB在架构和用途上，有很多相似的地方，详细的对比如下表中所示 - CouchDB vs. MongoDB 特征比较 CouchDB MongoDB 数据模型 它遵循面向文档的模型，数据以JSON格式呈现。 它遵循面向文档的模型，但数据以BSON格式呈现。 接口 CouchDB使用基于HTTP/REST的接口。它非常直观，设计非常好。 MongoDB在TCP/IP上使用二进
-
当我试图理解CAP中的“可用性”（A）和“分区容差”（P）时，我发现很难理解各种文章中的解释。 我觉得a和P可以同时进行（我知道事实并非如此，这就是我无法理解的原因！）。 简单地解释一下，A和P是什么，以及它们之间的区别？
-
分布式共识算法 (Consensus Algorithm) 如何理解分布式共识？ 多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论 已达成一致的结论，不可推翻 有哪些分布式共识算法? Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 paxos 具有很
-
大家都说mongoDB是CAP定理中的CP！但通过使用主从复制，它也具有高可用性（如果主复制失败，其余成员将自动尝试选择新的主复制）。我的问题是，在什么情况下（以及如何）它可以有AP（最终的一致性）？
-
使用CQRS和事件存储，微服务之间的编排提供了最终的一致性，其中一个微服务中的更改需要一点时间传播到其他相关的下游系统(本质上是其他微服务)。如果数据非常关键，以至于两个微服务都应该具有很强的数据一致性，那么有什么选择呢？我能想到的一个选择是像数据网格那样的直写缓存，但这非常脆弱，特别是在分布式系统中。