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

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

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

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

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

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

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

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

“不能正确保存”可能意味着:

By default MongoDB does not save your changes to the drive immediately. So there is a possibility that you tell a user "update is successful", power outage happens and the update is lost. MongoDB provides options to control level of update "durability". It can wait for the other replica(s) to receive this update (in memory), wait for the write to happen to the local journal file, etc. There is no easy "atomic" updates to multiple collections and even multiple documents in the same collection. It's not a problem in most cases because it can be circumvented with Two Phase Commit, or restructuring your schema so updates are made to a single document. See this question: Document Databases: Redundant data, references, etc. (MongoDB specifically)

“在MongoDB中，单个文档上的操作是原子的”——这是过去的事情

在MongoDB 4.0的新版本中，您可以:

However, for situations that require atomicity for updates to multiple documents or consistency between reads to multiple documents, MongoDB provides the ability to perform multi-document transactions against replica sets. Multi-document transactions can be used across multiple operations, collections, databases, and documents. Multi-document transactions provide an “all-or-nothing” proposition. When a transaction commits, all data changes made in the transaction are saved. If any operation in the transaction fails, the transaction aborts and all data changes made in the transaction are discarded without ever becoming visible. Until a transaction commits, no write operations in the transaction are visible outside the transaction.

尽管对于如何执行和执行什么操作有一些限制。

检查Mongo Doc。 https://docs.mongodb.com/master/core/transactions/

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.

我认为其他人已经给出了很好的答案。 然而，我想补充的是，有ACID NOSQL数据库(如http://ravendb.net/)。所以这不仅仅是NOSQL - no ACID vs关系型ACID....的决定