分布式事务又分为强事务和柔性事务（最终一致性）
- 强事务：基于XA实现，如2PC，3PC
- 柔性事务：TCC，最大努力通知（如消息队列的本地事务消息表）
# 一、两阶段提交（2PC）
- prepare阶段：锁定资源（执行本地数据脚本但不提交事务）
- commit阶段：提交资源（根据第一阶段的返回结果，确定rollback还是commit）
缺点：
- 性能（同步阻塞）：发送prepare后，如果部分参与者断开连接，会导致其他参与者的资源处于被动阻塞状态。
- 数据一致性（网络抖动）：发送commit后，如果出现网络抖动，导致部分服务未接收到commit，则整个分布式系统会出现数据不一致的情况。
- 可靠性（单点故障）：发送prepare后，如果协调者宕机并重新选举，选举后的协调者无法解决上个事务问题，导致参与者资源一直阻塞。
# 二、三阶段提交（3PC）
3PC本质上是对2PC的优化，加入了一个precommit阶段，同时引入了超时机制，当参与者各种原因未收到协调者的commit请求后，会对本地事务进行commit，不会一直阻塞等待，解决了2PC的单点故障问题，通过ack超时重试机制，保证commit最终被提交，确实数据的一致性。
- CanCommit：保证网络正常，确保资源满足要求。
- PreCommit：执行数据库脚本，锁定资源，不提交事务。如果在锁定资源后等待DoCommit超时，则自动提交（根据概率计算而来），防止资源被无限锁定。
- DoCommit：根据PreCommit的结果，确定是commit还是rollback。
缺点：
- 增加一个步骤，参与者和协调者通信次数增加。增加了系统的复杂度。
优点：
- 增加询问功能【减缓阻塞】，在锁定资源前发现问题，减少阻塞时间。
- 自动提交功能【解决数据一致性问题】，在等待DoCommit超时后，自动提交事务（根据概率计算得来），防止资源被无限阻塞。
# 三、补偿事务(TCC)
【柔性事务】
TCC的实现逻辑跟2PC类似，只不过2PC应用于DB层，TCC则可以理解为在应用层的2PC，是需要我们编写业务逻辑来实现的方式。
TCC的数据一致性上是最终一致性，因为其会预扣资源并提供补偿机制，即使事务最终执行失败，在这个过程中，其他事务看到的数据库都是被扣除后的数据。
- Try：完成业务检查，预留业务所需的资源。Try是整个TCC的精髓，可以灵活选择业务资源锁的粒度。
- Confirm：执行业务逻辑，直接使用Try操作预留的业务资源，无需再次检查。
- Cancel：释放Try阶段预留的业务资源。
缺点：
- 业务侵入性强，需要实现Try、Confirm、Cancel接口，并在业务初始化阶段将这三个接口的实现注入TCC事务管理器。
优点：
- 可以在Try阶段控制锁的粒度，只预留资源，而不是真正的操作。比如用XA，则在事物执行期间，相关数据会在数据库层面被锁定，导致其他事物无法操作。而TCC则不会，他在页面层面加锁，先预扣相关资源（Try），并提供错误补偿机制（Cancel），即使该TCC还在执行，也不阻塞其他TCC操作。
参考：
← 分布式一致性算法 分布式理论（BASE） →