因系统各种业务上的拆分，将多个业务服务拆分到了不同的服务器上，形成了微服务。而实际生产环境中，我们总会遇一些需要多个微服务联合提供服务的场景，并需要保证每个微服务都需有事务的四大特性（原子性、一致性、隔离性、持久性）。典型的场景如下单就会牵涉到3个服务（会员服务、订单服务、商品服务）。在下单的同时，我们需要保证订单的成功创建和商品库存的正确减少。
由此，我做了一些资料的准备工作，发现可以使用分布式事务，我比较熟悉的是tcc，但具体tcc的底层实现是如何的，我也不太清楚，但我再mysql的官方文档上找到了这个问题的解决方案。即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