分布式事务之TCC事务
TCC 事务介绍
在08年的软件开发2.0技术大会上,支付宝程立在PPT大规模SOA系统中的分布事务处理,提出TCC概念。 在网络上搜索分布式事务相关的博客,基本都会提及这个PPT,目前很多分布式事务开源项目也都是基于TCC的思想实现。
TCC 将事务提交分为 Try - Confirm - Cancel 3个操作。
- Try:预留业务资源/数据效验
- Confirm:确认执行业务操作
- Cancel:取消执行业务操作
TCC事务处理流程和 2PC 二阶段提交类似,不过 2PC通常都是在跨库的DB层面,而TCC本质就是一个应用层面的2PC。
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/
- tcc-transaction-dubbo-order 服务 http://192.168.10.199:8882/
- tcc-transaction-dubbo-capital 服务 http://192.168.10.199:8883/
服务全部启动成功:
3. 多种事务场景测试
- 第一种情况:红包账户冻结成功(try)、资金账户冻结成功(try),订单操作异常(try)
模拟异常代码:
购买结果:
此时订单支付失败,红包账户冻结金额、资金账户冻结金额全部退回。
通过多种类似方式测试,例如:红包账户冻结异常、资金账户冻结异常,都会调cancel,退回冻结资源。所以在try阶段的任意一方异常,都会执行全局回滚。
- 第二种情况:订单处理成功(confirm),资金账户扣减成功(confirm),但红包账户扣减失败(confirm)
模拟异常代码,在红包扣减 confirm 操作制造异常:
购买结果:
此时订单为支付成功,但实际红包金额还处在冻结状态,事务管理器记录订单confirm操作未执行成功,系统会不断重试调用订单的confirm操作,直到红包扣减成功。
手动将红包服务异常代码去掉,重启服务,等到下一次重试,红包冻结金额被扣除成功。
- 第三种情况: 资金账户冻结成功(try),红包账户冻结成功(try),订单处理失败(confirm)
模拟异常代码,在订单 confirm 操作制造异常:
购买结果:
此时订单支付成功,但实际资金账户冻结金额、红包冻结金额都还没有扣除成功,事务管理器记录订单confirm操作未执行成功,系统会通过不断重试订单的confirm操作,直到资金账户和红包账户扣减成功。
手动将异常代码去掉,重启服务,等到下一次重试,红包和资金账户冻结金额被扣除。
- 第四种情况:在第一种情况下,订单cancel操作处理失败(cancel)
模拟异常代码,在第一种情况下基础,在cancel操作上在制造异常:
购买结果:
此时订单支付失败,资金账户、红包账户冻结成功,事务管理器记录订单cancel操作失败,系统会不断重试订单的cancel操作,直到资金账户和红包账户冻结金额退回账户。
手动将异常代码去掉,重启服务,下一次重试cancel操作,资金账户和红包账户冻结金额退回。
总结: try 操作成功,进入 confirm 操作,只要 confirm 处理失败(不管是协调者挂了,还是参与者处理失败或超时),系统通过不断重试直到处理成功。 进入 cancel 操作也是一样,只要 cancel 处理失败,系统通过不断重试直到处理成功。
问题
- 对于转账的cancel事务,相对简单,只要把账务冲负即可。可一般的业务逻辑会涉及很多流程、单证等操作,尤其是历史系统,应该很难改造成tcc结构的吧,不知道你们用tcc用在什么场景下?
- 我第一次是在支付宝架构师程立PPT中听说tcc结构的,不知道你的实现跟阿里系的实现是什么关系,目前应用的规模大吗?
- 我理解try程序完成后,立即提交try事务,不会有锁事务竞争。可这个时候账户余额的状态也被设置成了类似不可读的状态吧,依然不可以在其他业务中查询账户余额,那么这种方案比2PC优势具体在什么地方?
回答
- 我的感觉TCC是比较适合具有较强一致性要求的场景,账务系统就是这样场景;应用TCC也有一定的开发成本,如果没有强一致性要求,可以考虑其他补偿型方案;
- 目前已应用在线上环境多个应用,主要就是应用账务系统里使用;因为不是开源的,我没有看过阿里的实现,部分借鉴了他们的思路;希望有机会能看看;
- 在Try结束后,账户余额会有部分资金冻结,其他业务不可以使用冻结资金;和2PC比较的话,理解下来有两点:
- 2PC是基于资源层(如数据库),TCC是基于SOA服务
- 2PC是是用全局事务,数据被lock的时间跨整个事务,直到全局事务结束;而TCC里每个对资源操作的是本地事务,数据被lock的时间短,可扩展性好
其实目前阿里分布式事务解决方案--GTS(Gloabel Trasaction Service)正在公测中,详情可以参考这篇公众号文章:GTS来了!阿里微服务架构下的分布式事务解决方案
引用自:https://www.liangzl.com/get-article-detail-525.html