mysql：mysql XA事务的简单例子

# 测试

创建测试表，并写入数据

sql 复制代码

create table cash_account(
    name varchar(10),
    balance decimal(10,2)
) 
engine=innodb;

insert into cash_account values('Tom', 210000);

第一个会话，执行XA事务的业务内容

sql 复制代码

xa start 'transfer_of_account','cash';

update cash_account set 
    balance = balance - 30000 
where name = 'Tom';

xa end 'transfer_of_account','cash';

xa prepare 'transfer_of_account','cash';

第二个会话，通过XA事务id提交XA事务。可以试试在执行【xa commit】之前查询表【cash_account】的数据，看看有没有变化。

sql 复制代码

select * from cash_account;

xa commit 'transfer_of_account','cash';

select * from cash_account;

也可以通过XA事务id回滚XA事务

sql 复制代码

xa rollback 'transfer_of_account','cash';

第三个会话，在XA事务还没有提交之前可以通过【xa recover】查询XA事务的状态

sql 复制代码

xa recover

# 普通事务与XA事务的区别

普通事务
- 通过【begin、rollback、commit】进行控制
- 【begin】必须和【rollback、commit】在同一个会话里面
XA事务
- 可以给【XA事务】起一个名字，如上就是【'transfer_of_account','cash'】
- 通过【xa start、dml、xa end、xa prepare、xa commit、xa rollback】进行控制
- 可以跨会话进行事务的回滚和提交

# XA事务的使用场景

考虑【A服务】顺序调用【B服务、C服务】完成同一个事务的功能。
- 如果我们使用的是普通事务，那么【A】在调用【B】的接口时，【B】一般是执行【begin，dml，commit】然后本地数据库事务就提交了。然后调用【C】的接口时如果失败，【B】的数据已经提交，回滚不了了。
- 如果我们使用的是XA事务，
  - 那么【A】可以在调用【B】的接口时传【XA事务id】，让【B】执行【xa start、dml、xa end、xa prepare】，这样【B】服务在执行完之后返回时是还没有提交的。
  - 然后【A】可以调用【C】的接口，也传【XA事务id（可以是另一个）】，让【C】执行【xa start、dml、xa end、xa prepare】，这样【C】服务在执行完之后返回时是还没有提交的。
  - 等全部的业务操作都做完之后，然后【A】以上面的【XA事务id】为参数再次调用【B、C】的接口执行【xa commit】，提交刚刚的【XA事务】，就达到了强一致性的效果了。
XA事务的缺点
- 阻塞的时候太长。【B】执行完第一次的XA事务之后在还没有执行【xa commit】之前，修改的数据是被锁住的。只有等到【C】也执行完了【XA事务】之后，在【A】发出【xa commit】指令之后数据库才会解锁，整个过程时间太长了。程序没设计好的话不同服务之间死锁的概率很大。不过这种强一致性对金融行业是有好处的