XA Seata TA 是2pc 两阶段提交的具体实现
TCC 是 3pc 三阶段提交的具体实现
一般选用的都是 2阶段提交 锁定资源的方式
2阶段 提交和 3PC 最大的区别就是 是否对 操作的资源是否锁定， 2阶段是会锁定的， 3阶段时不锁定的， 3阶段的时效性和一致性 比二阶段 好些， 但性能就不行了。
电商项目对分布式事务 能避则避的 的态度， 应用分布式事务代价很大， 用了也只是保证最终一致性， 很难做到实时一致性。
一般电商项目都是 采用补偿机制来对数据进行同步。 通常有对账的过程。
分布式事务典型场景
当下互联网发展如火如荼，绝大部分公司都进行了数据库拆分和服务化(SOA)。在这种情况下，完成某一个业务功能可能需要横跨多个服务，操作多个数据库。这就涉及到到了分布式事务，用需要操作的资源位于多个资源服务器上，而应用需要保证对于多个资源服务器的数据的操作，要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。
典型的分布式事务场景：
跨库事务
跨库事务指的是，一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。笔者见过一个相对比较复杂的业务，一个业务中同时操作了9个库。下图演示了一个服务同时操作2个库的情况：
跨库事务
跨库事务指的是，一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。笔者见过一个相对比较复杂的业务，一个业务中同时操作了9个库。下图演示了一个服务同时操作2个库的情况：
对于分库分表的情况，一般开发人员都会使用一些数据库中间件来降低sql操作的复杂性。如，对于sql：insert into user(id,name) values (1,"张三"),(2,"李四")。这条sql是操作单库的语法，单库情况下，可以保证事务的一致性。
但是由于现在进行了分库分表，开发人员希望将1号记录插入分库1，2号记录插入分库2。所以数据库中间件要将其改写为2条sql，分别插入两个不同的分库，此时要保证两个库要不都成功，要不都失败，因此基本上所有的数据库中间件都面临着分布式事务的问题。
X/Open DTP模型与XA规范
X/Open，即现在的open group，是一个独立的组织，主要负责制定各种行业技术标准。 就分布式事务处理(Distributed Transaction Processing,简称DTP)而言，X/Open主要提供了以下参考文档：
DTP 参考模型： <<Distributed Transaction Processing: Reference Model>>
DTP XA规范： << Distributed Transaction Processing: The XA Specification>>
DTP模型
构成DTP模型的5个基本元素：
应用程序(Application Program ，简称AP)：用于定义事务边界(即定义事务的开始和结束)，并且在事务边界内对资源进行操作。
资源管理器(Resource Manager，简称RM)：如数据库、文件系统等，并提供访问资源的方式。
事务管理器(Transaction Manager ，简称TM)：负责分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚等。
通信资源管理器(Communication Resource Manager，简称CRM)：控制一个TM域(TM domain)内或者跨TM域的分布式应用之间的通信。
通信协议(Communication Protocol，简称CP)：提供CRM提供的分布式应用节点之间的底层通信服务。
