[Reprint] solutions of distributed transactions (XA and 2PC)

Distributed solutions affairs (XA and 2PC)

3. Distributed 2PC transaction solutions of (two-phase commit)

There 2PC, TCC, reliable sources eventual consistency, best to inform these types of distributed scenarios for different industry common solution.

3.1. What is 2PC

2PC i.e., two-phase commit protocol, the entire transaction is a two-stage process, the preparation phase (Prepare phase), the commit phase (commit phase), 2 is the two-stage, P refers to a preparation stage, C is the commit phase.
For example: Joe Smith and John Doe Long time no see, about an old friend from dinner, the restaurant owner required to pay to the ticket. At this time Joe Smith and John Doe were complaining about the current situation unsatisfactory, cyst shy, are not willing to treat, then only AA. Only Joe Smith and John Doe are payment, ticketing arrangements for the boss to dinner. But because Joe Smith and John Doe are stingy, the formation of two awkward scene:
the preparation phase: the boss Zhang payment requirements, Joe Smith payments. The boss asked John Doe payment, John Doe payment.
Commit phase: the boss ticket, they have to get tickets seated dining.
Forming two examples of a transaction, if Joe Smith or John Doe One refused to pay, or not enough money, the store owner will not give tickets, and would have returned payment.
The entire transaction process by the transaction manager and the composition of the participants, the store owner is a transaction manager, John Doe is the transaction participants, the transaction manager responsible for decision-making throughout the distributed transaction commits and rollbacks, transaction participants responsible for their own local commit and rollback transactions.
Part of a relational database in a computer, such as Oracle, MySQL support two-phase commit protocol, as follows:
1. Prepare phase (Prepare Phase): Prepare transaction manager sends a message to each of the participants, each participant performs the transaction in the local database, and write local Undo / Redo logs, did not submit the transaction at this time.
(Undo log data is recorded before modification, for rollback database, Redo log record data is modified, for writing data file submitted to the Panel)
2. Submit phase (commit phase): If the transaction manager received two participants in the implementation of the failure or timeout message, sent directly rollback (Rollback) message to each participant; otherwise, send submission (Commit) message; participation commit or rollback by the operation, and releases the resource lock transaction process according to an instruction using the transaction manager. Note: You must release the lock resource in the final stage.
The following figure shows two 2PC two stages, two points successes and failures note:
successful cases:


Failures:

 

3.2. Solution

3.2.1 XA program

2PC traditional program is implemented in the database level, such as Oracle, MySQL supports 2PC protocol, in order to reduce unnecessary uniform standards within the industry docking costs, the need to develop a standardized process model and interface standards, Open Group The Open Group defined distribution transaction processing model DTP (Distributed transaction processing Reference model) .
To give you a clearer XA program content, the following integration of new user registration send an example to illustrate:


Execution process is as follows:
1, the application (AP) and integrated user library library holding two data sources.
2, an application (AP) by TM to inform the new user library RM user, notify the library RM integration for users to add points, RM did not commit the transaction at this time, when the user points and resource locking.
3, TM received a reply execute, if one party fails to roll back the transaction were initiated by other RM, rollback is completed, the resource lock is released.
4, TM received a reply to the implementation of all the success, all this time to commit the transaction RM launch, completion of the filing, resource lock is released.
DTP role model is defined as follows:

 

  • AP (Application Program): both applications can be understood as DTP program uses distributed transactions.
  • RM(Resource Manager) : 即资源管理器,可以理解为事务的参与者,一般情况下是指一个数据库实例,通过资源管理器对该数据库进行控制,资源管理器控制着分支事务。
  • TM(Transaction Manager) : 事务管理器,负责协调和管理事务,事务管理器控制着全局事务,管理事务生命周期,并协调各个RM。全局事务是指分布式事务处理环境中,需要操作多个数据库共同完成一个工作,这个工作即是一个全局事务。
  • DTP模型定义TM和RM之间通讯的接口规范叫XA,简单理解为数据库提供的2PC接口协议,基于数据库的XA协议来实现2PC又称为XA方案。
  • 以上三个角色之间的交互方式如下 :
    1)TM向AP提供应用程序编程接口,AP通过TM提交及回滚事务。
    2)TM交易中间件通过XA接口来通知RM数据库事务的开始、结束以及提交、回滚等。
    总结 :
    整个2PC的事务流程涉及到三个角色AP、RM、TM。AP指的是使用2PC分布式事务的应用程序;RM指的是资源管理器,它控制着分支事务;TM指的是事务管理器,它控制着整个全局事务。
    1)在准备阶段RM执行实际的业务操作,但不提交事务,资源锁定;
    2)在提交阶段TM会接收RM在准备阶段的执行回复,只要有任一个RM执行失败,TM会通知所有RM执行回滚操作,否则,TM将会通知所有RM提交该事务。提交阶段结束资源锁释放。
    XA方案的问题 :
    1、需要本地数据库支持XA协议。
    2、资源锁需要等到两个阶段结束才释放,性能较差。

 

