MongoDB事务

事务问题

数据库支持数据块间的事务是有原因的。典型的场景是应用需要修改几个独立的比特时，如果只有一些而不是全部改变存储到了数据库，那么这就会出现不一致问题。因此ACID的概念是：

• 原子性：所有的改变要么都做了，要么都没做
• 一致性：数据保持一致性状态
• 隔离性：其它用户看不到部分改变
• 持久性：一旦向用户确认了事务，数据就处于安全的状态（通常存在硬盘上）

引入NoSQL数据库后，文档间ACID事务的支持通常就取消了。许多键/值存储仍有ACID，但它只适用于单个条目，取消ACID的主要原因是其可扩展限制。如果文档横跨几个服务器，事务将会很难实施以及性能。假设事务横跨数十个服务器，一些数据库是远程的，一些是不可靠的，想象下这会变的多难，多慢！

在单个文档等级上，MongoDB支持ACID。更准确的说，默认情况下是“ACI”，打开“j”WriteConcern选项后是ACID。Mongo有丰富的查询语言，横跨多个文档，因此人们一直在寻找多文档事务来使用他们的SQL代码。一个常见的办法是利用文档的性质：不需要很多行、很多关系，你可以将所有的东西嵌入到一个大文档中，Denormalization将带你回归事务。

这个技术解决了从一对一关系到一对多关系的很多事务问题。这也可能使应用更简单，数据库更快，所以这是双赢。不过当数据库必须分离时，该怎么办？

减少ACID

其实大部分应用都可以归结为：

• 原子性：实际上你希望所有的改变都完成
• 一致性：系统短时间不一致没关系，只要最终一致就行。
• 隔离性：缺乏隔离性导致暂时的不一致，这并不理想，但是当今线上服务时代，很多用户对此都习惯了（如用户支持：“它要花几秒传输”）。
• 持久性：很重要，要支持。

这样问题就简化为鲁棒性、可扩性、最终一致性。

解决方案1：字段同步

这种解决方案的使用场景最简单，最常见：文档间有些字段需要保持“同步”。例如，你有一个用户名为“John”的用户文档，文档代表John发表过的评论。如果用户可以更换用户名ÿ