分布式事务解决方案：2PC，TCC以及基于消息的最终一致性

各种形态的分布式事务

分布式事务有多种主流形态，包括：

基于消息实现的分布式事务
基于补偿实现的分布式事务
基于TCC实现的分布式事务
基于SAGA实现的分布式事务
基于2PC实现的分布式事务
这些形态的原理已经在很多文章中进行了剖析，用“分布式事务”关键字就能搜到对应的文章，本文不再赘述这些形态的原理，并将重点放在如何根据业务选择对应的分布式事务形态上。
分布式事务解决方案汇总

接下来，以一个典型的分布式事务问题——“转账”为例，详细探讨分布式事务的各种解决方案。

以支付宝为例，要把一笔钱从支付宝的余额转账到余额宝，支付宝的余额在系统A，背后有对应的DB1；余额宝在系统B，背后有对应的DB2；蚂蚁借呗在系统C，背后有对应的DB3，这些系统之间都要支持相关转账。所谓“转账”，就是转出方的系统里面账号要扣钱，转入方的系统里面账号要加钱，如何保证两个操作在两个系统中同时成功呢？

2PC

（1）2PC理论。在讲MySQL Binlog和Redo Log的一致性问题时，已经用到了2PC。当然，那个场景只是内部的分布式事务问题，只涉及单机的两个日志文件之间的数据一致性；2PC是应用在两个数据库或两个系统之间。

2PC有两个角色：事务协调者和事务参与者。具体到数据库的实现来说，每一个数据库就是一个参与者，调用方也就是协调者。2PC是指事务的提交分为两个阶段，如图10-1所示。

阶段1：准备阶段。协调者向各个参与者发起询问，说要执行一个事务，各参与者可能回复YES、NO或超时。

阶段2：提交阶段。如果所有参与者都回复的是YES，则事务协调者向所有参与者发起事务提交操作，即Commit操作，所有参与者各自执行事务，然后发送ACK。

如果有一个参与者回复的是NO，或者超时了，则事务协调者向所有参与者发起事务回滚操作，所有参与者各自回滚事务，然后发送ACK，如图10-2所示。

图10-1 2PC事务提交示意图

图10-2 事务回滚示意图

所以，无论事务提交，还是事务回滚，都是两个阶段。

（2）2PC的实现。通过分析可以发现，要实现2PC，所有参与者都要实现三个接口：Prepare、Commit、Rollback，这也就是XA协议，在Java中对应的接口是javax.transaction.xa.XAResource，通常的数据库也都实现了这个协议。开源的Atomikos也基于该协议提供了2