如果您的存储支持每个键的线性化和比较和设置(对于MongoDB是这样的)，您可以在客户端实现原子多键更新(可序列化的事务)。这种方法在谷歌的Percolator和CockroachDB中使用，但没有什么可以阻止你在MongoDB中使用它。

我已经创建了这种交易的一步一步的可视化。我希望它能帮助你理解它们。

如果您不介意读提交隔离级别，那么有必要看看Peter Bailis的RAMP事务。它们也可以在客户端为MongoDB实现。

在“星巴克不使用两阶段提交”中有一个很好的解释。

这不是关于NoSQL数据库，但它确实说明了一点，有时您可以承担丢失事务或使数据库暂时处于不一致的状态。

我不认为这是需要“修复”的东西。解决办法是使用acid兼容的关系数据库。当NoSQL的行为符合应用程序需求时，您可以选择一个NoSQL替代方案。

如果您的存储支持每个键的线性化和比较和设置(对于MongoDB是这样的)，您可以在客户端实现原子多键更新(可序列化的事务)。这种方法在谷歌的Percolator和CockroachDB中使用，但没有什么可以阻止你在MongoDB中使用它。

我已经创建了这种交易的一步一步的可视化。我希望它能帮助你理解它们。

如果您不介意读提交隔离级别，那么有必要看看Peter Bailis的RAMP事务。它们也可以在客户端为MongoDB实现。

使用MongoDB会丢失的一件事是多集合(表)事务。MongoDB中的原子修饰符只能针对单个文档。

如果你需要从库存中移除一件物品，同时将其添加到某人的订单中——你不能这样做。除非这两样东西——库存和订单——存在于同一个文档中(它们很可能不存在)。

我在我正在开发的一个应用程序中遇到了同样的问题，并且有两个可能的解决方案可供选择:

1)尽可能地结构化你的文档，尽可能地使用原子修饰符，对于剩下的部分，使用后台进程清理可能不同步的记录。例如，我从库存中删除项目，并使用原子修饰符将它们添加到同一文档的reservedInventory数组中。

这让我总是知道库存中没有可用的项目(因为它们是由客户预订的)。当客户结账离开时，我然后从保留库存中删除项目。这不是一个标准的交易，因为客户可以放弃购物车，我需要一些后台流程来检查并找到被放弃的购物车，并将保留的库存移回可用的库存池。

这显然不太理想，但这是大型应用程序中mongodb不能完美满足需求的唯一部分。此外，到目前为止，它工作得完美无缺。对于许多场景来说，这可能不太可能，但是由于我使用的文档结构，它非常适合。

2)与MongoDB一起使用事务性数据库。通常使用MySQL为绝对需要它们的事情提供事务，而让MongoDB(或任何其他NoSQL)做它最擅长的事情。

如果从长远来看，我的第一个解决方案不起作用，我将进一步研究结合MongoDB和MySQL，但目前第一个解决方案很适合我的需求。

从MongoDB v4.0开始，将支持多文档ACID事务。通过快照隔离，事务将提供全局一致的数据视图，并强制执行全有或全无的执行以维护数据完整性。

它们感觉像是来自关系世界的事务，例如:

with client.start_session() as s:
    s.start_transaction()
    try:
        collection.insert_one(doc1, session=s)
        collection.insert_one(doc2, session=s)
        s.commit_transaction()
    except Exception:
        s.abort_transaction()

参见https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb

MongoDB不兼容acid的说法实际上是不对的。相反，MongoDB是文档级的acid编译器。

对单个文档的任何更新都是

原子性:要么完全完成，要么没有 一致:没有读者会看到“部分应用”的更新 孤立的:同样，没有读者会看到“肮脏”的阅读 持久的:(带有适当的写作关注点)

MongoDB没有事务——也就是说，可以回滚且与acid兼容的多文档更新。

请注意，可以使用两阶段提交在单个文档的acid兼容更新之上构建事务。