解决跨2个DB实例的CouchDB文档冲突的最佳方法是什么？

我有一个应用程序在NodeJS上运行，我正在尝试制作一个分布式应用程序。所有的写入请求都会发送到节点应用程序，它会写入CouchDB A，成功后会写入CouchDB B。我们通过ELB（从2个DBs读取）读取数据。它工作正常

但是我最近遇到了一个问题，我的CouchDB宕机了，CouchDB启动后，现在两个实例之间的文档版本不匹配

---

在没有停机时间的情况下，解决上述情况的最佳方法是什么

如果您的CouchDB A和CouchDB B位于同一个数据中心，那么@Flimzy建议在集群部署中使用CouchDB 2.0是一个不错的选择。您可以在集群中配置

n

CouchDB节点，并在集群上方配置负载平衡器，将HTTP（s）通信量传递给任何处于“启动”状态的节点

如果A&B在地理位置上是分开的，则可以使用从A-->B和B-->A移动数据，这将使两个实例保持完全同步。A&B可以是3个或更多CouchDB 2.0节点的集群，也可以是CouchDB 1.7的单个实例

当数据库的两个副本同时以不同方式修改时，这些解决方案都无法“修复”您所看到的问题。这种“冲突”状态是CouchDB防止两次写入冲突时数据丢失的方法。您的应用程序可以通过选择一个获胜的修订版或编写一个新的修订版来解决冲突。这不是一种故障情况，而是帮助您的应用程序从分布式系统中并发写入期间的数据丢失中恢复

---

您可以阅读更多信息。

如果您的两个1.6.x节点都在使用标准复制同步存储桶，那么关闭一个节点应该不是问题。在节点向上时，它接收所有更新而没有冲突-因为无法进行更新，所以节点已关闭

如果您在正常操作期间遇到冲突，不幸的是，没有通用的方法自动解决冲突。然而，在大多数情况下，您可以找到一种标记受影响文档子树的策略，这种策略允许确定哪一个subversion是最近的（或更重要的）

要检测存在冲突的文档，您可以使用标准视图：如果存在冲突修订，则视图功能接收的文档具有

\u conflicts

属性。使用适当的视图可以检测冲突并合并文档。无论如何，无论您如何检测冲突，您都需要外部代码来解决冲突

<>如果你的冲突数据本质上是数字的，考虑使用CRDT结构和标准MAP/Read来获得最终值。如果您的数据是文本，您也可以尝试使用CRDT，但是为了获得合理的性能，您需要使用用Erlang编写的减缩器

至于2.x。我不建议在您的案例中使用2.x（实际上，对于除实验之外的任何真实案例）。首先，使用2.x不会消除冲突，因此它不能解决您的问题。此外，考虑到Account2.x需要跨节点执行大量记录不清的手动操作，并且无法重新平衡，您将得到比价值更大的痛苦

顺便说一句，使用任何集群解决方案对两个节点都没有什么意义

---

对于上述CVE 12635和CouchDB 1.6.x：您可以使用此修补程序来覆盖漏洞。

为什么不使用CouchDB的内置群集支持，而不是重新发明轮子？@Flimzy非常感谢您的建议。我也会努力做到这一点。但是我当前的应用程序是在couchDB 1.6的生产环境中运行的（我希望它不支持集群），我也不能这么快地运行。你能提供一些更好的方法来解决我目前的问题吗？最简单的解决方案是升级到CouchDB 2.1。另一种方法是自己编写相同的功能，这将花费更长的时间，并且更容易出错。（另外请注意，由于最近发现了一个严重的安全漏洞，您不应该再使用CouchDB 1.6。请立即更新到1.7或2.1）非常感谢您的简短回答。我遇到一篇文章“通常复制更新得这么快，但由于写负载的原因可能需要一段时间，如果客户端连续快速发送多个请求，很有可能再次更新文档时会碰到CouchDB，CouchDB将拒绝写入，因为_rev不再匹配…”有关详细信息，请查找此链接（）。那么在这种情况下，我们将如何管理？