分布式事务之TCC服务设计和实现注意事项

摘要： 一、TCC简介 TCC是一种比较成熟的分布式事务解决方案，可用于解决跨库操做的数据一致性问题； TCC是服务化的两阶段编程模型，其Try、Confirm、Cancel 3个方法均由业务编码实现； 其中Try操做做为一阶段，负责资源的检查和预留，Confirm操做做为二阶段提交操做，执行真正的业务，...

一、TCC简介

TCC是一种比较成熟的分布式事务解决方案，可用于解决跨库操做的数据一致性问题；

TCC是服务化的两阶段编程模型，其Try、Confirm、Cancel 3个方法均由业务编码实现；

其中Try操做做为一阶段，负责资源的检查和预留，Confirm操做做为二阶段提交操做，执行真正的业务，Cancel是预留资源的取消；

以下图所示，业务实现TCC服务以后，该TCC服务将做为分布式事务的其中一个资源，参与到整个分布式事务中；事务管理器分2阶段协调TCC服务，在第一阶段调用全部TCC服务的Try方法，在第二阶段执行全部TCC服务的Confirm或者Cancel方法；

二、用户在实现TCC服务时，有如下注意事项

一、业务操做分两阶段完成：
以下图所示，接入TCC前，业务操做只须要一步就能完成，可是在接入TCC以后，须要考虑如何将其分红2阶段完成，把资源的检查和预留放在一阶段的Try操做中进行，把真正的业务操做的执行放在二阶段的Confirm操做中进行；

TCC服务要保证第一阶段Try操做成功以后，二阶段Confirm操做必定能成功；

二、容许空回滚；

以下图所示，事务协调器在调用TCC服务的一阶段Try操做时，可能会出现由于丢包而致使的网络超时，此时事务协调器会触发二阶段回滚，调用TCC服务的Cancel操做；

TCC服务在未收到Try请求的状况下收到Cancel请求，这种场景被称为空回滚；TCC服务在实现时应当容许空回滚的执行；

三、防悬挂控制；

以下图所示，事务协调器在调用TCC服务的一阶段Try操做时，可能会出现因网络拥堵而致使的超时，此时事务协调器会触发二阶段回滚，调用TCC服务的Cancel操做；在此以后，拥堵在网络上的一阶段Try数据包被TCC服务收到，出现了二阶段Cancel请求比一阶段Try请求先执行的状况；

用户在实现TCC服务时，应当容许空回滚，可是要拒绝执行空回滚以后到来的一阶段Try请求；

四、幂等控制：

不管是网络数据包重传，仍是异常事务的补偿执行，都会致使TCC服务的Try、Confirm或者Cancel操做被重复执行；用户在实现TCC服务时，须要考虑幂等控制，即Try、Confirm、Cancel 执行一次和执行屡次的业务结果是同样的；

五、业务数据可见性控制；

TCC服务的一阶段Try操做会作资源的预留，在二阶段操做执行以前，若是其余事务须要读取被预留的资源数据，那么处于中间状态的业务数据该如何向用户展现，须要业务在实现时考虑清楚；一般的设计原则是“宁肯不展现、少展现，也很少展现、错展现”；

六、业务数据并发访问控制；

TCC服务的一阶段Try操做预留资源以后，在二阶段操做执行以前，预留的资源都不会被释放；若是此时其余分布式事务修改这些业务资源，会出现分布式事务的并发问题；

用户在实现TCC服务时，须要考虑业务数据的并发控制，尽可能将逻辑锁粒度降到最低，以最大限度的提升分布式事务的并发性；

三、总结

蚂蚁金服使用TCC有10年历史，在TCC应用方面积累了大量实践经验；除了上述TCC服务的设计注意事项外，咱们在解决用户高并发、高可用需求方面也提供了解决方案，咱们对分布式事务作了极致的性能优化以支持双11等大促的高并发需求，咱们基于蚂蚁LDC架构的高可用方案能使分布式事务服务达到99.99%的可用性；

蚂蚁金服大部分业务系统均采用TCC的方式接入分布式事务，但设计TCC服务时要遵循大量设计规范，这无疑对用户提了很是高的要求；为了简化用户接入分布式事务的门槛，蚂蚁金服的分布式事务框架（SOFA-DTX）推出了FMT（Framework-managed transactions）模式和XA模式，这两种模式均不须要用户实现TCC服务，用户只须要关注自身业务SQL即可；DTX的三种模式：TCC、FMT和XA相互之间是功能互补，相辅相成的，造成了蚂蚁金服完善的分布式事务解决方案。

SOFA-DTX全面覆盖金融场景，金融级容灾保障、提供丰富的接入模式而且使用简洁易于接入；目前已经应用在支付宝、网上银行、蚂蚁财富、芝麻信用、南京银行等项目中。

文章做者：绍辉

原文连接本文为云栖社区原创内容，未经容许不得转载。