执行两步提交
概述 这部分提供了多记录更新或者多记录事务，使用两步提交来完成多记录写入的模板。另外，可以扩展此方法来提供rollback-like功能。
背景 MongoDB对于单条记录的操作是原子性的；但是涉及多条记录的操作却不是原子性的。由于记录可能是相当复杂，并且有内嵌记录，单记录原子性操作提供了实际中常用的必要支持。
除了单记录的原子性操作，还有许多情况需要多记录操作事务，当执行一个包含一些列操作的事务时，就有以下要求：
原子性：如果一个操作失败，事务中之前的操作需要回滚到之前的状态
一致性：如果一个重大失误，比如网络故障，硬件故障，中断了事务，
数据库必须能够恢复到之前的状态
对于需要多记录操作的事务，可以在应用中实现两步提交的方法，来提供多记录更新支持。使用这种方法保证了一致性，并且万一出现错误，事务的执行状态是可恢复的。然而在这个过程中，记录处于未定的数据和状态。
注意：因为MongoDB只有单记录操作是原子性的，两步提交只能提供语义上的“类事务”功能。对于应用来说，使其能够回到在两步提交中的某个状态的中间数据或者回滚数据。
模板
考虑以下情景：
要将资金从账户A转移到账户B，在关系型数据库中，可以在一个事务中从A中减去资金，同时在B中加上。在MongoDB中，可以模拟两步提交来获得相同结果。 这个例子使用两个集合
1.accounts，用于存储账户信息
2.transactions，用于存储资金转移事务的信息
初始化账户信息 db.accounts.insert(
[
{ _id: "A", balance: 1000, pendingTransactions: [] },
{ _id: "B", balance: 1000, pendingTransactions: [] }
]
);
初始化转账记录 对于每次资金转移操作，将转账信息添加到transactions集合中，插入的记录包含以下信息：
source和destination字段，引用自ccounts集合中的_id字段
value字段，声明转移数值
state字段，表明当前转移状态，值可以是initial,pending, applied, done, canceling, 或者 canceled.
lastModified字段，反应最后修改日期
从A转账100到B，初始化transactions记录：
db.transactions.insert({ _id: 1, source: "A", destination: "B", value: 100, state: "initial", lastModified: new Date() });
使用两步提交进行转账 1.从transactions集合中，找到state为initial的记录。此时transactions集合中只有一条记录，即刚插入的那条。在包含其他记录的集合中，除非你声明了其他查询条件，否则这个查询将返回任何state为initial的记录。
var t = db.transactions.findOne( { state: "initial" } );
在MongoDB的shell中输入t，查看t的内容，类似于：
{ "_id" : 1, "source" : "A", "destination" : "B", "value" : 100, "state" : "initial", "lastModified":??}
2.更新事务状态为pending
设置state为pending，lastModified为当前时间
db.transactions.update(
{ _id: t._id, state: "initial" },
{
$set: { state: "pending" },
$currentDate: { lastModified: true }
}
)
在更新操作中，state:'initial'确保没有其他进程已经更新了这条记录。如果nMatched和nModified是0，回到第一步，获取一个新的事务，重新开始这个过程。
3.在两个账户中应用该事务
使用update方法将事务t应用到两个账户中。在更新条件中，包含条件pendingTransactions:{$ne:t._id},以避免重复应用该事务。
db.accounts.update(
{ _id: t.source, pendingTransactions: { $ne: t._id } },
{ $inc: { balance: -t.value }, $push: { pendingTransactions: t._id } }
)
db.accounts.update(
{ _id: t.destination, pendingTransactions: { $ne: t._id } },
{ $inc: { balance: t.value }, $push: { pendingTransactions: t._id } }
)
从A账号减去t.value，给B账户加上t.value，同时给每个账户的pendingTransactions数组添加事务id
4.更新事务状态为applied
db.transactions.update(
{ _id: t._id, state: "pending" },
{
$set: { state: "applied" },
$currentDate: { lastModified: true }
}
)
5.更新账户pendingTransactions数组
db.accounts.update(
{ _id: t.source, pendingTransactions: t._id },
{ $pull: { pendingTransactions: t._id } }
)
db.accounts.update(
{ _id: t.destination, pendingTransactions: t._id },
{ $pull: { pendingTransactions: t._id } }
)
从两个账户中移除已应用的事务。
6.更新事务状态为done
db.transactions.update(
{ _id: t._id, state: "applied" },
{
$set: { state: "done" },
$currentDate: { lastModified: true }
}
)
从失败场景中恢复数据 事务最重要的不是以上这个例子提供的原型，而是当事务没有完全执行成功的时候，从各种失败场景中恢复数据的可能性。
恢复操作
两步提交模型允许应用程序重新执行事务操作序列，以保证数据一致性。在程序启动时，或者定时执行恢复操作，来抓取任何未完成的事务。
恢复到数据一致的状态的时间取决于应用程序多久需要恢复每个事务。
以下恢复操作使用lastModified日期作为pending状态的事务是否需要回滚的标识符。如果pending或者applied状态的事务在最近的30分钟内没有被更新，说明这些事务需要被恢复。可以使用不同的条件来决定是否需要恢复。
Pending状态的事务 恢复事务状态在pending之后，applied之前
例：
获取三十分钟内未成功的事务记录
var dateThreshold = new Date();
dateThreshold.setMinutes(dateThreshold.get |