事务是恢复和并发控制的基本单位，保证ACID：原子性、一致性、隔离性、持久性。
对于全是异步的 Nodejs 而言， 并不适合做事务操作：
代码书写上：
try ... catch ...是写给人看的，但是属于同步方法，局限性很大。
callback简直是噩梦。
Promise.then(...).catch(...)相对而言好一点。
ES7 的async ... await ...比较清爽，使用 Babel 编译，这是笔者目前找到的最人类的方式，但是和原来的Promise混合使用的时候有时候会出问题，因为编译之后的代码没法看，最后还得重构回Promise。
异步：
异步导致有可能有意料之外的uncaughtExceptionError。
对于 JAVA/C++ 这样语言，出错能直接转到catch中，但是 Node 不是，uncaughtExceptionError将直接导致处理链断掉，你只能通过其他方式保证数据一致性。
虽然 Node 做事务相当非人类，但是考虑开发效率 / 成本，使用 Node 进行开发并不比换语言开差，毕竟事务只有核心业务需要用到。
单点
单机的事务相当容易保证，特别在依赖 MySQL 或者其他关系数据库时。
Nodejs 有 ORM (如Sequelize) 支持事务，也可以直接使用PROCEDURE/FUNCTION。
两者各有优势：
ORM 适合复杂逻辑的事务；
存储过程可以有效减少 IO 次数，防止使用 ORM 时回滚失败。
实际开发过程中可以将两者结合起来一起使用，使用 ORM 完成逻辑，使用存储过程减少 IO 次数。
分布式
对于分布式系统，相信很多人都知道CAP理论，即任何一个分布式系统无法同时满足：
Consistency (一致性)
Availability (可用性)
Partition tolerance (分区容错性)
但是实际上 Consistency 是任何一个系统都不可能放弃的，分布式事务亦是为了保证数据一致性，有时候为了妥协另外两个特性，会放弃强一致性，保证最终一致性。
http://www.developcls.com
http://www.developcls.com/qa/85d4b9a5d70a4a7d8709a95ae56d33b7.html
解决方式
目前业界有很多解决分布式事务的方案，根据对数据一致性的强弱要求，可以选择不同的方案，但是解决思路大致如下：
两阶段提交
如 XA 协议（TM（事务管理器）和RM（资源管理器）之间的接口）。
假设有 A、B、C 三个操作，第一阶段，等待 A B C 均就绪，第二阶段，提交 A B C；如果第一阶段 A 失败了，则第二阶段回滚 B C。
本地事务
使用本地消息表，将远程事务拆分成一个个本地事务，写入本地表中，然后 定时 / 使用 MQ 通知事务方。
两者各有利弊，定时扫描可能大部分时候都在做无用功，而只使用 MQ 可能会有失败 / 多次消费的问题。
使用回滚接口
如 A B 两个接口，串行处理，B 失败了回滚 A ，但是回滚也可能失败，所以也需要使用本地事务表 / MQ。
使用 Node 开发，1 比较重型，不适合；2 和 3 是比较好的选择：
选择一款可靠的 MQ 服务（单次消费 / 失败重试）；
拆分本地事务；
不能拆分的事务，保证回滚。
举个栗子
做一个抢购系统，用户使用虚拟币进行抢购，虚拟币是另外一套系统。为了考虑到公平，每个用户还可能要限制购买上限。
这样用户一次抢购的完整流程如下：
检查购买上限
检查总数
扣除虚拟币
写入数据库
需要事务保证的地方就是 3 和 4，3 是远程事务，4 是本地事务，此栗子中必然是串行操作，3 在前，4 在后。
0x0001
这个时候流量很少，并发不高，将 3 和 4 作为一个事务，保证一起成功，而失败一起回滚。
事务 4 即使使用 ORM 完成，也能完成功能，这个时候系统能很好的工作。
0x0010
流量上升中，抢购的商品变多，并发也变大，这个时候，考虑使用 Redis 来提高性能了（牺牲强一致性）：
将 购买上限 与 总数 写入 Redis，在压力转嫁到数据库之前就挡掉，由于 Redis 的强大性能，可以假设 Redis 等同于内存操作，做好回滚就可以了。
同时可以将事务 4 重构成PROCEDURE防止 ORM 可能回滚失败。
0x0011
流量大到数据库扛不住了，加入 MQ 服务：
使用 Redis 抗住流量，使用 MQ 抗住压力，使用PROCEDURE降低 IO 。
0x0011看起来像一个可靠的系统了，但是还有一个隐患：uncaughtExceptionError或者 程序宕掉了，这个会影响最终一致性，导致 Redis 数据与 Database 中的数据在抢购临界结束的时候不一致。
0x0100
增加最终一致性保证。
抢购的栗子有个很特别的地方，就是total limit，达到总数上限之后，就只有 MQ 中的部分需要处理了，因此可以很巧妙的利用时间差，即考虑在达到上限之后，取一次数据库快照，延迟一段时间之后，再对比一次数据库，判断是数据不一致还是正常逻辑。
这是一个投机取巧的处理方式，一定程度上可以保证最终一致性。当然，还是人最靠谱了，程序搞不定，人工修复嘛，ORZ~。
终语
分布式事务是一个很大的话题，依据业务量大小可以给出很多实现。
Nodejs 做分布式事务勉勉强强，异步里面的雷很多，不过依赖良好的设计和逻辑一样可以实现。
