阿里的神器 Seata 实现了 TCC 模式来解决分布式事务!
大家好,我是不才陈某~
今天这篇文章介绍一下Seata如何实现TCC事务模式,文章目录如下:
什么是TCC模式?
TCC(Try Confirm Cancel)方案是一种应用层面侵入业务的两阶段提交。是目前最火的一种柔性事务方案,其核心思想是:针对每个操作,都要注册一个与其对应的确认和补偿(撤销)操作。
TCC分为两个阶段,分别如下:
- 第一阶段:Try(尝试),主要是对业务系统做检测及资源预留 (加锁,锁住资源)
-
第二阶段:本阶段根据第一阶段的结果,决定是执行confirm还是cancel
- Confirm(确认):执行真正的业务(执行业务,释放锁)
- Cancle(取消):是预留资源的取消(出问题,释放锁)
为了方便理解,下面以电商下单为例进行方案解析,这里把整个过程简单分为扣减库存,订单创建 2 个步骤,库存服务和订单服务分别在不同的服务器节点上。
假设商品库存为 100,购买数量为 2,这里检查和更新库存的同时,冻结用户购买数量的库存,同时创建订单,订单状态为待确认。
①Try 阶段
TCC 机制中的 Try 仅是一个初步操作,它和后续的确认一起才能真正构成一个完整的业务逻辑,这个阶段主要完成:
- 完成所有业务检查( 一致性 ) 。
- 预留必须业务资源( 准隔离性 ) 。
- Try 尝试执行业务。
②Confirm / Cancel 阶段
根据 Try 阶段服务是否全部正常执行,继续执行确认操作(Confirm)或取消操作(Cancel)。
Confirm 和 Cancel 操作满足幂等性,如果 Confirm 或 Cancel 操作执行失败,将会不断重试直到执行完成。
Confirm:当 Try 阶段服务全部正常执行, 执行确认业务逻辑操作,业务如下图:
这里使用的资源一定是 Try 阶段预留的业务资源。在 TCC 事务机制中认为,如果在 Try 阶段能正常的预留资源,那 Confirm 一定能完整正确的提交。
Confirm 阶段也可以看成是对 Try 阶段的一个补充,Try+Confirm 一起组成了一个完整的业务逻辑。
Cancel:当 Try 阶段存在服务执行失败, 进入 Cancel 阶段,业务如下图:
Cancel 取消执行,释放 Try 阶段预留的业务资源,上面的例子中,Cancel 操作会把冻结的库存释放,并更新订单状态为取消。
以上便是TCC模式的全部概念,这部分内容在陈某之前的文章也是详细的介绍过:对比7种分布式事务方案,还是偏爱阿里开源的Seata,真香!(原理+实战)
TCC模式的三种类型?
业内实际生产中对TCC模式进行了扩展,总结出了如下三种类型,其实从官方的定义中无此说法,不过是企业生产中根据实际的需求衍生出来的三种方案。
1、通用型 TCC 解决方案
通用型TCC解决方案是最经典的TCC事务模型的实现,正如第一节介绍的模型,所有的从业务都参与到主业务的决策中。
适用场景:
由于从业务服务是同步调用,其结果会影响到主业务服务的决策,因此通用型 TCC 分布式事务解决方案适用于执行时间确定且较短的业务,比如电商系统的三个核心服务:订单服务、账户服务、库存服务。
这个三个服务要么同时成功,要么同时失败。
当库存服务、账户服务的第二阶段调用完成后,整个分布式事务完成。
2、异步确保型 TCC 解决方案
异步确保型 TCC 解决方案的直接从业务服务是可靠消息服务,而真正的从业务服务则通过消息服务解耦,作为消息服务的消费端,异步地执行。
可靠消息服务需要提供 Try,Confirm,Cancel 三个接口。Try 接口预发送,只负责持久化存储消息数据;Confirm 接口确认发送,这时才开始真正的投递消息;Cancel 接口取消发送,删除消息数据。
消息服务的消息数据独立存储,独立伸缩,降低从业务服务与消息系统间的耦合,在消息服务可靠的前提下,实现分布式事务的最终一致性。
此解决方案虽然增加了消息服务的维护成本,但由于消息服务代替从业务服务实现了 TCC 接口,从业务服务不需要任何改造,接入成本非常低。
适用场景:
由于从业务服务消费消息是一个异步的过程,执行时间不确定,可能会导致不一致时间窗口增加。因此,异步确保性 TCC 分布式事务解决方案只适用于对最终一致性时间敏感度较低的一些被动型业务(从业务服务的处理结果不影响主业务服务的决策,只被动的接收主业务服务的决策结果)。比如会员注册服务和邮件发送服务:
3、补偿型 TCC 解决方案
补偿型 TCC 解决方案与通用型 TCC 解决方案的结构相似,其从业务服务也需要参与到主业务服务的活动决策当中。但不一样的是,前者的从业务服务只需要提供 Do 和 Compensate 两个接口,而后者需要提供三个接口。
Do 接口直接执行真正的完整业务逻辑,完成业务处理,业务执行结果外部可见;Compensate 操作用于业务补偿,抵消或部分抵消正向业务操作的业务结果,Compensate操作需满足幂等性。
与通用型解决方案相比,补偿型解决方案的从业务服务不需要改造原有业务逻辑,只需要额外增加一个补偿回滚逻辑即可,业务改造量较小。但要注意的是,业务在一阶段就执行完整个业务逻辑,无法做到有效的事务隔离,当需要回滚时,可能存在补偿失败的情况,还需要额外的异常处理机制,比如人工介入。
适用场景:
由于存在回滚补偿失败的情况,补偿型 TCC 分布式事务解决方案只适用于一些并发冲突较少或者需要与外部交互的业务,这些外部业务不属于被动型业务,其执行结果会影响主业务服务的决策。
以上部分内容参考自:seata.io/zh-cn/blog/…
TCC事务模式的落地实现
在前面文章中介绍了Seata的AT模式,有不清楚的可以看:对比7种分布式事务方案,还是偏爱阿里开源的Seata,真香!(原理+实战)
当然Seata支持的事务模式不局限于AT模式,还有TCC模式、SAGA模式、XA模式,下面整合一下TCC模式。
1、演示场景
就以电商系统中下订单为例,为了演示,直接去掉账户服务,以订单服务、库存服务为例介绍。
具体的逻辑如下:
- 客户端调用下订单接口
- 扣库存
- 创建订单
- 请求完成
根据上面的逻辑可知,订单服务肯定是主业务服务,事务的发起方,库存服务是从业务服务,参与事务的决策。
Seata的AT模式解决方案伪代码如下:
@GlobalTransactional
public Result<Void> createOrder(Long productId,Long num,.....){
//1、扣库存
reduceStorage();
//2、创建订单
saveOrder();
}
@GlobalTransactional这个注解用于发起一个全局事务。
但是AT模式有局限性,如下:
- 性能低,锁定资源时间太长
- 无法解决跨应用的事务
因此对于要求性能的下单接口,可以考虑使用TCC模式进行拆分成两阶段执行,这样整个流程锁定资源的时间将会变短,性能也能提高。
此时的TCC模式的拆分如下:
1、一阶段的Try操作
TCC模式中的Try阶段其实就是预留资源,在这个过程中可以将需要的商品数量的库存冻结,这样就要在库存表中维护一个冻结的库存这个字段。
伪代码如下:
@Transactional
public boolean try(){
//冻结库存
frozenStorage();
//生成订单,状态为待确认
saveOrder();
}
注意:@Transactional开启了本地事务,只要出现了异常,本地事务将会回滚,同时执行第二阶段的cancel操作。
2、二阶段的confirm操作
confirm操作在一阶段try操作成功之后提交事务,涉及到的操作如下:
- 释放try操作冻结的库存(冻结库存-购买数量)
- 生成订单
伪代码如下:
@Transactional
public boolean confirm(){
//释放掉try操作预留的库存
cleanFrozen();
//修改订单,状态为已完成
updateOrder();
return true;
}
注意:这里如果返回false,遵循TCC规范,应该要不断重试,直到confirm完成。
3、二阶段的cancel操作
cancel操作在一阶段try操作出现异常之后执行,用于回滚资源,涉及到的操作如下:
- 恢复冻结的库存(冻结库存-购买数量、库存+购买数量)
- 删除订单
伪代码如下:
@Transactional
public boolean cancel(){
//释放掉try操作预留的库存
rollbackFrozen();
//修改订单,状态为已完成
delOrder();
return true;
}
注意:这里如果返回false,遵循TCC规范,应该要不断重试,直到cancel完成。
2、TCC事务模型的三个异常
实现TCC事务模型涉及到的三个异常是不可避免的,实际生产中必须要规避这三大异常。
1、空回滚
定义:在未调用try方法或try方法未执行成功的情况下,就执行了cancel方法进行了回滚。
怎么理解呢?未调用try方法就执行了cancel方法,这个很容易理解,既然没有预留资源,那么肯定是不能回滚。
try方法未执行成功是什么意思?
可以看上节中的第一阶段try方法的伪代码,由于try方法开启了本地事务,一旦try方法执行过程中出现了异常,将会导致try方法的本地事务回滚(注意这里不是cancel方法回滚,而是try方法的本地事务回滚),这样其实try方法中的所有操作都将会回滚,也就没有必要调用cancel方法。
但是实际上一旦try方法抛出了异常,那么必定是要调用cancel方法进行回滚,这样就导致了空回滚。
解决方案:
解决逻辑很简单:在cancel方法执行操作之前,必须要知道try方法是否执行成功。
2、幂等性
TCC模式定义中提到:如果confirm或者cancel方法执行失败,要一直重试直到成功。
这里就涉及了幂等性,confirm和cancel方法必须保证同一个全局事务中的幂等性。
解决方案:
解决逻辑很简单:对付幂等,自然是要利用幂等标识进行防重操作。
3、悬挂
事务协调器在调用 TCC 服务的一阶段 Try 操作时,可能会出现因网络拥堵而导致的超时,此时事务管理器会触发二阶段回滚,调用 TCC 服务的 Cancel 操作,Cancel 调用未超时;
在此之后,拥堵在网络上的一阶段 Try 数据包被 TCC 服务收到,出现了二阶段 Cancel 请求比一阶段 Try 请求先执行的情况,此 TCC 服务在执行晚到的 Try 之后,将永远不会再收到二阶段的 Confirm 或者 Cancel ,造成 TCC 服务悬挂。
解决方案:
解决逻辑很简单:在执行try方法操作资源之前判断cancel方法是否已经执行;同样的在cancel方法执行后要记录执行的状态。
4、总结
针对以上三个异常,落地的解决方案很多,比如维护一个事务状态表,每个事务的执行阶段全部记录下来。
- 幂等:在执行confirm或者cancel之前根据事务状态表查询当前全局事务是否已经执行过confirm或者cancel方法
- 空回滚:在执行cancel之前才能根据事务状态表查询当前全局事务是否已经执行成功try方法
- 悬挂:在执行try方法之前,根据事务状态表查询当前全局事务是否已经执行过cancel方法
Seata整合TCC实现
关于如何搭建项目、添加依赖这里就不再细说了,不熟悉的可以看我之前的文章:对比7种分布式事务方案,还是偏爱阿里开源的Seata,真香!(原理+实战)
本节只介绍关键代码,毕竟篇幅有限,其他部分请自行下载源码。
案例源码已上传GitHub,关注公众号:码猿技术专栏,回复关键:9531 获取!
源码目录如下:
项目启动所需要的相关文件如下图:
nacos目录中的SEATA_GROUP是Seata事务服务端和客户端所需要的相关配置,直接导入nacos即可。
seata目录中的conf是1.3.0版本服务端的配置
SQL目录是相关的几个数据库。
1、TCC接口定义
在order-boot模块创建OrderTccService,代码如下:
代码中注释已经很完整了,下面挑几个重点介绍一下:
- @LocalTCC:该注解开启TCC事务
-
@TwoPhaseBusinessAction:该注解标注在try方法上,其中的三个属性如下:
- name:TCC事务的名称,必须是唯一的
- commitMethod:confirm方法的名称,默认是commit
- rollbackMethod:cancel方法的名称,,默认是rollback
- confirm和cancel的返回值尤为重要,返回false则会不断的重试。
2、TCC接口实现
定义有了,总要实现,如下:
1、try方法
①处的代码是为了防止悬挂异常,从事务日志表中获取全局事务ID的状态,如果是cancel状态则不执行。
②处的代码冻结库存
③处的代码生成订单,状态为待确认
④处的代码向幂等工具类中添加一个标记,key为当前类和全局事务ID,value为当前时间戳。
注意:必须要开启本地事务,如上代码使用@Transactional开启本地事务
2、confirm方法
①处的代码从幂等工具类中根据当前类和全局事务ID获取值,由于try阶段执行成功会向其中添加值,confirm方法执行成功会移出这个值,因此在confirm开头判断这个值是否存在就起到了幂等效果,防止重试的效果。
⑥处的代码从幂等工具类中移出try方法中添加的值。
②处的代码是从BusinessActionContext中获取try方法中的入参。
③处的代码是释放掉冻结的库存
④处的代码是修改订单的状态为已完成。
注意:1. 开启本地事务 2. 注意返回值,返回false时将会重试
3、cancel方法
①处的代码是向事务日志记录表中插入一条数据,标记当前事务进入cancel方法,用来防止悬挂,这个和try方法中的①处的代码相呼应。
②处的代码是为了防止幂等和空回滚,因为只有当try方法中执行成功幂等工具类中对应的当前类和全局事务ID才会存储该值。这样既防止了幂等,也防止了空回滚。
③处的代码恢复冻结的库存。
④处的代码删除这笔订单
⑤处的代码是移出幂等工具类当前类和全局事务ID对应的值。
3、如何防止TCC模型的三个异常?
实现方法有很多,有些案例是全部使用事务日志表记录当前的状态,这样完美的解决了幂等、空回滚、悬挂的问题。
陈某这里为了方便,使用了两种方案,如下:
1、幂等、空回滚
使用了一个幂等工具类,其中是个Map,key为当前类和全局事务ID,value是时间戳。
代码如下:
思路如下:
- 在try方法最后使用幂等工具类中的add方法添加值
- 在confirm、cancel方法中使用幂等工具类中的remove方法移出值
- 在confirm、cancel方法中使用幂等工具类中get方法获取值,如果为空,则表示已经执行过了,直接返回true,这样既防止了幂等,也防止了空回滚。
2、悬挂
悬挂的实现依靠的是事务日志表,表结构如下:
CREATE TABLE `transactional_record` (
`id` bigint(11) NOT NULL AUTO_INCREMENT,
`xid` varchar(100) NOT NULL,
`status` int(1) DEFAULT NULL COMMENT '1. try 2 commit 3 cancel ',
PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
其中的xid是全局事务ID,status是事务的状态。
其他的字段自己可以扩展
解决悬挂问题的逻辑如下:
- cancel方法中将当前全局事务ID记录到事务日志表中,状态为cancel
- try方法执行资源操作前检查事务日志表中当前全局事务ID是否已经是cancel状态
4、创建订单的业务方法
上面只是完成了TCC的三个方法,主业务事务发起方还未提供,代码如下:
@GlobalTransactional这个注解开启了全局事务,是事务的发起方。
内部直接调用的TCC的try方法。
5、其他的配置
以上只是列出了关键的步骤,剩余其他的配置自己根据案例源码完善,如下:
- 接口测试
- 整合nacos
- 整合feign
- 整合seata,TCC模式中的配置和AT模式的Seata配置相同
注意:一定要配置Seata的事务组tx-service-group,配置方法见之前的文章。
6、总结
TCC事务模型相对来说比较简单的一种,有兴趣的可以下载源码试试。
推荐阅读
-
阿里的神器 Seata 实现了 TCC 模式来解决分布式事务!
-
反传销网8月30日发布:视频区块链里的骗子,币里的韭菜,杜子建骂人了!金融大V周召说区块链!——“一小帮骗子玩一大帮小白,被割韭菜,小白还轮流被割,割的就是你!” 什么区块链,统统是骗子 作者:周召(知乎金融领域大V,毕业于上海财经大学,目前任职上海某股权投资基金合伙人) 有人问我,区块链现在这么火,到底是不是骗局? 我的回答是: 是骗局。而且我并不是说数字货币是骗局,而是说所有搞区块链的都是骗局。 -01- 区块链是一种鸡肋技术 人类社会任何技术的发明应用,本质都是为了提高社会的生产效率。而所谓区块链技术本质不过是几种早已成熟的技术的大杂烩,冗余且十分低效,除了提高了洗钱和诈骗的效率以外,对人类社会的进步毫无贡献。 真正意义上的区块链得包含三个要素:分布式系统(包括记账和存储),无法篡改的数据结构,以及共识算法,三者互为基础和因果,就像三体世界一样。看上去挺让人不明觉厉的,而经过几年的瞎折腾,稍微懂点区块链的碰了几次壁后都已经渐渐明白区块链其实并没有什么卵用,区块链技术已经名存实亡,沦为了营销工具和传销组织的画皮。 因为符合上述定义的、以比特币为代表的原教旨区块链技术,是反效率的,从经济学角度来说,不但不是一种帕累托改进,甚至还可以说是一种帕累托倒退。 原教旨区块链技术的效率十分低下,因为要遍历所有节点,只能做非常轻量级的数据应用,一旦涉及到大量的数据传输与更新,区块链就瞎了。 一方面整条链交易速度会极慢,另一方面数据库容量极速膨胀,考虑到人手一份的存储机制,区块链其实是对存储资源和能源的一种极大的浪费。 这里还没有加上为了取得所谓的共识和挖矿消耗的巨大的能源,如果说区块链技术是屎,那么这波区块链投机浪潮可谓人类历史上最大规模的搅屎运动。 区块链也验证不了任何东西。 所谓的智能合约,即不智能,也非合约。我看有人还说,如果有了智能合约,就可以跟老板签一份放区块链上,如果明年销售业绩提升30%,就加薪10%,由于区块链不能篡改,不能抵赖,所以老板必须得执行,说得有板有眼,不懂行的愣一看,好像还真是那么回事。 但仔细一想,问题就来了。首先,在区块链上如何证明你真的达到了30%业绩提升?即便真的达到老板耍赖如何执行? 也就是说,如果区块链真这么厉害,要法院和仲裁干什么。 人类社会真正的符合成本效益原则的是代理制度。之前有人说要用区块链改造注册会计师行业,我不知道他准备怎么设计,我猜想他思路大概是这样的,首先肯定搞去中心化,让所有会计师到链上来,然后一个新人要成为注册会计师就要所有会计师同意并记录在链上。 那我就请问了,我每天上班累死累活,为什么还要花时间去验证一个跟我无关的的人的专业能力?最优做法当然是组织一个委员会,让专门的人来负责,这不就是现在注册会师协会干的事儿吗?区块链的逻辑相当于什么事情都要拿出来公投,这个绝对是扯淡的。 当然这么说都有点抬举区块链了,区块链技术本身根本没有判断是非能力,如果这么高级的人工智能,靠一个无脑分布式记账就能实现的话,我们早就进入共产主义社会了。 虽然EOS等数字货币采用了超级节点,通过再中心化的方式提高效率,有点行业协会的意思,是对区块链原教旨主义的一种修正,但是依然无法突破区块链技术最本质的局限性。有人说,私有链和联盟链是区块链技术的未来,也是扯淡,因为区块链技术没有未来。如果有,说明他是包装成区块链的伪区块链技术。 区块链所涉及的所有底层技术,不管是分布式数据库技术,加密技术,还是点对点传输技术等,基本都是早已存在没什么秘密可言的技术。 比特币系统最重要的特性是封闭性和自洽性,他验证不了任何系统自身以外产生的信息的真实性。 所谓系统自身产生的信息,就是数据库数据的变动信息,有价值的基本上有且只有交易信息。所以说比特币最初不过是中本聪一种炫技的产物,来证明自己对几种技术的掌握,你看我多牛逼,设计出了一个像三体一样的系统。因此,数字货币很有可能是区块链从始至终唯一的杀手应用。 比特币和区块链概念从诞生到今天已经快10年了,很多人说区块链技术在爆发的前夜,但这个前夜好像是不是有点过长了啊朋友,跟三体里的长夜有一拼啊。都说区块链技术像是90年代初的互联网,可是90年代初的互联网在十年发展后,已经出现了一大批伟大的公司,阿里巴巴在99年都成立了,区块链怎么除了币还是币呢? 正规的数字货币未来发展的形式无外乎几种,要么就是论坛币形式,或者类似股票的权益凭证等。问题是论坛币和股票之前,本来也都电子化了,区块链来了到底改变了什么呢? 所有想把TOKEN和应用场景结合起来的人最后都很痛苦,最后他们会发现区块链技术就是脱裤子放屁,自己辛苦搞半天,干嘛不自己作为中心关心门来收钱?最后这些人都产生了价值的虚无感,最终精神崩溃,只能发币疯狂收割韭菜,一边嘴里还说着我是个好人之类的奇怪的话。 因此,之前币圈链圈还泾渭分明,互相瞧不起,但这两年链圈逐渐坐不住了,想着是不是趁着泡沫没彻底破灭之前赶快收割一波,不然可能什么都捞不着了。 前段时间和一个名校毕业的链圈朋友瞎聊天,他说他们“致力于用区块链技术解决数字版权保护问题”,我就问他一个问题,你们如何保证你链的版权所有权声明是真实的,万一盗版者抢先一步把数据放在链上怎么办。他说他们的解决方案是连入国家数字版权保护中心的数据库进行验证…… 所以说区块链技术就是个鸡肋,研究到最后都会落入效率与真实性的黑洞,很多人一头扎进链圈后才发现,真正意义上的区块链技术,其实什么都干不了。 -02- 不是蠢就是坏的区块链媒体 空气币和区块链的造富神话,让区块链自媒体也开始迎风乱扭。一群群根本不知道区块链为何物的妖魔鬼怪纷纷进驻区块链自媒体战场,开始大放厥词胡编乱造。 任何东西,但凡只要和区块,链,分,分布式,记账,加密,验证,可追溯等等这些个关键词沾到哪怕一点点,这些所谓的区块链媒体人就会像狗闻到了屎了一样疯狂地把区块链概念往上套。 这让我想起曾经一度也是热闹非凡的物联网,我曾经去看过江苏一家号称要改变世界的“物联网”企业,过去一看是生产路由器的,我黑人问号脸,对方解释说没有路由器万物怎么互联,我觉得他说得好有道理,竟无言以对。 好,下面让我们进入奇葩共赏析时间,来看看区城链媒体经常有哪些危言耸听的奇谈怪论 区块链(分布式记账)的典型应用是*?? 正如前面所说,真正意义上的区块链分布式记账,不光包括“记”这个动作,还包括分布式存储和共识机制等。而*诞生远远早于区块链这个词的出现,勉强算是“分布式编辑”吧,就被很多区块链媒体拿来强行充当区块链技术应用的典范。 其实事实恰恰相反,*恰恰是去中心化失败的典范,现在如果没有精英和专业人士的编辑和维护,*早就没法看了。 区块链会促进社会分工?? 罗振宇好像就说过类似的话,虽然罗振宇说过很多没有逻辑的话,但这句话绝对是最没逻辑思维的。很多区块链自媒体也常常用这句话来忽悠老百姓,说分工代表效率提高社会进步,而区块链“无疑”会促进分工,他们的理由仅仅是分工和分布式记账都共用一个“分”字,就强行把他们扯到一起。 实际情况恰恰相反,区块链是逆分工的,区块链精神是号召所有人积极地参与到他不擅长也不想掺合的事情里面去。 区块链不能像上帝一样许诺他的子民死后上天国,只能给他们许诺你们是六度人脉中的第一级,我可以赚后面五级人的钱,你处于金字塔的顶端。
-
Seata聚合 AT、TCC、SAGA 、 XA事务模式打造一站式的分布式事务解决方案