3.2.2 Seata方案

Seata是阿里中间件团队发起的开源项目Fescar,后更名Seata,它是一个是开源的分布式事务框架。传统2PC的问题在Seata中得到了解决,它通过对本地关系数据库的分支事务的协调来驱动完成全局事务,是工作在应用层的中间件。主要优点是性能较好,且不长时间占用连接资源,它以高效并且对业务0入侵的方式解决微服务场景下面临的分布式事务问题,它目前提供AT模式(即2PC)及TCC模式的分布式事务解决方案。
Seata的设计思想如下 :
Seata的设计目标其一是对业务无入侵,因此从业务无入侵的2PC方案着手,在传统2PC的基础上演进,并解决2PC方案面临的问题。
Seata把一个分布式事务理解成一个包含来若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致,要么一起成功提交,要么一起失败回滚。此外,通常分支事务本身就是一个关系数据库的本地事务,下图是全局事务与分支事务的关系图 :


与传统2PC的模型类似,Seata定义了三个组件来协议分布式事务的处理过程 :

 

 

  • Transaction Coordinator(TC):事务协调器,它是独立的中间件,需要独立部署运行,它维护全局事务的运行状态,接收TM指令发起全局事务的提交与回滚,负责与RM通信协调各个分支事务的提交或回滚。
  • Transaction Manager(TM):事务管理器,TM需要嵌入应用程序中工作,它负责开启一个全局事务,并最终向TC发起全局提交或全局回滚的指令。
  • Resource Manager(RM):控制分支事务,负责分支注册、状态汇报,并接收事务协调器TC的指令,驱动分支(本地)事务的提交和回滚。
    还拿新用户注册送积分举例Seata的分布式事务过程 :


具体的执行流程如下 :

 

 

  1. 用户服务的TM向TC申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的XID。
  2. 用户服务的RM向TC注册分支事务,该分支事务在用户服务执行新增用户逻辑,并将其纳入XID对应全局事务的管辖。
  3. 用户服务执行分支事务,向用户表插入一条记录。
  4. 逻辑执行到远程调用积分服务时(XID在微服务调用链路的上下文中传播)。积分服务的RM向TC注册分支事务,该分支事务执行增加积分的逻辑,并将其纳入XID对应全局事务的管辖。
  5. 积分服务执行分支事务,向积分记录表插入一条记录,执行完毕后,返回用户服务。
  6. 用户服务分支事务执行完毕。
  7. TM向TC发起针对XID的全局提交或回滚决议。
  8. TC调度XID下管辖的全部分支事务完成提交或回滚请求。

 

Seata实现2PC与传统2PC的差别 :
架构层次方面,传统2PC方案的RM实际上是在数据库层,RM本质上就是数据库自身,通过XA协议实现,而Seata的RM是以jar包的形式作为中间件层部署在应用程序的这一侧的。
两阶段提交方面,传统2PC无论第二阶段的决议是commit还是rollbcak,事务性资源的锁都要保持到Phase2完成才释放。而Seata的做法是在Phase1就将本地事务提交,这样就可以省去Phase2持锁的时间,整体提高效率。

