TCC和XA的区别和概述
TCC
主要限制
对业务有侵入性，需要提供了三个接口。
主业务服务和从业务服务都需要进行改造，从业务方改造成本更高。如果从业务方还不是自己的公司的话那更是成本提高了（可能人家都不搭理你），原来只需要提供一个接口，现在需要改造成try、confirm、canel3个接口，开发成本高。
使用范围（业务层面的控制）
分布式架构，TCC是分布式事务，是最终一致性的，不会长期持有所有数据库资源的锁，原理上还是提交本地事务，所以不会存在长事务，这样就和本地事事务没有区别，性能很好。
第一阶段由发起方（发起所在的程序）发出try请求，第二阶段由事务管理器发起confirm／cancel请求，而且采用了异步实现。
概述和原理
原来一个接口就可以，现在要提供三个接口
try 数据就生效了，提交了事务
confirm 确定下数据，查询try的数据是否正确
cancle 回滚数据，把try的数据回滚掉
XA（很少使用了）
主要限制
必须要拿到所有数据源，而且数据源还要支持XA协议。
性能比较差，要把所有涉及到的数据都要锁定，是强一致性的，会产生长事务。
使用范围（资源管理方面的控制）
适用于单体架构
概述和与原理
XA协议是由X/Open组织提出的一个分布式事务处理规范，目前MySQL中只有InnoDB存储引擎支持XA协议。
其中有几个概念：
AP 代表我们的应用程序，参与事务发起和结束。
RM 代表资源管理器，主要负责管理每个数据库的连接数据源
TM 代表事务管理器，负责事务的全局管理，包括事务的生命周期管理和资源的分配协调等。
下面是2pc提交的的大概流程
两者的区别
XA是把所有数据执行成功的通知发送给协调器（第一阶段），协调器在执行commit（第二阶段）
TCC是第一阶段就把事务commit了（try接口），TCC的第二阶段是一个确认（Confirm）的阶段，也就是说只需要调用各个子系统里的confirm逻辑，所以在执行confirm逻辑的时候，并不会持有数据库的锁，所以不会产生性能问题。
来源：CSDN
作者：升起的日落
链接：https://blog.csdn.net/weixin_40462208/article/details/103754609