mysql XA 分布式事务、TCC事务

mysql XA 分布式事务

因系统各种业务上的拆分，将多个业务服务拆分到了不同的服务器上，形成了微服务。而实际生产环境中，我们总会遇一些需要多个微服务联合提供服务的场景，并需要保证每个微服务都需有事务的四大特性（原子性、一致性、隔离性、持久性）。典型的场景如下单就会牵涉到3个服务（会员服务、订单服务、商品服务）。在下单的同时，我们需要保证订单的成功创建和商品库存的正确减少。

由此，我做了一些资料的准备工作，发现可以使用分布式事务，我比较熟悉的是tcc，但具体tcc的底层实现是如何的，我也不太清楚，但我再mysql的官方文档上找到了这个问题的解决方案。即XA事务。

关于XA事务的介绍详解请点击这里

以下是我做的测试，首先我们通过命令打开两个mysql连接，并做好测试表的准备工作。

如上是我的测试数据。我将用这个数据来测试XA事务。

第一步：client1 创建一个xa事务

xa start "mysql_xa_1";
update users set nickname='tanyong123' where id=1;
update users set versionId = 22 where id=1;
xa end "mysql_xa_1";
xa prepare "mysql_xa_1";

其中mysql_xa_1 是事务id,我们总是要保证事务id的唯一性，不可以重复

发现我这里创建成功了，

第二步：创建client2 效验数据是否已持久化到文件层

检测我刚才执行的sql语句是否已持久化到文件层。
新开一个连接client2

可以发现刚刚xa中执行的事务语句并没有持久化进来。

第三步：效验client2 拿着client1的事务id 能否提交成功

可以发现，提交失败了。那么是否是因为我的client1连接没有关闭（退出），而导致client2无法提交成功呢？基于这个，我又做了一个测试，退出client1的mysql连接。再次让client2执行事务

由图可发现提交成功了，我们创建client3 看下xa事务提交的数据是否持久化到文件层了。

由此可知已持久化到文件层。

总结

基于如上测试，我们可知，当client1创建好xa事务后通过事务id是可以让client2去提交事务的。

基于这个原理，我设计了一个简单的分布式事务模型图

业务方通过restful 或是 rpc 获取到xa事务id，根据其他业务的执行结果判断对这些xa事务执行回滚还是提交。

xa 事务回滚命令

xa rollback "mysql_xa_1" 

mysql_xa_1 为事务id

分布式事务TCC

两个事务的处理主要在于要有一个中间人做协调器，一旦监控到一方失败，那么协调器就会回滚所有任务的事务。后续附上具体的代码实现。如上图所示为我理解的具体原理实行图。