分布式事务Seata的常见问题

对Seata的AT模式的理解：

事务之间遵循两个原则：
1.未拿到全局锁时，本地事务不能提交
2.请求获取全局锁超时，本地事务回滚，释放本地锁

例子：
两个全局事务tx1和tx2，分别去更新a表的字段m

1. tx1先获取本地锁，更新了字段m，获取全局锁，释放本地锁
2. tx2拿到了本地锁，更新了字段m，获取全局锁发现被tx1占用，一直等待tx1释放全局锁
3. tx1释放了全局锁，被tx2获取，然后提交了本地事务，释放了本地锁

如果在1发生了全局的回滚，tx1此时没有本地锁，无法回滚，只持有全局锁，他的全局锁不不会释放了。导致tx2等待超时了，开始放弃去获取全局锁，并把自己的本地事务也回滚了，然后释放了本地锁。这样tx1又能获取到本地锁去回滚它的事务。

这是一个抽象出来的典型的分布式事务链路，3 个服务，分别有自己的数据库，服务调用形成一个业务链路，这个链路的数据要保障数据一致性。

调用链路上的 SQL 操作，当前服务调用完成后，直接 提交，释放资源（连接和本地事务的数据锁定）。
业务数据提交的同时，把数据的 回滚日志 一并存放到回滚日志表里，以备全局回滚时使用。

这里面有两个关键：
第一，利用了 数据库本地事务 的特性，让回滚日志和业务数据的写入保证原子性：只要有业务数据提交成功，就一定有相应的回滚日志数据。

第二，考虑到实际业务的运行过程，绝大部分情况下最终是成功全局提交的。直接本地提交的机制，省去了绝大部分情况下，两阶段提交的开销。