3.3. Seata实现2PC事务

3.3.1. 业务说明

本实例通过Seata中间件实现分布式事务,模拟两个账户的转账交易过程。两个账户在两个不同的银行(张三在bank1、李四在bank2),bank1和bank2是两个微服务。交易过程中,张三给李四转账制定金额。
上述交易步骤,要么一起成功,要么一起失败,必须是一个整体性的事务。

 

3.3.2.程序组成部分

本实例程序组成 部分如下 :
数据库 :MySQL-5.7.25
包括bank1和bank2两个数据库。
JDK:1.8
微服务框架 :spring-boot-2.1.3、spring-cloud-Greenwich.RELEASE
seata客户端(RM、TM):spring-cloud-alibaba-seata-2.1.0RELEASE
seata服务端(TC):seata-server-0.7.1
微服务及数据库的关系 :
dtx/dtx-seata-demo/seata-demo-bank1 银行1,操作张三账户,链接数据库bank1
dtx/dtx-seata-demo/seata-demo-bank2 银行2,操作李四账户,链接数据库bank2
服务注册中兴 :dtx/discover-server
本实例程序技术架构如下 :


交互流程如下 :
1、请求bank1进行转账,传入转账金额。
2、bank1减少转账金额,调用bank2,传入转账金额。

3.3.3.创建数据库

bank1库,包含张三账户

