分布式事务之TCC事务

浅浅的花香味﹌ 2022-03-12 09:48 433阅读 0赞

### TCC 事务介绍 ###

在08年的软件开发2.0技术大会上，支付宝程立在PPT[大规模SOA系统中的分布事务处理][SOA]，提出TCC概念。 在网络上搜索分布式事务相关的博客，基本都会提及这个PPT，目前很多分布式事务开源项目也都是基于TCC的思想实现。

TCC 将事务提交分为 Try - Confirm - Cancel 3个操作。

*  Try：预留业务资源/数据效验
 *  Confirm：确认执行业务操作
 *  Cancel：取消执行业务操作

TCC事务处理流程和 2PC 二阶段提交类似，不过 2PC通常都是在跨库的DB层面，而TCC本质就是一个应用层面的2PC。

![20180604001625_695.jpg][]

TCC原理图，图片来自阿里公众号文章

### TCC 优缺点 ###

TCC优点：让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。

TCC不足之处：

*  对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
 *  实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等。

### TCC 事务应用场景 ###

我们通过用户下单使用余额+红包支付来看一下TCC事务的具体应用。

假设用户下单操作来自3个系统下单系统、资金账户系统、红包账户系统，下单成功需要同时调用资金账户服务和红包服务完成支付

假设购买商品1000元，使用账户红包200元，余额800元，确认支付。

*  **Try操作**  
    tryX 下单系统创建待支付订单  
    tryY 冻结账户红包200元  
    tryZ 冻结资金账户800元
 *  **Confirm操作**  
    confirmX 订单更新为支付成功  
    confirmY 扣减账户红包200元  
    confirmZ 扣减资金账户800元
 *  **Cancel操作**  
    cancelX 订单处理异常，资金红包退回，订单支付失败  
    cancelY 冻结红包失败，账户余额退回，订单支付失败  
    cancelZ 冻结余额失败，账户红包退回，订单支付失败

### TCC 开源项目实战 [tcc-transaction][] ###

> [tcc-transaction][] 是TCC型事务Java实现，tcc-transaction不和底层使用的rpc框架耦合，也就是使用doubbo,thrift,web service,http等都可以  
> 首先感谢开源作者无私奉献，顺手star、fork下。

在 tcc-transaction 事例中有dubbo、http实现，在这里我们使用dubbo事例。

事例的具体功能，其实就是上面介绍的 下单使用余额+红包支付。

tcc-transaction 事务管理器日志持久化支持多种方式

> 引用官方1.2指南说明：tcc-transaction框架使用transactionRepository持久化事务日志。可以选择FileSystemTransactionRepository、SpringJdbcTransactionRepository、RedisTransactionRepository或ZooKeeperTransactionRepository。

我们这里演示使用SpringJdbcTransactionRepository，存储到MySQL

1. 项目准备

假设本地环境MySQL、Zookeeper都已经准备完毕

使用IDEA，将项目克隆到本地

我们使用的实例为tcc-transaction-dubbo-sample

*  tcc-transaction-dubbo-capital 资金账户dubbo服务
 *  tcc-transaction-dubbo-capital-api 资金账户dubbo接口定义
 *  tcc-transaction-dubbo-order 下单系统
 *  tcc-transaction-dubbo-redpacket 红包账户dubbo服务
 *  tcc-transaction-dubbo-redpacket-api 红包账户dubbo接口定义

执行数据库脚本： tcc-transaction\\tcc-transaction-tutorial-sample\\src\\dbscripts\\create\_db\_cap.sql (资金账户)

tcc-transaction\\tcc-transaction-tutorial-sample\\src\\dbscripts\\create\_db\_ord.sql (订单库)

tcc-transaction\\tcc-transaction-tutorial-sample\\src\\dbscripts\\create\_db\_red.sql (红包账户)

tcc-transaction\\tcc-transaction-tutorial-sample\\src\\dbscripts\\create\_db\_tcc.sql (事务日志持久化)

修改项目配置： Zookeeper 配置

zookeeper.address=127.0.0.1:2181
    
    如果非默认配置，需要将tcc-transaction-dubbo-sample 下的模块全部修改

JDBC连接配置：

jdbc.driverClassName=com.mysql.jdbc.Driver
    tcc.jdbc.url=jdbc:mysql://127.0.0.1:3306/TCC?useUnicode=true&characterEncoding=UTF-8&allowMultiQueries=true
    jdbc.username=root
    jdbc.password=
    
    如果非默认配置，需要将tcc-transaction-dubbo-sample，tcc-transaction-sample-domain 下项目模块修改

2. 项目发布

实例目前都是使用的Tomcat发布，我们先部署Tomcat：

