分布式事务解决方案

分布式事务产生的背景

1. 跨库事务：一个本地事务，涉及多个库实例的处理
2. 分库分表：分库之后，导致一个SQL被映射到多个库去执行
3. 微服务化：一个本地事务，设计到多个跨服务的RPC调用

目前分布式事务的方案都不能百分百解决分布式事务的问题，只是围绕怎么让分布式事务成功率更高来设计方案，每种方案都会有解决不了的问题存在，所以分布式事务不像数据库事务那样，要么commit，要么rollback，各种方案能最大可能的保证每个分支都commit或者rollback，当不能百分百保证所有分支事务都必须commit/rollback，所以会存在某些分支事务commit，某些分支事务rollback这种中间状态。当如果分布式应用能保证全年可用性达到99.99%，也是非常好的

一、DTP事务模型

X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由厂商进行具体的实现。有以下三个角色组成：

AP：Application，我们的应用程序
RM：Resource Manager，资源管理器，可以把它理解为应用程序借用RM对数据库资源的控制管理，资源必须实现XA定义接口
TM：Transaction Manger，事务管理器，负责生成事务唯一标识，监控事务的执行进度，完成事务的最终提交/回滚。

DTP就是一个分布式事务规范，那么实现这套规范，需要自己去实现两个协议，一个是TX协议：APP调用TM接口来开启/控制事务，一个是XA协议：TM调用RM的提交/回滚接口，来控制事务。

那么接下来将讨论以下几种分布式解决方案：2PC、TCC

二、2PC两阶段提交

prepare -> commit ，每个分支事务做完prepare（商品预扣）之后，最后由事务管理器一起commit/rollback，如果某个分支事务prepare失败，则rollback，如果commit/rollback失败，那么就会引发事务的失败，**但相比于两个分支事务独立提交(不做分布式事务处理)，2PC有统一prepare的阶段，大大降低了某个事务commit/rollback的失败概率。**但是也引发了新的问题，两个分支事务prepare的时间会增加，也就增加了对资源锁定（商品预扣）时间，降低了并发度。那么我们可以看出，2PC是强一致性的。

MySql jdbc已经实现了XA规范，所以用jdbc就可以实现2PC：

import com.mysql.jdbc.jdbc2.optional.MysqlXAConnection;
import com.mysql.jdbc.jdbc2.optional.MysqlXid;
import javax.sql.XAConnection;
import javax.transaction.xa.XAException;
import javax.transaction.xa.XAResource;
import javax.transaction.xa.Xid;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.SQLException;
public class MysqlXAConnectionTest {