分布式事务(四)之TCC

在电商领域等互联网场景下,传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于CAP理论以及BASE理论,有人就提出了柔性事务的概念。在业内,关于柔性事务,最主要的有以下四种类型:两阶段型、补偿型、异步确保型、最大努力通知型几种。我们前边讲过的2PC和3PC都属于两阶段型,两阶段型事务存在长期锁定资源的情况,导致可用性差。接下来我们来介绍的TCC则是补偿型分布式事务。

TCC TCC 事务介绍

TCC方案是可能是目前最火的一种柔性事务方案了。关于TCC(Try-Confirm-Cancel)的概念,最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。在该论文中,TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司,其注册了TCC商标。国内最早关于TCC的报道,应该是InfoQ上对阿里程立博士的一篇采访。经过程博士的这一次传道之后,TCC在国内逐渐被大家广为了解并接受。

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

Try:预留业务资源/数据效验;

Confirm:确认执行业务操作;

Cancel:取消执行业务操作。

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

TCC概览

TCC示例

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

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

Try操作

tryX 下单系统创建待支付订单

tryY 冻结账户红包200元

tryZ 冻结资金账户800元

Confirm操作

confirmX 订单更新为支付成功

confirmY 扣减账户红包200元

confirmZ 扣减资金账户800元

Cancel操作

cancelX 订单处理异常,资金红包退回,订单支付失败

cancelY 冻结红包失败,账户余额退回,订单支付失败

cancelZ 冻结余额失败,账户红包退回,订单支付失败

TCC事务的优缺点:

优点:XA两阶段提交资源层面的,而TCC实际上把资源层面二阶段提交上提到了业务层面来实现。有效了的避免了XA两阶段提交占用资源锁时间过长导致的性能地下问题。

缺点:主业务服务和从业务服务都需要进行改造,从业务方改造成本更高。以上文中的订单服务为例,2PC中只需要提供一个下单接口即可,而TCC中缺需要提供Try-Confirm-Cancel三个接口,大大增加了开发量。

TCC变种

国内厂商在TCC实战中,提出了三种TCC变种实现:

通用型TCC,如果我们上面介绍的TCC模型实例,从业务服务需要提供try、confirm、cancel

补偿性TCC,从业务服务只需要提供Do和Compensate两个接口

异步确保型TCC,主业务服务的直接从业务服务是可靠消息服务,而真正的从业务服务则通过消息服务解耦,作为消息服务的消费端,异步地执行。

2PC实现分布式事务分为准备阶段和提交阶段,2PC的关键是在准备阶段,在这个阶段所有参与者必须完成约束检查,达成关于分布式事务一致性的共识。第二阶段,根据之前达成的共识,完成相应的操作。提交事务的过程中需要在很多个资源节点之间进行协调,而且每个节点对锁资源的释放必须等到事务最终提交的时候。这样两阶段事务提交会耗费更长的时间。事务执行时间长意味着锁资源发生冲突的概率增加,当事务的并发量积累到一定数量的时候,很可能出现事务积压甚至出现死锁。系统的性能和吞吐量就会下降。

而柔性事务(遵循BASE理论)放弃了隔离性,减小了事务中锁的粒度,使得应用能够更好的利用数据库的并发性能,实现吞吐量的线性扩展。异步执行方式可以更好的适应分布式环境,在网络抖动、节点故障的情况下能够尽量保障服务的可用性 (Availability)。因此在高可用、高性能的应用场景,柔性事务是最佳的选择。

我是御狐神,欢迎大家关注我的微信公众号:wzm2zsd

qrcode_for_gh_83670e17bbd7_344-2021-09-04-10-55-16

参考文档

分布式事务之柔性事务
柔性事务 :TCC两阶段补偿型

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zzpyyf.html