同时可以将事务 4 重构成 PROCEDURE 防止 ORM 可能回滚失败。
0x0011
流量大到数据库扛不住了，加入 MQ 服务：
使用 Redis 抗住流量，使用 MQ 抗住压力，使用 PROCEDURE 降低 IO 。
0x0011看起来像一个可靠的系统了，但是还有一个隐患： uncaughtExceptionError 或者 程序宕掉了，这个会影响 最终一致性 ，导致 Redis 数据与 Database 中的数据在抢购临界结束的时候不一致。
0x0100
增加最终一致性保证。
抢购的栗子有个很特别的地方，就是 total limit ，达到总数上限之后，就只有 MQ 中的部分需要处理了，因此可以很巧妙的利用时间差，即考虑在达到上限之后，取一次数据库快照，延迟一段时间之后，再对比一次数据库，判断是数据不一致还是正常逻辑。
这是一个投机取巧的处理方式，一定程度上可以保证最终一致性。当然，还是人最靠谱了，程序搞不定，人工修复嘛，ORZ~。
终语
分布式事务是一个很大的话题，依据业务量大小可以给出很多实现。
Nodejs 做分布式事务勉勉强强，异步里面的雷很多，不过依赖良好的设计和逻辑一样可以实现。