定制型网站建设,厦门大型企业网站开发公司,西宁建一个网站公司,备案网站建设书今天这篇文章介绍一下Seata如何实现TCC事务模式#xff0c;文章目录如下#xff1a;目录什么是TCC模式#xff1f;TCC#xff08;Try Confirm Cancel#xff09;方案是一种应用层面侵入业务的两阶段提交。是目前最火的一种柔性事务方案#xff0c;其核心思想是#xff1… 今天这篇文章介绍一下Seata如何实现TCC事务模式文章目录如下目录什么是TCC模式TCCTry Confirm Cancel方案是一种应用层面侵入业务的两阶段提交。是目前最火的一种柔性事务方案其核心思想是针对每个操作都要注册一个与其对应的确认和补偿撤销操作。TCC分为两个阶段分别如下第一阶段Try尝试主要是对业务系统做检测及资源预留 (加锁锁住资源)第二阶段本阶段根据第一阶段的结果决定是执行confirm还是cancelConfirm确认执行真正的业务执行业务释放锁Cancle取消是预留资源的取消出问题释放锁TCC为了方便理解下面以电商下单为例进行方案解析这里把整个过程简单分为扣减库存订单创建 2 个步骤库存服务和订单服务分别在不同的服务器节点上。假设商品库存为 100购买数量为 2这里检查和更新库存的同时冻结用户购买数量的库存同时创建订单订单状态为待确认。①Try 阶段TCC 机制中的 Try 仅是一个初步操作它和后续的确认一起才能真正构成一个完整的业务逻辑这个阶段主要完成完成所有业务检查( 一致性 ) 。预留必须业务资源( 准隔离性 ) 。Try 尝试执行业务。Try阶段②Confirm / Cancel 阶段根据 Try 阶段服务是否全部正常执行继续执行确认操作Confirm或取消操作Cancel。Confirm 和 Cancel 操作满足幂等性如果 Confirm 或 Cancel 操作执行失败将会不断重试直到执行完成。Confirm当 Try 阶段服务全部正常执行 执行确认业务逻辑操作业务如下图Try-Confirm这里使用的资源一定是 Try 阶段预留的业务资源。在 TCC 事务机制中认为如果在 Try 阶段能正常的预留资源那 Confirm 一定能完整正确的提交。Confirm 阶段也可以看成是对 Try 阶段的一个补充TryConfirm 一起组成了一个完整的业务逻辑。Cancel当 Try 阶段存在服务执行失败 进入 Cancel 阶段业务如下图Try-CancelCancel 取消执行释放 Try 阶段预留的业务资源上面的例子中Cancel 操作会把冻结的库存释放并更新订单状态为取消。TCC模式的三种类型业内实际生产中对TCC模式进行了扩展总结出了如下三种类型其实从官方的定义中无此说法不过是企业生产中根据实际的需求衍生出来的三种方案。1、通用型 TCC 解决方案通用型TCC解决方案是最经典的TCC事务模型的实现正如第一节介绍的模型所有的从业务都参与到主业务的决策中。通用型TCC适用场景由于从业务服务是同步调用其结果会影响到主业务服务的决策因此通用型 TCC 分布式事务解决方案适用于执行时间确定且较短的业务比如电商系统的三个核心服务订单服务、账户服务、库存服务。这个三个服务要么同时成功要么同时失败。当库存服务、账户服务的第二阶段调用完成后整个分布式事务完成。2、异步确保型 TCC 解决方案异步确保型 TCC 解决方案的直接从业务服务是可靠消息服务而真正的从业务服务则通过消息服务解耦作为消息服务的消费端异步地执行。异步确保型可靠消息服务需要提供 TryConfirmCancel 三个接口。Try 接口预发送只负责持久化存储消息数据Confirm 接口确认发送这时才开始真正的投递消息Cancel 接口取消发送删除消息数据。消息服务的消息数据独立存储独立伸缩降低从业务服务与消息系统间的耦合在消息服务可靠的前提下实现分布式事务的最终一致性。此解决方案虽然增加了消息服务的维护成本但由于消息服务代替从业务服务实现了 TCC 接口从业务服务不需要任何改造接入成本非常低。适用场景由于从业务服务消费消息是一个异步的过程执行时间不确定可能会导致不一致时间窗口增加。因此异步确保性 TCC 分布式事务解决方案只适用于对最终一致性时间敏感度较低的一些被动型业务从业务服务的处理结果不影响主业务服务的决策只被动的接收主业务服务的决策结果。比如会员注册服务和邮件发送服务3、补偿型 TCC 解决方案补偿型 TCC 解决方案与通用型 TCC 解决方案的结构相似其从业务服务也需要参与到主业务服务的活动决策当中。但不一样的是前者的从业务服务只需要提供 Do 和 Compensate 两个接口而后者需要提供三个接口。Do 接口直接执行真正的完整业务逻辑完成业务处理业务执行结果外部可见Compensate 操作用于业务补偿抵消或部分抵消正向业务操作的业务结果Compensate操作需满足幂等性。与通用型解决方案相比补偿型解决方案的从业务服务不需要改造原有业务逻辑只需要额外增加一个补偿回滚逻辑即可业务改造量较小。但要注意的是业务在一阶段就执行完整个业务逻辑无法做到有效的事务隔离当需要回滚时可能存在补偿失败的情况还需要额外的异常处理机制比如人工介入。适用场景由于存在回滚补偿失败的情况补偿型 TCC 分布式事务解决方案只适用于一些并发冲突较少或者需要与外部交互的业务这些外部业务不属于被动型业务其执行结果会影响主业务服务的决策。“以上部分内容参考自https://seata.io/zh-cn/blog/tcc-mode-applicable-scenario-analysis.html?utm_sourcegold_browser_extension”TCC事务模式的落地实现在前面文章中介绍了Seata的AT模式当然Seata支持的事务模式不局限于AT模式还有TCC模式、SAGA模式、XA模式下面整合一下TCC模式。1、演示场景就以电商系统中下订单为例为了演示直接去掉账户服务以订单服务、库存服务为例介绍。具体的逻辑如下客户端调用下订单接口扣库存创建订单请求完成根据上面的逻辑可知订单服务肯定是主业务服务事务的发起方库存服务是从业务服务参与事务的决策。Seata的AT模式解决方案伪代码如下GlobalTransactional
public ResultVoid 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实现关于如何搭建项目、添加依赖这里就不再细说了本节介绍一下关键代码。源码目录如下源码目录项目启动所需要的相关文件如下图nacos目录中的SEATA_GROUP是Seata事务服务端和客户端所需要的相关配置直接导入nacos即可。seata目录中的conf是1.3.0版本服务端的配置SQL目录是相关的几个数据库。1、TCC接口定义在order-boot模块创建OrderTccService代码如下代码中注释已经很完整了下面挑几个重点介绍一下LocalTCC该注解开启TCC事务TwoPhaseBusinessAction该注解标注在try方法上其中的三个属性如下nameTCC事务的名称必须是唯一的commitMethodconfirm方法的名称默认是commitrollbackMethodcancel方法的名称默认是rollbackconfirm和cancel的返回值尤为重要返回false则会不断的重试。2、TCC接口实现定义有了总要实现如下1、try方法try方法①处的代码是为了防止悬挂异常从事务日志表中获取全局事务ID的状态如果是cancel状态则不执行。②处的代码冻结库存③处的代码生成订单状态为待确认④处的代码向幂等工具类中添加一个标记key为当前类和全局事务IDvalue为当前时间戳。“注意必须要开启本地事务如上代码使用Transactional开启本地事务”2、confirm方法confirm方法①处的代码从幂等工具类中根据当前类和全局事务ID获取值由于try阶段执行成功会向其中添加值confirm方法执行成功会移出这个值因此在confirm开头判断这个值是否存在就起到了幂等效果防止重试的效果。⑥处的代码从幂等工具类中移出try方法中添加的值。②处的代码是从BusinessActionContext中获取try方法中的入参。③处的代码是释放掉冻结的库存④处的代码是修改订单的状态为已完成。“注意1. 开启本地事务 2. 注意返回值返回false时将会重试”3、cancel方法cancel方法①处的代码是向事务日志记录表中插入一条数据标记当前事务进入cancel方法用来防止悬挂这个和try方法中的①处的代码相呼应。②处的代码是为了防止幂等和空回滚因为只有当try方法中执行成功幂等工具类中对应的当前类和全局事务ID才会存储该值。这样既防止了幂等也防止了空回滚。③处的代码恢复冻结的库存。④处的代码删除这笔订单⑤处的代码是移出幂等工具类当前类和全局事务ID对应的值。3、如何防止TCC模型的三个异常实现方法有很多有些案例是全部使用事务日志表记录当前的状态这样完美的解决了幂等、空回滚、悬挂的问题。陈某这里为了方便使用了两种方案如下1、幂等、空回滚使用了一个幂等工具类其中是个Mapkey为当前类和全局事务IDvalue是时间戳。代码如下思路如下在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
) ENGINEInnoDB DEFAULT CHARSETutf8mb4;其中的xid是全局事务IDstatus是事务的状态。“其他的字段自己可以扩展”解决悬挂问题的逻辑如下cancel方法中将当前全局事务ID记录到事务日志表中状态为canceltry方法执行资源操作前检查事务日志表中当前全局事务ID是否已经是cancel状态4、创建订单的业务方法上面只是完成了TCC的三个方法主业务事务发起方还未提供代码如下GlobalTransactional这个注解开启了全局事务是事务的发起方。内部直接调用的TCC的try方法。5、其他的配置以上只是列出了关键的步骤剩余其他的配置自己根据案例源码完善如下接口测试整合nacos整合feign整合seataTCC模式中的配置和AT模式的Seata配置相同“注意一定要配置Seata的事务组tx-service-group配置方法见之前的文章。”6、总结TCC事务模型相对来说比较简单的一种有兴趣的可以下载源码试试。往期推荐synchronized和ReentrantLock的5个区别oppo后端16连问怎么解决MySQL死锁问题的
