概念对齐
- 刚性事务：遵循ACID原则，强一致性。
- 柔性事务：遵循BASE理论，最终一致性；与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。
XA
优点
基于XA协议实现的分布式事务对业务的侵入性很弱。它最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于XA协议的分布式事务。XA协议能够严格保障事务的ACID特性。
缺点
在高并发性能至上的场景中，基于XA协议的分布式事务并不是最佳选择
TCC
TCC是Try、Confirm、Cancel三个词语的缩写，他是一种面向应用层的原子性提交协议
- Try：完成业务检查，预留业务所需的资源。Try操作是整个TCC的精髓，可以灵活选择业务资源锁的粒度。
- Confirm：执行业务逻辑，直接使用Try阶段预留的业务资源，无须再次进行业务检查。
- Cancel：释放Try阶段预留的业务资源。
优点
- 事务的隔离交给业务实现，释放底层数据库锁资源
缺点
- 在业务上侵入性更大，需要实现try、confirm、cancel三个接口；
Saga
实现方案
注解+拦截器
事件驱动架构
优点
- 适用于事件驱动异步执行，吞吐量更高
- 一阶段提交本地事务，无锁，高性能
- 补偿事务易于实现
缺点
- 有数据隔离性问题，可能产生脏数据、更新丢失、模糊读取等问题；
应用场景
- Saga是一种**「长事务的解决方案」，更适合于「业务流程长、业务流程多」**的场景；
- 如果服务参与者包含其他公司或遗留系统服务，此时无法提供TCC模式下的三个接口，那么就需要采用Saga；
- 典型的业务系统：金融机构对接系统（需要对接外部系统）、渠道整合（流程长）、分布式架构服务；
- 银行金融机构使用更为广泛；
二阶段提交（2PC）
他是一种面向资源(数据库)层的提交协议。 整个事务过程由事务管理器和参与者组成，事务管理器负责决策整个分布式事务的提交和回滚，事务参与者负责自己本地事务的提交和回滚
- 准备阶段（Prepare phase）**：**事务管理器给每个参与者 Prepare 消息，每个数据库参与者在本地执行事务，并写本地的 Undo/Redo 日志，此时事务没有提交。（Undo 日志是记录修改的数据，用于数据回滚，Redo 日志是记录修改后的数据，用于提交事务后写入数据文件）
- 提交阶段（Commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息，直接给每个参与者发送回滚（Rollback）消息；否则，发送提交（Commit）消息；参与者根据事务管理器的执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意：必须在最后阶段释放资源。
问题
同步阻塞
执行过程中，数据库要锁定对应的数据行。如果其他事务刚好也要操作这些数据行，那它们就只能等待。其实同步阻塞只是设计方式，真正的问题在于这种设计会导致分布式事务出现高延迟和性能的显著下降。
单点故障
事务管理器非常重要，一旦发生故障，数据库会一直阻塞下去。尤其是在第二阶段发生故障的话，所有数据库还都处于锁定事务资源的状态中，从而无法继续完成事务操作。
数据不一致
在第二阶段，当事务管理器向参与者发送 Commit 请求之后，发生了局部网络异常，导致只有部分数据库接收到请求，但是其他数据库未接到请求所以无法提交事务，整个系统就会出现数据不一致性的现象。比如，小明的余额已经能够扣减，但是小红的余额没有增加，这样就不符合原子性的要求了。
参考
https://zhuanlan.zhihu.com/p/142136446 https://seata.io/zh-cn/blog/seata-at-tcc-saga.html