不久之前团队有个新人问我一个很重要的web服务接口如何保证事务的问题。因为涉及到跨库事务，当时我只是回答目前我们的SOA框架都不支持跨库事务。然后就问到了数据库跨库事务是如何实现的，我只能凭印象含糊回答多数是基于数据库日志（后来知道就是所谓的预写日志Write-Ahead Logging），具体数据库内部如何控制数据一致性则真的说不清楚。后来一起查了一下事务的资料，原来DB的事务控制除了基于预写日志还要实现两阶段提交协议（2PC），摘抄两段加深印象。
一、2PC的两个阶段
1、准备阶段（Prepare Phase）
When the transaction manager receives a commit request, it sends a prepare command to all of the resource managers involved in the transaction. Each resource manager then does everything required to make the transaction durable, and all buffers holding log images for the transaction are flushed to disk. As each resource manager completes the prepare phase, it returns success or failure of the prepare to the transaction manager.
2、提交阶段（Commit Phase）
If the transaction manager receives successful prepares from all of the resource managers, it sends commit commands to each resource manager. The resource managers can then complete the commit. If all of the resource managers report a successful commit, the transaction manager then sends a success notification to the application. If any resource manager reported a failure to prepare, the transaction manager sends a rollback
二、2PC的原理示例
如何理解2PC实现分布式事务的呢？下面举例说明下。
假设有A、B、C三个数据库，A作为一个事务发起者，称为“主库”，B和C则称为”从库”。假设需要执行一个在A、B和C三个库的某个表中插入一行数据的事务。
准备阶段（Prepare Phase），A锁定表，并将事务写入自己的预写日志；A将事务发给从库B和C，B和C也各自锁定自己的表，并把事务写入预写日志，完成后返回告诉A准备阶段完成；
提交阶段（Commit Phase），A开始执行自己的事务，并通知B和C提交事务。如果在这个过程中没有任何错误，那么操作将在A、B和C库中完成；如果发生错误，比如从库C超时无响应，或者从库C磁盘空间不足…A将通知所有参与事务的B和C回滚该事务，并且回滚A自己的事务。
顺便重点再提一下预写日志，因为数据库的这种日志无比重要，普通的增删改查、数据还原、单库事务以及本文的分布式事务都离不开它，没有它绝大多数主流数据库的数据一致性根本无法实现。
到这里大家应该已经看到，相比单库事务，分布式事务控制更加复杂，而且开销极大。虽然一些高级开发框架如.net framework提供了较为强大丰富的类库如TransactionScope来简化开发分布式事务，但是建议能不用则不用，因为它被反映普遍存在性能问题和无意识的死锁问题。这种分布式事务的场景如果频繁出现，重新拆分系统合理规划架构才是正道。
总结：在大型web应用中如何保持事务这个话题被问得非常多，个人已经是不止一次被问到所维护的站点是如何实现事务的。在分布式多集群环境下，业务逻辑错综复杂，保证数据库完全可靠存储当然并不容易。但是web应用程序的一个典型特点是读多写少，牺牲极少的数据一致性获得系统的高可扩展性可维护性以及高性能，那么一点点的数据不准确在业务上完全可以容忍，何况我们有日志，后续还有很多补偿措施，甚至直接人工介入处理也未尝不可。
