分布式事务之TCC事务

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

TCC 事务介绍

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

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

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

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

分布式事务之TCC事务_第1张图片

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/

服务全部启动成功:

分布式事务之TCC事务_第2张图片

3. 多种事务场景测试

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

模拟异常代码:

分布式事务之TCC事务_第3张图片

购买结果:

分布式事务之TCC事务_第4张图片

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

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

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

分布式事务之TCC事务_第5张图片

购买结果:

分布式事务之TCC事务_第6张图片

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

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

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

模拟异常代码,在订单 confirm 操作制造异常:

分布式事务之TCC事务_第7张图片

购买结果:

分布式事务之TCC事务_第8张图片

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

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

  • 第四种情况:在第一种情况下,订单cancel操作处理失败(cancel)

模拟异常代码,在第一种情况下基础,在cancel操作上在制造异常: 分布式事务之TCC事务_第9张图片

购买结果:

分布式事务之TCC事务_第10张图片

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

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

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

引用一段对话,具体说明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的时间短,可扩展性好

其实目前阿里分布式事务解决方案--GTS(Gloabel Trasaction Service)正在公测中,详情可以参考这篇公众号文章:GTS来了!阿里微服务架构下的分布式事务解决方案

参考资料

  • "分布式事务"解决方案汇总 -- 2PC/TCC/事务消息/1PC
  • tcc-transaction 使用指南1.2.x
  • GTS来了!阿里微服务架构下的分布式事务解决方案

转载于:https://my.oschina.net/wenjinglian/blog/1637901

你可能感兴趣的:(java,数据库,大数据)