关于TCC的理论部分请参考：分布式事务基础理论——TCC

概述

目前市面上的TCC框架众多（都是国内的呢）：

Hmily

Hmily是dromara团队设计开发的金融级柔性分布式事务解决方案。

功能

• 高可靠性 ：支持分布式场景下，事务异常回滚，超时异常恢复，防止事务悬挂

• 易用性 ：提供零侵入性式的 Spring-Boot, Spring-Namespace 快速与业务系统集成

• 高性能 ：去中心化设计，与业务系统完全融合，天然支持集群部署

• 可观测性 ：Metrics多项指标性能监控，以及admin管理后台UI展示

• 多种RPC ： 支持 Dubbo, SpringCloud,Motan, Sofa-rpc, brpc, tars 等知名RPC框架

• 日志存储 ： 支持 mysql, oracle, mongodb, redis, zookeeper 等方式

• 复杂场景 ： 支持RPC嵌套调用事务

支持范围

• 必须使用 JDK8+

• TCC模式下，用户必须要使用一款 RPC 框架, 比如 : Dubbo, SpringCloud,Montan

• TAC模式下，用户必须使用关系型数据库, 比如：mysql, oracle, sqlsever

TCC中的特别处理

空回滚

在没有调用TCC中Try方法的情况下，调用了第二阶段的Cancel方法，Cancel方法需要直接识别出来这是一次空回滚，直接返回成功结果。

出现原因：分支事务所在系统服务宕机或者网络波段，分支事务的调用记录是失败的，该情况下其实分支事务没有进行Try操作，当故障恢复后，分布式事务进行了回滚则会调用二阶段的Cancel方法，既而形成了空回滚。

解决方法：已知全局事务id会贯穿整个全局分布式事务的调用链，额外增加一张分支事务记录表，其中有全局事务id和分支事务id，每一次成功的Try执行后插入一条分支事务执行记录，第二阶段Cancel执行时读取该表记录，如果该分支事务对应的执行记录存在，就回滚，如果不存在就认为是空回滚，直接返回成功。

幂等性

为了保证第二阶段中出现的失败情况，Hmily会有重试机制，此时就会出现幂等性问题。如果Cancel执行过程中没有保证好幂等性问题，会导致数据污染。

悬挂

悬挂就是Cancel先于Try执行了。

出现原因：当全局事务发起者通过RPC方式调用分支分支事务执行Try的时候，出现了调用网络延迟的问题，此时TM会认为RPC调用超时需要回滚，但是可能这次RPC的Try请求在回滚之后执行成功了。此次Try操作预留的资源只有该分布式事务可以使用，该次预留的资源无法进行后续的处理，这就是选个挂。

解决思路：在执行第一阶段Try操作之前，要在事务记录表中是否有该分支事务对应的二阶段事务，如果有记录就不执行Try。

总结

• 在TCC模式下，所有操作要保证幂等性
• 需要有事务的执行记录
• 执行Try和Cancel时候都需要进行操作记录判断

今天的文章分布式事务TCC方案——Hmily金融级柔性分布式事务解决方案介绍分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。