处置散布式事务 TCC Seata 真香！

当天这篇文章引见一下Seata如何成功TCC事务形式，文章目录如下：

什么是TCC形式？

TCC（Try Confirm Cancel）打算是一种运行层面侵入业务的两阶段提交。是目前最火的一种柔性事务打算，其外围现实是：针对每个操作，都要注册一个与其对应确实认和补救（撤销）操作。

TCC分为两个阶段，区分如下：

Confirm（确认）：口头真正的业务（口头业务，监禁锁）

Cancle（敞开）：是预留资源的敞开（出疑问，监禁锁）

为了繁难了解，上方以电商下单为例启动打算解析，这里把整个环节繁难分为扣减库存，订单创立 2 个步骤，库存服务和订单服务区分在不同的主机节点上。

假定商品库存为 100，购置数量为 2，这里审核和降级库存的同时，解冻用户购置数量的库存，同时创立订单，订单形态为待确认。

①Try 阶段

TCC 机制中的 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 散布式事务处置打算只实用于一些并发抵触较少或许要求与外部交互的业务，这些外部业务不属于主动型业务，其口头结果会影响主业务服务的决策。

以上局部内容参考自：

TCC事务形式的落地成功

在前面文章中引见了Seata的AT形式，有不分明的可以看：对比7种散布式事务打算，还是偏爱阿里开源的Seata，真香！(原理+实战)

当然Seata允许的事务形式不局限于AT形式，还有TCC形式、SAGA形式、XA形式，上方整合一下TCC形式。

1、演示场景

就以电商系统中下订单为例，为了演示，间接去掉账户服务，以订单服务、库存服务为例引见。

详细的逻辑如下：

依据上方的逻辑可知，订单服务必需是主业务服务，事务的动员方，库存服务是从业务服务，介入事务的决策。

Seata的AT形式处置打算伪代码如下：

 ResultVoid createOrderLong productIdLong num{reduceStoragesaveOrder}

@GlobalTransactional这个注解用于动员一个全局事务。

然而AT形式有局限性，如下：

因此关于要求性能的下单接口，可以思考经常使用TCC形式启动拆分红两阶段口头，这样整个流程锁定资源的期间将会变短，性能也能提高。

此时的TCC形式的拆分如下：

1）一阶段的Try操作

TCC形式中的Try阶段其实就是预留资源，在这个环节中可以将要求的商品数量的库存解冻，这样就要在库存表中保养一个解冻的库存这个字段。

伪代码如下：

  try{frozenStorage//生成订单，形态为待确认saveOrder}

留意：@Transactional开启了本地事务，只需产生了意外，本地事务将会回滚，同时口头第二阶段的cancel操作。

2）二阶段的confirm操作

confirm操作在一阶段try操作成功之后提交事务，触及到的操作如下：

伪代码如下：

  confirm{//监禁掉try操作预留的库存cleanFrozen//修正订单，形态为已成功updateOrder }

留意：这里假设前往false，遵照TCC规范，应该要不时重试，直到confirm成功。

3）二阶段的cancel操作

cancel操作在一阶段try操作产生意外之后口头，用于回滚资源，触及到的操作如下：

伪代码如下：

  cancel{//监禁掉try操作预留的库存rollbackFrozen//修正订单，形态为已成功delOrder }

留意：这里假设前往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）总结

针对以上三个意外，落地的处置打算很多，比如保养一个事务形态表，每个事务的口头阶段所有记载上去。

Seata整合TCC成功

关于如何搭建名目、参与依赖这里就不再细说了，不相熟的可以看我之前的文章：对比7种散布式事务打算，还是偏爱阿里开源的Seata，真香！(原理+实战)

本节只引见关键代码，毕竟篇幅有限，其余局部请自行下载源码。

案例源码已上行GitHub，关注群众号：码猿技术专栏，回复关键：9528失掉！

源码目录如下：

名目启动所要求的相关文件如下图：

nacos目录中的SEATA_GROUP是Seata事务服务端和客户端所要求的相关性能，间接导入nacos即可。

seata目录中的conf是1.3.0版本服务端的性能

SQL目录是相关的几个数据库。

1、TCC接口定义

在order-boot模块创立OrderTccService，代码如下：

代码中注释曾经很完整了，上方挑几个重点引见一下：

name：TCC事务的称号，必需是惟一的

commitMethod：confirm方法的称号，自动是commit

rollbackMethod：cancel方法的称号，，自动是rollback

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是期间戳。

代码如下：

思绪如下：

2）悬挂

悬挂的成功依托的是事务日志表，表结构如下：

其中的xid是全局事务ID，status是事务的形态。

其余的字段自己可以裁减

处置悬挂疑问的逻辑如下：

4、创立订单的业务方法

上方只是成功了TCC的三个方法，主业务事务动员方还未提供，代码如下：

@GlobalTransactional这个注解开启了全局事务，是事务的动员方。

外部间接调用的TCC的try方法。

5、其余的性能

以上只是列出了关键的步骤，残余其余的性能自己依据案例源码完善，如下：

留意：肯定要性能Seata的事务组tx-service-group，性能方法见之前的文章。

6、总结

TCC事务模型相对来说比拟繁难的一种，有兴味的可以下载源码试试。