*  tcc-transaction-dubbo-capital 服务 [http://192.168.10.199:8881/][http_192.168.10.199_8881]
 *  tcc-transaction-dubbo-order 服务 [http://192.168.10.199:8882/][http_192.168.10.199_8882]
 *  tcc-transaction-dubbo-capital 服务 [http://192.168.10.199:8883/][http_192.168.10.199_8883]

服务全部启动成功：

![20180604001625_201.jpg][]

3. 多种事务场景测试

*  **第一种情况：红包账户冻结成功(try)、资金账户冻结成功(try)，订单操作异常(try)**

模拟异常代码：

![20180604001625_529.jpg][]

购买结果：

![20180604001625_640.jpg][]

此时订单支付失败，红包账户冻结金额、资金账户冻结金额全部退回。  
通过多种类似方式测试，例如：红包账户冻结异常、资金账户冻结异常，都会调cancel，退回冻结资源。所以在try阶段的任意一方异常，都会执行全局回滚。

*  **第二种情况：订单处理成功(confirm)，资金账户扣减成功(confirm)，但红包账户扣减失败(confirm)**

模拟异常代码，在红包扣减 confirm 操作制造异常：

![20180604001625_673.jpg][]

购买结果：

![20180604001625_467.jpg][]

此时订单为支付成功，但实际红包金额还处在冻结状态，事务管理器记录订单confirm操作未执行成功，系统会不断重试调用订单的confirm操作，直到红包扣减成功。

手动将红包服务异常代码去掉，重启服务，等到下一次重试，红包冻结金额被扣除成功。

*  **第三种情况: 资金账户冻结成功(try)，红包账户冻结成功(try)，订单处理失败(confirm)**

模拟异常代码，在订单 confirm 操作制造异常：

![20180604001625_295.jpg][]

购买结果：

![20180604001626_281.jpg][]

此时订单支付成功，但实际资金账户冻结金额、红包冻结金额都还没有扣除成功，事务管理器记录订单confirm操作未执行成功，系统会通过不断重试订单的confirm操作，直到资金账户和红包账户扣减成功。

手动将异常代码去掉，重启服务，等到下一次重试，红包和资金账户冻结金额被扣除。

*  **第四种情况：在第一种情况下，订单cancel操作处理失败(cancel)**

模拟异常代码，在第一种情况下基础，在cancel操作上在制造异常： ![20180604001626_638.jpg][]

购买结果：

![20180604001626_254.jpg][]

此时订单支付失败，资金账户、红包账户冻结成功，事务管理器记录订单cancel操作失败，系统会不断重试订单的cancel操作，直到资金账户和红包账户冻结金额退回账户。

手动将异常代码去掉，重启服务，下一次重试cancel操作，资金账户和红包账户冻结金额退回。

总结： try 操作成功，进入 confirm 操作，只要 confirm 处理失败（不管是协调者挂了，还是参与者处理失败或超时），系统通过不断重试直到处理成功。 进入 cancel 操作也是一样，只要 cancel 处理失败，系统通过不断重试直到处理成功。

[引用一段对话，具体说明TCC使用场景，以及和2PC对比][TCC_2PC]：

> 问题
> 
> 1.  对于转账的cancel事务，相对简单，只要把账务冲负即可。可一般的业务逻辑会涉及很多流程、单证等操作，尤其是历史系统，应该很难改造成tcc结构的吧，不知道你们用tcc用在什么场景下？
> 2.  我第一次是在支付宝架构师程立PPT中听说tcc结构的，不知道你的实现跟阿里系的实现是什么关系，目前应用的规模大吗？
> 3.  我理解try程序完成后，立即提交try事务，不会有锁事务竞争。可这个时候账户余额的状态也被设置成了类似不可读的状态吧，依然不可以在其他业务中查询账户余额，那么这种方案比2PC优势具体在什么地方？

> 回答
> 
> 1.  我的感觉TCC是比较适合具有较强一致性要求的场景，账务系统就是这样场景；应用TCC也有一定的开发成本，如果没有强一致性要求，可以考虑其他补偿型方案；
> 2.  目前已应用在线上环境多个应用，主要就是应用账务系统里使用；因为不是开源的，我没有看过阿里的实现，部分借鉴了他们的思路；希望有机会能看看；
> 3.  在Try结束后，账户余额会有部分资金冻结，其他业务不可以使用冻结资金；和2PC比较的话，理解下来有两点：
> 
>  *  2PC是基于资源层（如数据库），TCC是基于SOA服务
>  *  2PC是是用全局事务，数据被lock的时间跨整个事务，直到全局事务结束；而TCC里每个对资源操作的是本地事务，数据被lock的时间短，可扩展性好

[SOA]: https://wenku.baidu.com/view/be946bec0975f46527d3e104.html
[20180604001625_695.jpg]: /images/20220312/9dbf787605e7470788c4ab29588325d3.png
[tcc-transaction]: https://github.com/changmingxie/tcc-transaction
[http_192.168.10.199_8881]: http://192.168.10.199:8881/
[http_192.168.10.199_8882]: http://192.168.10.199:8882/
[http_192.168.10.199_8883]: http://192.168.10.199:8883/
[20180604001625_201.jpg]: /images/20220312/a5837edb5fc64a129c696330329ea314.png
[20180604001625_529.jpg]: /images/20220312/ff34ca9f08db48909c21c243d8400888.png
[20180604001625_640.jpg]: /images/20220312/f69960fc560345ba9f5cb5428626eb36.png
[20180604001625_673.jpg]: /images/20220312/0ea4e6565c474388a855811d2df30b28.png
[20180604001625_467.jpg]: /images/20220312/874ff0d1252b4d098557f85ac0c7c8c2.png
[20180604001625_295.jpg]: /images/20220312/4f8d5a109b1a4e1b95240ffdc92ef046.png
[20180604001626_281.jpg]: /images/20220312/eb5991890f0947a1ac76186ce2a87964.png
[20180604001626_638.jpg]: /images/20220312/5d56f0f56ea5466d8074b105bf76b20b.png
[20180604001626_254.jpg]: /images/20220312/27d0be9fc210432e822e2c4e514fd26e.png
[TCC_2PC]: https://github.com/changmingxie/tcc-transaction/issues/1