CREATE DATABASE /*!32312 IF NOT EXISTS*/`bank1` /*!40100 DEFAULT CHARACTER SET utf8 */; USE `bank1`; /*Table structure for table `account_info` */ DROP TABLE IF EXISTS `account_info`; CREATE TABLE `account_info` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `account_name` varchar(100) COLLATE utf8_bin DEFAULT NULL COMMENT '户主姓名', `account_no` varchar(100) COLLATE utf8_bin DEFAULT NULL COMMENT '银行卡号', `account_password` varchar(100) COLLATE utf8_bin DEFAULT NULL COMMENT '帐户密码', `account_balance` double DEFAULT NULL COMMENT '帐户余额', PRIMARY KEY (`id`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=DYNAMIC; /*Data for the table `account_info` */ insert into `account_info`(`id`,`account_name`,`account_no`,`account_password`,`account_balance`) values (2,'张三','1',NULL,1000); /*Table structure for table `de_duplication` */ DROP TABLE IF EXISTS `de_duplication`; CREATE TABLE `de_duplication` ( `tx_no` varchar(64) COLLATE utf8_bin NOT NULL, `create_time` datetime DEFAULT NULL, PRIMARY KEY (`tx_no`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=DYNAMIC; /*Data for the table `de_duplication` */ /*Table structure for table `local_cancel_log` */ DROP TABLE IF EXISTS `local_cancel_log`; CREATE TABLE `local_cancel_log` ( `tx_no` varchar(64) NOT NULL COMMENT '事务id', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`tx_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Data for the table `local_cancel_log` */ /*Table structure for table `local_confirm_log` */ DROP TABLE IF EXISTS `local_confirm_log`; CREATE TABLE `local_confirm_log` ( `tx_no` varchar(64) NOT NULL COMMENT '事务id', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`tx_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Data for the table `local_confirm_log` */ /*Table structure for table `local_trade_log` */ DROP TABLE IF EXISTS `local_trade_log`; CREATE TABLE `local_trade_log` ( `tx_no` bigint(20) NOT NULL, `create_time` datetime DEFAULT NULL, PRIMARY KEY (`tx_no`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=DYNAMIC; DROP TABLE IF EXISTS `local_try_log`; CREATE TABLE `local_try_log` ( `tx_no` varchar(64) NOT NULL COMMENT '事务id', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`tx_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Data for the table `local_try_log` */ /*Table structure for table `undo_log` */ DROP TABLE IF EXISTS `undo_log`; CREATE TABLE `undo_log` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `branch_id` bigint(20) NOT NULL, `xid` varchar(100) NOT NULL, `context` varchar(128) NOT NULL, `rollback_info` longblob NOT NULL, `log_status` int(11) NOT NULL, `log_created` datetime NOT NULL, `log_modified` datetime NOT NULL, `ext` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`) ) ENGINE=InnoDB AUTO_INCREMENT=167 DEFAULT CHARSET=utf8; /*Data for the table `undo_log` */ insert into `undo_log`(`id`,`branch_id`,`xid`,`context`,`rollback_info`,`log_status`,`log_created`,`log_modified`,`ext`) values (166,2019228885,'192.168.1.101:8888:2019228047','serializer=jackson','{}',1,'2019-08-11 15:16:43','2019-08-11 15:16:43',NULL);

bank2库,包含李四账户

CREATE DATABASE /*!32312 IF NOT EXISTS*/`bank2` /*!40100 DEFAULT CHARACTER SET utf8 */; USE `bank2`; /*Table structure for table `account_info` */ DROP TABLE IF EXISTS `account_info`; CREATE TABLE `account_info` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `account_name` varchar(100) COLLATE utf8_bin DEFAULT NULL COMMENT '户主姓名', `account_no` varchar(100) COLLATE utf8_bin DEFAULT NULL COMMENT '银行卡号', `account_password` varchar(100) COLLATE utf8_bin DEFAULT NULL COMMENT '帐户密码', `account_balance` double DEFAULT NULL COMMENT '帐户余额', PRIMARY KEY (`id`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=DYNAMIC; /*Data for the table `account_info` */ insert into `account_info`(`id`,`account_name`,`account_no`,`account_password`,`account_balance`) values (3,'李四的账户','2',NULL,0); /*Table structure for table `de_duplication` */ DROP TABLE IF EXISTS `de_duplication`; CREATE TABLE `de_duplication` ( `tx_no` varchar(64) COLLATE utf8_bin NOT NULL, `create_time` datetime DEFAULT NULL, PRIMARY KEY (`tx_no`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=DYNAMIC; /*Data for the table `de_duplication` */ /*Table structure for table `local_cancel_log` */ DROP TABLE IF EXISTS `local_cancel_log`; CREATE TABLE `local_cancel_log` ( `tx_no` varchar(64) NOT NULL COMMENT '事务id', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`tx_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Data for the table `local_cancel_log` */ /*Table structure for table `local_confirm_log` */ DROP TABLE IF EXISTS `local_confirm_log`; CREATE TABLE `local_confirm_log` ( `tx_no` varchar(64) NOT NULL COMMENT '事务id', `create_time` datetime DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Data for the table `local_confirm_log` */ /*Table structure for table `local_trade_log` */ DROP TABLE IF EXISTS `local_trade_log`; CREATE TABLE `local_trade_log` ( `tx_no` bigint(20) NOT NULL, `create_time` datetime DEFAULT NULL, PRIMARY KEY (`tx_no`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=DYNAMIC; DROP TABLE IF EXISTS `local_try_log`; CREATE TABLE `local_try_log` ( `tx_no` varchar(64) NOT NULL COMMENT '事务id', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`tx_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; /*Data for the table `local_try_log` *//*Table structure for table `undo_log` */ DROP TABLE IF EXISTS `undo_log`; CREATE TABLE `undo_log` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `branch_id` bigint(20) NOT NULL, `xid` varchar(100) NOT NULL, `context` varchar(128) NOT NULL, `rollback_info` longblob NOT NULL, `log_status` int(11) NOT NULL, `log_created` datetime NOT NULL, `log_modified` datetime NOT NULL, `ext` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

3.3.4.启动TC(事务协调器)

(1)下载seata服务器
下载地址 :seata服务器
(2)解压并启动
winodws :【seata服务端解压路径】/bin/seata-server.bat -p 8888 -m file
mac/linux : 【seata服务端解压路径】nohup sh seata-server.sh -p 8888 -h 127.0.0.1 -m file &> seata.log &
注 :其中8888为服务端口号;file为启动模式,这里指seata服务将采用文件的方式存储信息。


如上图出现“Server started。。。“的字样则表示启动成功。

3.3.5 discover-server

discover-server是服务注册中心,测试工程将自己注册至discover-server。

3.3.6 创建dtx-seata-demo

dtx-seata-demo是seata的测试工程,根据业务需求需要创建两个dex-seata-demo工程。
(1)父工程maven依赖说明
在dtx父工程中指定了SpringBoot和SpringCloud版本


在dtx-seata-demo父工程中指定了spring-cloud-alibaba-dependencies的版本。


(3)配置seata
在src/main/resource中,新增registry.conf、file.conf文件,内容可拷贝seata-server-0.7.1中的配置文件子。 在registry.conf中registry.type使用file:


在file.conf中更改service.vgroup_mapping.[springcloud服务名]-fescar-service-group = “default”,并修改 service.default.grouplist =[seata服务端地址]


关于vgroup_mapping的配置:
vgroup_mapping.事务分组服务名=Seata Server集群名称(默认名称为default) default.grouplist = Seata Server集群地址
在 org.springframework.cloud:spring-cloud-starter-alibaba-seata 的 org.springframework.cloud.alibaba.seata.GlobalTransactionAutoConfiguration 类中,默认会使用 ${spring.application.name}-fescar-service-group 作为事务分组服务名注册到 Seata Server上,如果和 file.conf 中的配置不一致,会提示 no available server to connect 错误
也可以通过配置 spring.cloud.alibaba.seata.tx-service-group 修改后缀,但是必须和 file.conf 中的配置保持 一致。
(4)创建代理数据源
新增DatabaseConfiguration.java,Seata的RM通过DataSourceProxy才能在业务代码的事务提交时,通过这个切 入点,与TC进行通信交互、记录undo_log等。

@Configuration public class DatabaseConfiguration { @Bean @ConfigurationProperties(prefix = "spring.datasource.ds0") public DruidDataSource ds0() { DruidDataSource druidDataSource = new DruidDataSource(); return druidDataSource; } @Primary @Bean public DataSource dataSource(DruidDataSource ds0) { DataSourceProxy pds0 = new DataSourceProxy(ds0); return pds0; } }

3.3.7 Seata执行流程

1、正常提交流程


2、回滚流程
回滚流程省略前的RM注册过程。


要点说明 :
1、每个RM使用DataSourceProxy连接数据库,其目的是使用ConnectionProxy,使用数据源和数据连接代理的目的就是第一阶段将undo_log和业务数据放在一个本地事务提交,这样就保存了只要有业务操作就一定有undo_log.
2、在第一阶段undo_log中存放了数据修改前和修改后的值,为事务回滚作好准备,所以第一阶段完成就已经将分支事务提交,也就释放了锁资源。
3、TM开启全局事务开始,将XID全局事务id放在事务上下午中,通过feign调用也将XID传入下游分支事务,每个分支事务将自己的Branch ID分支事务ID与XID关联。
4、第二阶段全局事务提交,TC会通知各个分支参与者提交分支事务,在第一阶段就已经提交了分支事务,这里各个参与者只需要删除undo_log即可,并且可以异步执行,第二阶段很快可以完成。
5、第二阶段全局事务回滚,TC会通知各个分支参与者回滚分支事务,通过XID和Branch ID找到相应的回滚日志,通过回滚日志生成反向的SQL并执行,以完成分支事务回滚到之前的状态,如果回滚失败则会重试回滚操作。

3.3.8 dtx-seata-demo-bank1

dtx-seata-demo-bank1实现如下功能:
1、张三账户减少金额,开启全局事务。
2、远程调用bank2向李四转账。
(1)DAO

@Mapper @Component public interface AccountInfoDao { //更新账户金额@Update("update account_info set account_balance = account_balance + #{amount} where account_no = #{accountNo}") int updateAccountBalance(@Param("accountNo") String accountNo, @Param("amount") Double amount); }

(2) FeignClient
远程调用bank2的客户端

@FeignClient(value = "seata‐demo‐bank2",fallback = Bank2ClientFallback.class) public interface Bank2Client { @GetMapping("/bank2/transfer") String transfer(@RequestParam("amount") Double amount); } @Component public class Bank2ClientFallback implements Bank2Client{ @Override public String transfer(Double amount) { return "fallback"; } }

(3)Service

@Service public class AccountInfoServiceImpl implements AccountInfoService { private Logger logger = LoggerFactory.getLogger(AccountInfoServiceImpl.class); @Autowired AccountInfoDao accountInfoDao; @Autowired Bank2Client bank2Client; //张三转账@Override @GlobalTransactional @Transactional public void updateAccountBalance(String accountNo, Double amount) { ("******** Bank1 Service Begin ... xid: {}" , RootContext.getXID()); //张三扣减金额accountInfoDao.updateAccountBalance(accountNo,amount*‐1); //向李四转账 String remoteRst = bank2Client.transfer(amount); //远程调用失败 if(remoteRst.equals("fallback")){ throw new RuntimeException("bank1 下游服务异常"); } //人为制造错误 if(amount==3){throw new RuntimeException("bank1 make exception 3"); } } }

将@GlobalTransactional注解标注在全局事务发起的Service实现方法上,开启全局事务 :
GlobalTransactionalInterceptor会拦截@GlobalTransactional注解的方法,生成全局事务ID(XID),XID会在整个分布式事务中传递。
在远程调用时,spring-cloud-alibaba-seata会拦截Feign调用将XID传递到下游服务。
(6)Controller

@RestController public class Bank1Controller { @Autowired AccountInfoService accountInfoService; //转账 @GetMapping("/transfer") public String transfer(Double amount){ accountInfoService.updateAccountBalance("1",amount); return "bank1"+amount; } }

3.3.9 dtx-seata-demo-bank2

dtx-seata-demo-bank2实现如下功能:
1、李四账户增加金额。
dtx-seata-demo-bank2在本账户事务中作为分支事务不使用@GlobalTransactional。
(1)DAO

@Mapper @Component public interface AccountInfoDao { //向李四转账@Update("UPDATE account_info SET account_balance = account_balance + #{amount} WHERE account_no = #{accountNo}") int updateAccountBalance(@Param("accountNo") String accountNo, @Param("amount") Double amount); }

(2)Service

@Service public class AccountInfoServiceImpl implements AccountInfoService { private Logger logger = LoggerFactory.getLogger(AccountInfoServiceImpl.class); @Autowired AccountInfoDao accountInfoDao; @Override @Transactional public void updateAccountBalance(String accountNo, Double amount) { ("******** Bank2 Service Begin ... xid: {}" , RootContext.getXID()); //李四增加金额accountInfoDao.updateAccountBalance(accountNo,amount); //制造异常 if(amount==2){ throw new RuntimeException("bank1 make exception 2"); } } }

(3)Controller

@RestController public class Bank2Controller { @Autowired AccountInfoService accountInfoService; @GetMapping("/transfer") public String transfer(Double amount){ accountInfoService.updateAccountBalance("2",amount); return "bank2"+amount; } }

3.3.10 测试场景

 

  • 张三向李四转账成功。
  • 李四事务失败,张三事务回滚成功。
  • 张三事务失败,李四事务回滚成功。
  • 分支事务超时测试。

 

3.4. 小结

传统2PC(基于数据库XA协议)和Seata实现2PC的两种2PC方案,由于Seata的零入侵并且解决了传统2PC长期锁资源的问题,所以推荐采用Seata实现2PC。
Seata实现2PC要点 :
1、全局事务开始使用GlobalTransactional标识。
2、每个本地事务方案仍然使用@Transactional标识。
3、每个数据都需要创建undo_log表,此表是Seata保证本地事务一致性的关键。

发布于 2019-11-24

Guess you like

Origin www.cnblogs.com/jinanxiaolaohu/p/12071179.html