【分布式事务-01】分布式事务之2pc两阶段提交

redis系列整体栏目

---

内容	链接地址
【一】分布式事务之2pc两阶段提交	https://zhenghuisheng.blog.csdn.net/article/details/142406325

---

一，分布式事务之2pc两阶段提交

在了解分布式事务之前，需要先了解什么事本地事务，本地事务指的是在单jvm进程下，不涉及到分布式场景下的事务。而在分布式场景下，如微服务架构，分库分表这些情况下，那么在一个方法中，就可能操作多个数据库，那么本地事务是不能解决多个事务的提交以及回滚的，因此就引入了分布式事务。

1，两阶段提交(2pc)

在解决分布式事务之前，先了解一下什么是两阶段提交。假设有一个场景：就是一个下单和扣减库存的场景，假设有两个库，一个是order订单表，一个是stock库存表 ，现在在分布式场景中，为了保证事务的原子性，要么同时成功，要么同时失败。

那么如果是让我们自定义区实现一个解决这种分布式方案的话，那么其实也很简单，其大概实现思路如下，首先拿到两个事务的预提交的状态，然后同时判断本地事务状态是否执行成功，执行成功则提交事务，有一个不成功则同时回滚事务

//订单创建和更新库存预提交
int orderStatus = order.prepare();
int stockStatus = stock.prepare();
//判断二者之间的状态是否都为1
if(orderStatus && stockStatus){//同时提交order.commit();stock.commit();
}else{//同时回滚order.rollback();stock.rollback();
}

其两阶段提交的本质也很好理解，就是分为两个阶段，一个是准备阶段，协调者会去每个本地事务拿到每个预提交的返回值，然后根据返回值进行判断是否都为ok，当都为ok时则执行commit操作，否则执行rollback操作

2，2pc两阶段提交实现思路

在介绍两阶段提交之前，需要先知道内部的一些名词

• Coordinator ：协调者，又被称为事务管理器，用于对所有本地事务进行收集，并用于控制所有本地事务进行准备操作、提交事务和回滚事务
• Participants：参与者，又被称为资源管理器，用于管理所有的本地事务

在了解完本地名词之后，再来查看2pc的两阶段操作是如何执行的

• 首先第一阶段就是协调者去通知各个参与者进行事务的预提交，参与者在接收到指令后开始预提交，随后向协调者发送应答，如果可以提交则返回ok肯定答复，如果出现其他情况则返回error否定答复
• 第二阶段就是在协调者接收到全部的参与者的答复之后，根据返回的应答消息进行判断，如果返回的消息都是肯定的答复ok，那么就执行commit提交的操作，这样所有参与者的事务全部同时进行提交；如果返回的应答消息有一个给了否定，那么协调者则发起rollback回滚的操作，这样所有的参与者都得回滚

两阶段提交完全依赖与参与者的本地事务的acid，通过每个参与者的事务，从而保证所有事务的执行

3，代码模拟两阶段提交

接下来通过一段代码来模拟两阶段提交，先获取订单表的连接，然后获取XAResource资源实例，并且设置对应的事务id，让资源管理器绑定事务管理器，然后执行预提交操作，最后收集两个与提交的结果，通过判断结果的value值，在如果都是肯定答复的话，那么二者都执行commit提交操作，否则执行rollback回滚操作

public static void main(String[] args) throws SQLException {//true表示打印XA语句,，用于调试boolean logXaCommands = true;// 获得资源管理器操作接口实例 RM1Connection conn1 = DriverManager.getConnection("jdbc:mysql://localhost:3306/db_order", "root", "root");XAConnection xaConn1 = new MysqlXAConnection((com.mysql.jdbc.Connection) conn1, logXaCommands);XAResource rm1 = xaConn1.getXAResource();// 获得资源管理器操作接口实例 RM2Connection conn2 = DriverManager.getConnection("jdbc:mysql://localhost:3306/db_storage", "root", "root");XAConnection xaConn2 = new MysqlXAConnection((com.mysql.jdbc.Connection) conn2, logXaCommands);XAResource rm2 = xaConn2.getXAResource();// AP请求TM执行一个分布式事务，TM生成全局事务idbyte[] gtrid = "g12345".getBytes();int formatId = 1;try {// ==============分别执行RM1和RM2上的事务分支====================// TM生成rm1上的事务分支idbyte[] bqual1 = "b00001".getBytes();Xid xid1 = new MysqlXid(gtrid, bqual1, formatId);// 执行rm1上的事务分支rm1.start(xid1, XAResource.TMNOFLAGS);//One of TMNOFLAGS, TMJOIN, or TMRESUME.PreparedStatement ps1 = conn1.prepareStatement("INSERT into order_tbl(user_id,commodity_code,count,money,status) VALUES (1001,2001,2,10,1)");ps1.execute();rm1.end(xid1, XAResource.TMSUCCESS);// TM生成rm2上的事务分支idbyte[] bqual2 = "b00002".getBytes();Xid xid2 = new MysqlXid(gtrid, bqual2, formatId);// 执行rm2上的事务分支rm2.start(xid2, XAResource.TMNOFLAGS);PreparedStatement ps2 = conn2.prepareStatement("update stock_tbl set count=count-2 where commodity_code=2001");ps2.execute();rm2.end(xid2, XAResource.TMSUCCESS);// ===================两阶段提交================================// phase1：询问所有的RM 准备提交事务分支int rm1_prepare = rm1.prepare(xid1);int rm2_prepare = rm2.prepare(xid2);// phase2：提交所有事务分支boolean onePhase = false;//TM判断有2个事务分支，所以不能优化为一阶段提交if (rm1_prepare == XAResource.XA_OK&& rm2_prepare == XAResource.XA_OK) {//所有事务分支都prepare成功，提交所有事务分支rm1.commit(xid1, onePhase);rm2.commit(xid2, onePhase);} else {//如果有事务分支没有成功，则回滚rm1.rollback(xid1);rm2.rollback(xid2);}} catch (XAException e) {// 如果出现异常，也要进行回滚e.printStackTrace();}}

4，两阶段提交的缺陷

虽说两阶段提交确实可以实现分布式事务，但是两阶段提交也存在着一定的缺陷。

事务管理器高可用：首先是事务管理器收集信息的问题，在收集时如何保证高可用问题，比如可以通过redis或者mysql将数据收集，然后再发出相关的指令，但是如果此时宕机要如何保证，因此可以做一些集群等，从而解决事务管理器的单点故障问题，不会让整个系统卡死

同步阻塞问题：由于第一阶段和第二阶段时一个完整的事务，因此只有第二阶段执行完第一段才能释放接连，如果出现延迟情况，那么就可能造成连接延迟阻塞等问题，如果大量的连接进来，那么就可能在成整个系统阻塞

提交/回滚不一致问题：由于在整个系统都是使用RPC的模式进行网络通信，如上面的订单和库存系统，假设订单的本地事务在预提交阶段给了一个否定消息，那么订单事务和扣减库存事务都得回滚，如果订单事务回滚成功，但是库存事务由于网络原因回滚失败，那么就造成少卖问题，甚至可能会涉及到账户余额等问题。