30 回答
我将把这个作为答案发布，纯粹是为了支持对话——Tim Mahy、nawroth和CraigTP提出了可行的数据库。由于使用了Erlang ， CouchDB将是我的首选，但还有其他的。
我想说ACID并不矛盾或否定NoSQL的概念......虽然似乎有一种趋势遵循dove表达的观点，但我认为这些概念是不同的。
NoSQL从根本上讲是关于简单的键值（例如 Redis）或文档样式的模式（在“文档”模型中收集的键值对，例如 MongoDB）作为经典 RDBMS 中显式模式的直接替代方案。它允许开发人员不对称地处理事物，而传统引擎在数据模型中强制执行严格的相同性。之所以如此有趣，是因为它提供了一种不同的方式来处理变化，并且对于更大的数据集，它提供了处理数量和性能的有趣机会。
ACID提供了管理如何将更改应用于数据库的原则。以一种非常简化的方式，它指出（我自己的版本）：
- (A) 当你做某事来改变一个数据库时，改变应该作为一个整体起作用或失败
- (C) 数据库应该保持一致（这是一个相当广泛的话题）
- (I) 如果其他事情同时发生，他们应该无法在更新中看到事情
- (D) 如果系统崩溃（硬件或软件），数据库需要能够自行恢复；如果它说它已完成应用更新，则需要确定
当谈到传播和约束的想法时，谈话变得更加令人兴奋。一些 RDBMS 引擎提供了强制执行可能具有传播元素（la cascade）的约束（例如外键）的能力。简而言之，一个“事物”可能与数据库中的另一个“事物”有关系，如果您更改一个“事物”的属性，则可能需要更改另一个（更新、删除、...很多选项）。NoSQL数据库，主要（目前）专注于高数据量和高流量，似乎正在解决在（从消费者的角度）任意时间范围内发生的分布式更新的想法。这基本上是一种特殊的复制形式，通过事务——所以我想说，如果传统的分布式数据库可以支持 ACID，那么 NoSQL 数据库也可以。
一些供进一步阅读的资源：
更新（2012 年 7 月 27 日）： 维基百科文章的链接已更新，以反映发布此答案时的最新文章版本。请注意，当前的维基百科文章已被广泛修改！
好吧，根据关于 NoSQL 的 Wikipedia 文章的旧版本：
NoSQL 是一项促进松散定义的非关系数据存储类的运动，它打破了关系数据库和 ACID 保证的悠久历史。
并且：
该名称试图描述越来越多的非关系分布式数据存储的出现，这些存储通常不尝试提供 ACID 保证。
和
NoSQL 系统通常提供弱一致性保证，例如最终一致性和仅限于单个数据项的事务，即使可以通过添加补充中间件层来强制执行完整的 ACID 保证。
所以，简而言之，我想说“NoSQL”数据存储的主要好处之一是它明显缺乏ACID。此外，恕我直言，尝试实现和强制执行ACID属性的次数越多，您获得的“NoSQL”数据存储的“精神”就越远，并且您获得的“真正的” RDBMS越接近（相对而言，当然）。
然而，话虽如此，“NoSQL”是一个非常模糊的术语，并且可以接受个人解释，并且在很大程度上取决于你有多少纯粹的观点。例如，大多数现代 RDBMS 系统实际上并没有完全遵守Edgar F. Codd的关系模型的12条规则！
采用务实的方法，Apache 的CouchDB似乎最接近体现 ACID 合规性，同时保留松散耦合、非关系的“NoSQL”心态。
请确保您阅读了 Martin Fowler 关于 NoSQL 数据库的介绍。以及相应的视频。
首先，我们可以区分两种 NoSQL 数据库：
- 面向聚合的数据库；
- 面向图的数据库（例如 Neo4J）。
按照设计，大多数面向图的数据库都是 ACID！
那么，其他类型呢？
在面向聚合的数据库中，我们可以放置三种子类型：
- 基于文档的 NoSQL 数据库（例如 MongoDB、CouchDB）；
- Key/Value NoSQL 数据库（例如 Redis）；
- 列族 NoSQL 数据库（例如 Hibase、Cassandra）。
我们在这里所说的聚合，是 Eric Evans 在其领域驱动设计中将其定义为在给定的有界上下文中自给自足的实体和值对象。
因此，聚合是我们作为一个单元与之交互的数据集合。聚合形成数据库 ACID 操作的边界。（马丁·福勒）
因此，在聚合级别，我们可以说大多数 NoSQL 数据库可以像 ACID RDBMS 一样安全，只要设置适当。当然，如果您将服务器调整为最佳速度，您可能会遇到非 ACID 的问题。但复制会有所帮助。
我的主要观点是，您必须按原样使用 NoSQL 数据库，而不是作为 RDBMS 的（廉价）替代品。我见过太多滥用文档之间关系的项目。这不可能是酸。如果您停留在文档级别，即处于聚合边界，则不需要任何事务。您的数据将与 ACID 数据库一样安全，即使它不是真正的 ACID，因为您不需要这些事务！如果您需要事务并一次更新多个“文档”，那么您将不再处于 NoSQL 世界中 - 所以请改用 RDBMS 引擎！
一些 2019 更新：从 4.0 版本开始，对于需要原子性来更新多个文档或读取多个文档之间的一致性的情况，MongoDB为副本集提供了多文档事务。
在这个问题中，有人必须提到OrientDB：OrientDB 是一个 NoSQL 数据库，是少数支持完全 ACID 事务的数据库之一。ACID 不仅适用于 RDBMS，因为它不是关系代数的一部分。所以有可能有一个支持 ACID 的 NoSQL 数据库。
这个特性是我在MongoDB中最怀念的一个
FoundationDB 符合 ACID：
它具有适当的事务，因此您可以以 ACID 方式更新多个不同的数据项。这被用作在更高层维护索引的基础。
ACID 和 NoSQL 是完全正交的。一个并不意味着另一个。
我的办公桌上有一个笔记本，我用它来记录我仍然需要做的事情。这个笔记本是一个 NoSQL 数据库。我使用带有“页面缓存”的线性搜索来查询它，因此我不必总是搜索每一页。它也符合 ACID，因为我确保我一次只写一件事，而不是在阅读时。
NoSQL 只是意味着它不是 SQL。许多人感到困惑，并认为这意味着高度可扩展的狂野西部超快速存储。它没有。这并不意味着键值存储或最终一致性。它的意思是“不是 SQL”，这个星球上有很多数据库，其中大多数不是 SQL [需要引用]。
您可以在其他答案中找到许多示例，因此我无需在此处列出它们，但是有非 SQL 数据库对各种操作具有 ACID 合规性，有些仅用于单个对象写入的 ACID，而有些则保证更多。每个数据库都是不同的。
“NoSQL”不是一个定义明确的术语。这是一个非常模糊的概念。因此，甚至不能说什么是“NoSQL”产品，什么不是“NoSQL”产品。并非几乎所有带有典型标签的产品都是键值商店。
作为 NoSQL 的创始人之一（我是 Apache CouchDB 的早期贡献者，也是2009 年在 CBS Interactive / CNET 举行的第一届 NoSQL 活动的发言人），我很高兴看到新算法创造了以前不存在的可能性. Calvin 协议提供了一种考虑物理约束（如 CAP 和PACELC ）的新方法。
Calvin 不是主动/被动异步复制或主动/主动同步复制，而是通过使用类似RAFT 的协议来维护事务日志，从而在副本中断期间保持正确性和可用性。此外，事务在每个副本上都被确定地处理，消除了死锁的可能性，因此只需一轮共识即可达成一致。这使得它即使在多云全球部署中也能快速运行。
FaunaDB是唯一使用 Calvin 协议的数据库实现，使其特别适合需要类似于大型机的数据完整性以及 NoSQL 规模和灵活性的工作负载。
是的，MarkLogic Server 是一种适用于 ACID 事务的 NoSQL 解决方案（我喜欢称之为文档数据库）
NoSQL 之祖：ZODB 是 ACID 兼容的。http://www.zodb.org/
但是，它只是 Python。
如果您正在寻找符合 ACID 的键/值存储，可以使用Berkeley DB。在图数据库中，至少Neo4j和HyperGraphDB提供 ACID 事务（HyperGraphDB 目前实际上使用 Berkeley DB 进行低级存储）。
提到了 FoundationDB，当时它还不是开源的。前两天苹果已经开源了： https ://www.foundationdb.org/blog/foundationdb-is-open-source/
我相信它是符合 ACID 的。
新SQL
这个概念维基百科贡献者定义为：
[…] 一类现代关系数据库管理系统，旨在为在线事务处理 (OLTP) 读写工作负载提供与 NoSQL 系统相同的可扩展性能，同时仍保持传统数据库系统的 ACID 保证。
[1][2][3]
参考
[1]Nancy Lynch 和 Seth Gilbert，“布鲁尔猜想和一致、可用、容错 Web 服务的可行性”</a>，ACM SIGACT 新闻，第 33 卷第 2 期（2002 年），第 2 页。51-59。
[2] “Brewer 的 CAP 定理”，julianbrowne.com，2010 年 3 月 2 日检索
[3] “分布式系统上的 Brewers CAP 定理”，royans.net
MongoDB 宣布其 4.0 版本将符合 ACID 的多文档事务。
4.2 版。应该在分片设置下支持它。
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
看看 CAP 定理
编辑：RavenDB 似乎符合 ACID
Hyperdex Warp http://hyperdex.org/warp/ Warp（ACID 功能）是专有的，但 Hyperdex 是免费的。
要添加到替代列表中，另一个完全符合 ACID 的 NoSQL 数据库是GT.M。
db4o
与滚动你自己的持久性或序列化不同，db4o 是 ACID 事务安全的，并允许在运行时进行查询、复制和模式更改
BergDB是一个轻量级、开源的 NoSQL 数据库，从一开始就设计用于运行 ACID 事务。实际上，BergDB 比大多数 SQL 数据库“更多”ACID，因为改变数据库状态的唯一方法是运行具有最高隔离级别的 ACID 事务（SQL 术语：“可序列化”）。脏读、不可重复读或幻读永远不会有任何问题。
在我看来，数据库仍然是高性能的；但不要相信我，我创建了这个软件。不如自己试试。
Tarantool 是一个完全 ACID 的 NoSQL 数据库。您可以发出 CRUD 操作或存储过程，一切都将严格按照 ACID 属性运行。你也可以在这里阅读：http: //stable.tarantool.org/doc/mpage/data-and-persistence.html
MarkLogic 也是 ACID 兼容的。我认为是现在最大的球员之一。
等待结束。
符合 ACID 的 NoSQL DB 已出 ----------- 看看citrusleaf
许多现代 NoSQL 解决方案不支持 ACID 事务（原子隔离多键更新），但它们中的大多数都支持允许您在应用程序级别实现事务的原语。
如果数据存储支持每个键的线性化和比较和设置（文档级原子性），那么实现客户端事务就足够了，此外，您还有几个选项可供选择：
如果您需要 Serializable 隔离级别，那么您可以遵循 Google 用于Percolator系统或 Cockroach Labs 用于CockroachDB的相同算法。我已经写了一篇关于它的博客并创建了一步一步的可视化，我希望它能帮助你理解算法背后的主要思想。
如果您预计会出现高争用，但您可以拥有已提交读隔离级别，那么请查看 Peter Bailis 的RAMP 事务。
第三种方法是使用补偿事务，也称为 saga 模式。它在 80 年代后期的Sagas论文中有所描述，但随着分布式系统的兴起而变得更加实际。请参阅应用 Saga 模式演讲以获取灵感。
适用于客户端事务的数据存储列表包括具有轻量级事务的 Cassandra、具有一致存储桶的 Riak、RethinkDB、ZooKeeper、Etdc、HBase、DynamoDB、MongoDB 等。
DynamoDB 是一个 NoSQL 数据库，具有ACID 事务。
YugaByte DB在查询层支持符合ACID 的分布式 txns以及 Redis 和 CQL API 兼容性。
VoltDB是声称符合 ACID 的参与者，虽然它仍然使用 SQL，但其目标在可扩展性方面是相同的
节点 levelUP 是事务性的，建立在 leveldb https://github.com/rvagg/node-levelup#batch
虽然它只是一个嵌入式引擎而不是服务器，但leveldb具有 WriteBatch 和打开同步写入以提供 ACID 行为的能力。
不仅 NoSQL 在设计上不符合 ACID。NoSQL 运动拥抱声称与 ACID 相反的 BASE（基本可用、软状态、最终一致性）。NoSQL 数据库通常被称为最终一致的数据库。要了解差异，您应该深入研究 CAP 定理（又名 Brewer 定理）
访问http://www.julianbrowne.com/article/viewer/brewers-cap-theorem