由 dawei 首先我们应该从AT去做判断，为什么Seata有了AT模式还去做XA的支持
从视角出发：首先，我们来总结下AT模式，首先所有的事物发起，都是从TM(不仅AT) 且数据的读已提交只能在应用中见效(用户自行开发的系统)，对资源的查看，无法做到全方面 而XA可让资源也感知到自身已处于全局事务中，对资源的隔离性可由数据库本身来实现，满足 全局一致性
从入侵性，数据库支持角度：业务无入侵的更彻底，少于2个服务的操作，仅使用本地事务即可满足一致性，而AT需要 全局锁来保证隔离性，所以无论是1个服务，单库的操作，还是n个服务都需要开启全局事务来保证 隔离性。对数据库的支持，如果AT需要支持mysql，pgsql，oracle以外的数据库，需要做适配，并且 对复杂sql的解析成本更大，开发效率低，支持的sql数量少，XA可全方位支持数据库的sql语句 多语言支持，如果你有java应用已经使用了seata xa那么本地数据库已经帮我们保证了隔离 性，即便其余seata不支持的语言和java并行处理下，数据也不会出现不一致的情况。
数据锁定：在整个事务处理过程结束前，涉及数据都被锁定，读写都按隔离级别的定义约束起来。
AT 模式使用 全局锁 保障基本的 写隔离，实际上也是锁定数据的，只不过锁在 TC 侧集中管理 解锁效率高且没有阻塞的问题，且XA本地数据库可能持有间隙锁，造成锁的粒度更大，锁定更多无辜数据
死锁(协议阻塞)：XA prepare 后，分支事务进入阻塞阶段，收到 XA commit 或 XA rollback 前必须阻塞等待。如果没有一个靠谱的协调者存在，比如abc三个库的数据被二阶段决议为提交，此时ab收到的指令，提交后，c库在收到指令后挂了，并没有提交xa事务，或者协调者没有做到二阶段重试，那么这个没有提交的xa事务将会一直 持有锁，造成死锁的局面
性能差：性能的损耗主要来自两个方面：一方面，事务协调过程，增加单个事务的 RT;另一方面，并发事务数 据的锁冲突，降低吞吐。其实主要原因就是上面的阻塞跟数据锁定造成，因为xa的一阶段并非提交，如果一阶段都是提交的场景下，由于At模式的一阶段提交，at的性能是优于xa，因为它锁在tc一侧集中释放，无需多个库进行本地的锁释放