30_8、业内分布式事务方案介绍：分析TCC分布式事务技术方案落地在项目中的一些细节

其实这个所谓TCC方案里有很多细节要考量一下啊！！！

1、接口拆分问题

首先就是，从业务服务的每个接口都要拆分为三个接口，一个是try接口，一个是confirm接口，一个是cancel接口，也就是说要提供分布式事务实现的业务接口，自己就要考虑好这个，要提供3个接口

虽然真是够麻烦的，不过也没办法

try接口里，一般就是预留资源，比如说经典的资金转账，卡掉一些锁定资金，你要是不这么干，万一别的分布式事务给你干掉了一些资金，那你实际执行confirm的时候一旦检查资金余额就会发现转账失败，余额不足了

有些接口，没有资源锁定的操作，try接口就留空

confirm就是原来的业务方法，该干嘛干嘛

cnacel接口，要提供回滚的方法，就是把try或者confirm里的操作给他回滚了

就比如说，如果是try阶段，资金服务的try成功了，资金被冻结了24块钱，结果订单服务的try失败了，主业务服务就会通知回滚，调用资金服务的cancel接口，就要检查一下lock_amount字段里的值，将里面的24块钱转回到原来的amount字段里面去

confirm阶段，资金服务，都把24块钱从id=1的账号里转移到id=2的账号里去了，lock_amount也扣减掉了24块钱。结果积分服务的confirm失败了，整个分布式事务回滚，调用各个接口的cancel接口

资金服务，就变成了需要将id=2的账号的amount字段扣减掉24块钱，给id=1的账户增加24块钱

2、接口的几种特殊情况

（1）空回滚：那要是try阶段，比如网络问题，人家压根儿没调通你的try接口，结果就认定失败，直接调用你的cancel接口，咋办？所以你这个时候啥都不能干

（2）try回滚以及confirm回滚：try阶段如果执行了，但是其他服务try失败了，那么会调用cancel来回滚，你要可以回滚掉try阶段的操作；confirm阶段要是你执行了，但是有别的服务失败了，此时你就要回滚掉confirm阶段的操作

（3）倒置请求：比如说人家调用try接口，中间网络超时了，结果认定失败，直接调用cancel空回滚了；结果过了几秒钟try接口请求到来，此时咋整呢？尴尬了吧，你要在这个时候不允许执行try接口操作；同理啊，confirm请求超时了，结果都cancel掉了，但是过了几秒请求来了，让你confirm，你能干这事儿吗？

3、接口的幂等性保证

你有没有考虑过一个问题，就是try、confirm和cancel都可能被多次调用，所以无论怎么样，你都得保证这几个接口的幂等性，分布式接口幂等性那必须依赖第三方的中间件来实现，可以考虑使用经典的zk，zk非常适用于分布式系统的协调类操作

所以一个接口对同一个参数调用，只能调用一次，保证幂等操作

4、tcc分布式事务框架

我们的主业务服务那块，那必须得用tcc事务框架，不然各种接口调用，还有就是业务活动管理器，难不成都大家自己来写代码搞？？？？那就废掉了啊！所以必须要选用一种tcc分布式事务框架，来实现主业务服务的各种try confirm concel控制逻辑，同时实现业务活动的管理

5、总结

玩儿tcc初步来讲主要就是上述那些问题，其实说白了，一个就是从业务服务那块的接口的问题，还有一个其实就是主业务服务那块的业务活动管理器的控制，以及整个分布式事务的控制