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

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

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

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

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

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

The only reason atomic modifies work against a single-collection is because the mongodb developers recently exchanged a database lock with a collection wide write-lock. Deciding that the increased concurrency here was worth the trade-off. At it's core, mongodb is a memory-mapped file: they've delegated the buffer-pool management to the machine's vm subsystem. Because it's always in memory, they're able to get away with very course grained locks: you'll be performing in-memory only operations while holding it, which will be extremely fast. This differs significantly from a traditional database system which is sometimes forced to perform I/O while holding a pagelock or a rowlock.

从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兼容更新之上构建事务。

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

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

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