2.为什么XA大家都不用？
其实也并非不用，例如在IBM大型机上基于CICS很多跨资源是基于XA协议实现的分布式事务，XA也事实上算分布式事务处理的规范了，但在为什么互联网中很少使用，究其原因我觉得有几个：
- 性能（阻塞性协议，增加响应时间、锁时间、死锁）
- 数据库支持完善度（MySQL 5.7之前都有缺陷）
- 协调者依赖独立的J2EE中间件（早期重量级Weblogic、Jboss，后期轻量级Atomikos、Narayana和Bitronix）
- 运维复杂，DBA缺少这方面经验
- 并不是所有资源都支持XA协议。
- 大厂懂所以不使用，小公司不懂所以不敢用
总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。
仔细对比这些方案与XA，会发现这些方案本质上都是将两阶段提交从资源层提升到了应用层。
• Saga的核心就是补偿，一阶段就是服务的正常顺序调用（数据库事务正常提交），如果都执行成功，则第二阶段则什么都不做；但如果其中有执行发生异常，则依次调用其补偿服务（一般多逆序调用未已执行服务的反交易）来保证整个交易的一致性。应用实施成本一般。
• TCC的特点在于业务资源检查与加锁，一阶段进行校验，资源锁定，如果第一阶段都成功，二阶段对锁定资源进行交易逻辑，否则，对锁定资源进行释放。应用实施成本较高。
• 基于可靠消息最终一致，一阶段服务正常调用，同时同事务记录消息表，二阶段则进行消息的投递，消费。应用实施成本较低
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4.1 亮点
相比与其它分布式事务框架，Seata架构的亮点主要有几个:
- 应用层基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性；
- 将分布式事务中TC（事务协调者）独立部署，负责事务的注册、回滚；
- 通过全局锁实现了写隔离与读隔离。
4.2 性能损耗
我们看看Seata增加了哪些开销（存内存运算类的忽略不纯计）：
一条Update的SQL，则需要全局事务xid获取（与TC通讯）、before image（解析SQL，查询一次数据库）、after image（查询一次数据库）、insert undo log（写一次数据库）、before commit（与TC通讯，判断锁冲突），这些操作都需要一次远程通讯RPC，而且是同步的。另外undo log写入时blob字段的插入性能也是不高的。每条写SQL都会增加这么多开销,粗略估计会增加5倍响应时间（二阶段虽然是异步的，但其实也会占用系统资源，网络、线程、数据库）。
4.3 性价比
为了进行自动补偿，需要对所有交易生成前后镜像并持久化，可是在实际业务场景下，这个是成功率有多高，或者说分布式事务失败需要回滚的有多少比率？这个比例在不同场景下是不一样的，考虑到执行事务编排前，很多都会校验业务的正确性，所以发生回滚的概率其实相对较低。按照二八原则预估，即为了20%的交易回滚，需要将80%的成功交易的响应时间增加5倍，这样的代价相比于让应用开发一个补偿交易是否是值得？值得我们深思。
4.4 全局锁
4.4.1 热点数据
Seata在每个分支事务中会携带对应的锁信息，在before commit阶段会依次获取锁(因为需要将所有SQL执行完才能拿到所有锁信息，所以放在commit前判断)。相比XA，Seata 虽然在一阶段成功后会释放数据库锁，但一阶段在commit前全局锁的判定也拉长了对数据锁的占有时间，这个开销比XA的prepare低多少需要根据实际业务场景进行测试。全局锁的引入实现了隔离性，但带来的问题就是阻塞，降低并发性，尤其是热点数据，这个问题会更加严重。
4.4.2 回滚锁释放时间
Seata在回滚时，需要先删除各节点的undo log，然后才能释放TC内存中的锁，所以如果第二阶段是回滚，释放锁的时间会更长。
4.4.3 死锁问题
Seata的引入全局锁会额外增加死锁的风险，具体可见https://github.com/seata/awesome-seata/blob/master/wiki/en-us/Fescar-AT.md，但如果出现死锁，会不断进行重试，最后靠等待全局锁超时，这种方式并不优雅，也延长了对数据库锁的占有时间。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++