redis系列整体栏目
内容 | 链接地址 |
---|---|
【一】分布式事务之2pc两阶段提交 | https://zhenghuisheng.blog.csdn.net/article/details/142406325 |
分布式事务之2pc两阶段提交
一,分布式事务之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;
// 获得资源管理器操作接口实例 RM1
Connection 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();
// 获得资源管理器操作接口实例 RM2
Connection 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生成全局事务id
byte[] gtrid = "g12345".getBytes();
int formatId = 1;
try {
// ==============分别执行RM1和RM2上的事务分支====================
// TM生成rm1上的事务分支id
byte[] 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上的事务分支id
byte[] 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的模式进行网络通信,如上面的订单和库存系统,假设订单的本地事务在预提交阶段给了一个否定消息,那么订单事务和扣减库存事务都得回滚,如果订单事务回滚成功,但是库存事务由于网络原因回滚失败,那么就造成少卖问题,甚至可能会涉及到账户余额等问题。