大多数流行的NoSQL数据库（MongoDB、RethinkDB）不支持ACID事务。它们如今在不同系统的开发人员中非常流行。
问题是：如何在没有事务的情况下保证数据一致性？ 我认为数据一致性是生产中最重要的事情之一。我错了吗？ 也许有一些技术可以恢复数据一致性？
我想在我的项目中使用 RethinkDB，但我害怕错过交易。
我对RethinkDB了解不多，所以这个答案主要基于MongoDB。
虽然MongoDB不能同时提供对多个文档的原子操作，但它确实保证了影响一个文档的单个操作的原子性。这意味着当一个查询更改同一文档的多个字段时，您可以确保所有这些更改都将同时执行。结合 MongoDB 在一个文档中保持一致的数据集而不是将其分布在不同相关表的多行中的理念，这消除了许多需要在关系数据库中进行事务的情况。
并非每个项目都需要复杂的交易。当然，在某些领域它是必不可少的（就像大多数处理金钱的情况一样），但在其他情况下，当某些数据在几毫秒内不一致时，它实际上并不是什么大问题。您需要考虑数据一致性对于您的项目有多重要。当您得出结论认为在很多情况下确实需要事务时，请务必坚持使用 SQL。
在紧要关头，MongoDB 可以通过使用两阶段提交模型来模拟多文档事务。它不容易实现，也不容易使用，它不会产生漂亮的数据模型，但当你有一个在所有方面都适合 MongoDB 的项目（除了一个用例之外）时，它是一种有效的解决方法没有交易就离不开它。
许多流行的 NoSQL 数据存储不支持盒子的原子多键更新（事务），但大多数都提供基元，允许您在应用程序级别构建 ACID 事务。
如果数据存储支持每个键的线性化和比较和设置操作（原子文档更新），那么就足以实现可序列化的客户端事务。例如，这种方法用于 Google 的 Percolator 和 CockroachDB 数据库。
在我的博客中，我创建了可序列化跨分片客户端事务的分步可视化，描述了主要用例并提供了算法变体的链接。我希望它能帮助您了解如何使用 NoSQL 数据存储处理事务。
支持每键线性化和 CAS 的数据存储包括：
顺便说一句，如果您对读提交隔离级别感到满意，那么看看 Peter Bailis 的 RAMP 事务 是有意义的。它们也可以使用同一组原语来实现。
在 RethinkDB 中，您可以保证原子性。根据文档https://rethinkdb.com/docs/architecture/
基于每个文档支持写入原子性 – 更新 单个 JSON 文档保证是原子的。 RethinkDB 是 与其他 NoSQL 系统的不同之处在于原子文档更新 不限于可能操作的一小部分——任何 可以对单个文档执行的操作组合 保证自动更新文档
当您想要运行非原子更新时，您必须明确选择它，根据 https://www.rethinkdb.com/api/javascript/update/
nonAtomic：如果设置为 true，则执行更新并分发 以非原子方式生成副本。该标志是必需的 执行非确定性更新，例如需要读取的更新 来自另一个表的数据。
在此处跟踪 RethinkDB 的某些事务支持时遇到问题：https://github.com/rethinkdb/rethinkdb/issues/4598
不管怎样，你没有很好的交易，但你有一些基本的保证就足够了。并尝试围绕这些基本的事情来设计你的操作。