分布式事务方案—— TCC事务

分布式事务方案—— TCC事务

引用

CSDN

1.

https://blog.csdn.net/m0_63653444/article/details/141304678

什么是 TCC 事务

TCC的作用主要是解决跨服务调用场景下的分布式事务问题，TCC是Try-Confirm-Cancel的简称：

• Try阶段：完成所有业务检查(一致性)，预留业务资源(准隔离性)。所有的资源提供者预留都成功， Try 阶段才算成功。
• Confirm阶段：确认执行业务操作，不做任何业务检查，只使用 Try 阶段预留的业务资源。
• Cancel阶段：取消 Try 阶段预留的业务资源。如果某个业务方的业务资源没有预留成功，则取消所有业务资源预留请求。

TCC事务机制相对于传统XA事务机制，其特征在于它依赖资源管理器对XA的支持，而是通过对(由业务系统提供的)业务逻辑的调度来实现分布式事务。

在阶段一：
XA 事务中，各个资源管理器准备各自事务分支，也就是准备提交资源的更新操作（insert，delete 或 update等），而在 TCC 中，是主业务活动请求 （try） 各个从业务服务预留资源

在阶段二：
XA 根据第一阶段每个资源管理器是否都 prepare 成功，判断是提交还是回滚。
TCC中，如果第一阶段所有业务资源都预留成功，那么 Confirm 各个从业务服务，否则 Cancel 所有从业务服务的资源预留请求；Try 阶段成功后，如果因为网络波动导致各个参与者超时，则需要重试。这就要求 Confirm 操作必须是幂等的。Try 操作主要是为了 保证业务操作的前置条件都得到满足。然后在 Confirm 阶段，因为前置条件都满足了，不断重试直至成功就行了。

但万一 Confirm 重试还是失败了呢？这就会导致数据不一致了，因为有的从业务 Confirm 成功已经执行了资源操作。所以 TCC 模式也不能百分百保证一致性。但 TCC 事务为我们屏蔽了大多数异常导致的数据不一致，一般情况下，进行 Confirm 或 Cancel 操作时产生异常的概率极小极小，我们可以先记录错误日志，后续使用定时任务修复数据或直接人工修复数据所以对于一些强一致性系统，我们还是会使用TCC事务来保证多个服务之间的数据一致性。

TCC事务优缺点

优点：

• 在应用层实现具体逻辑，锁定资源的粒度变小，不会锁定所有资源，提升了系统性能。
• Confirm阶段和Cancel阶段的方法具备幂等性，能够保证分布式事务执行完毕后数据的一致性。
• TCC分布式事务解决方案由主业务发起整个事务，无论是主业务还是分支事务所在的业务，都能部署为集群模式，从而解决了XA规范的单点故障问题。

缺点：

• 代码需要耦合到具体业务中，每个参与分布式事务的业务方法都要拆分成Try、Confirm和Cancel三个阶段的方法，提高了开发成本。