分布式事务之TCC模型

来自:打杂的ZRJ(微信号:zrj_guduyan),作者:孤独烟

引言

在上篇文章《异步服务调用利器(消息队列)》一文中留了一个坑,今天来填坑。如下图所示


如果服务A和服务B之间是同步调用,比如服务C需要按流程调服务A和服务B,服务A和服务B要么一起成功,要么一起失败。

针对这种情况,目前业内普遍推荐使用TCC事务模型来解决的!

正文

ok,老规矩,我们先套一个业务场景进去,如下图所示

那页面点了支付按钮,调用支付服务,那我们后台要实现下面三个步骤

[1] 订单服务-修改订单状态
[2] 账户服务-扣减金钱
[3] 库存服务-扣减库存

达到事务的效果,要么一起成功,要么一起失败!就要采取TCC分布式事务方案!

概念

TCC的全称是(Try-Confirm-Cancel)。如下图所示


ps:TCC又可以被称为两阶段补偿事务,第一阶段try只是预留资源,第二阶段要明确的告诉服务提供者,这个资源你到底要不要,对应第二阶段的confirm/cancel,用来清除第一阶段的影响,所以叫补偿型事务。

再打个比方,说TCC太高大上是吧,讲RM中的prepare、commit、rollback接口,总知道吧。可以类比的这么理解


那差别在哪呢?

rollback、commit、prepare,站在开发者层面是感知不到的,数据库帮你做了资源的操作!
而try、confirm、cancel,站在开发者层面是能感知到的,这三个方法的业务逻辑,即对资源的操作,开发者是要自己去实现的!

好,下面套入我们的场景,怎么做呢。比如,你的订单服务中本来只有一个接口

//修改代码状态
orderClient.updateStatus();

都要拆为三个接口,即

orderClient.tryUpateStatus();
orderClient.confirmUpateStatus();
orderClient.cancelUpateStatus();

注意了:面试官如果问你,TCC有什么缺点?这就是很严重的缺点,对代码入侵性大!每套业务逻辑、都要按try(请求资源)、confirm(操作资源)、cancel(取消资源),拆分为三个接口!

具体每个阶段,每个服务业务逻辑是什么样的呢?

假设,库存数量本来是50,那么可销售库存也是50。账户余额为50,可用余额也为50。用户下单,买了1个单价为1元的商品。流程如下:

Try阶段

订单服务:修改订单的状态为支付中
账户服务:账户余额不变,可用余额减1,然后将1这个数字冻结在一个单独的字段里
库存服务:库存数量不变,可销售库存减1,然后将1这个数字冻结在一个单独的字段里

confirm阶段

订单服务:修改订单的状态为支付完成
账户服务:账户余额变为(当前值减冻结字段的值),可用余额不变(Try阶段减过了),冻结字段清0。
库存服务:库存变为(当前值减冻结字段的值),可销售库存不变(Try阶段减过了),冻结字段清0。

cancel阶段

订单服务:修改订单的状态为未支付
账户服务:账户余额不变,可用余额变为(当前值加冻结字段的值),冻结字段清0。
库存服务:库存不变,可销售库存变为(当前值加冻结字段的值),冻结字段清0。

伪代码

接下来从代码程序来说明,为了便于演示,将入参略去。

本来,你支付服务的代码是长下面这样的


那么,用上TCC模型后,代码变成下面这样


注意了,这种写法其实严格上来说,不是不行。看你业务场景,因为存在一些瑕疵,看你自己有没办法接受

(1)cancel或者confirm出现异常了,你怎么处理?

例如在cancel阶段执行如下三行代码

orderClient.cancelUpdateStatus();
accountClient.cancelDecrease();
repositoryClient.cancelDecrease();

你第二行出现异常了,第三行没跑就退出了,怎么办?你要对此进行业务补偿!

(2)大量逻辑重复

你看啊,我们的执行架构其实是这样的

try{
    xxclient.try();
}catch(Throwable t){
    xxclient.cancel();
    throw t;
}
xxclient.confirm();

有没办法让这个架子交给框架去执行,我们告诉框架,你在每个阶段要执行哪些方法就好!

因此,需要引入TCC分布式事务框架,事务的Try、Confirm、Cancel三个状态交给框架来感知!你只要告诉框架,Try要执行啥,Confirm要执行啥,Cancel要执行啥!如果Cancel过程出现异常了,框架有内部的补偿措施给你恢复数据!

以分布式tcc框架hmily为例,如果出现cancel异常或者confirm异常的情况,在try阶段会保存好日志,Hmily有内置的调度线程池来进行恢复,不用担心。

那hmily,怎么感知状态的呢?也很简单,就是切面编程,核心逻辑如下几行


我们在使用过程中,只要通过@Tcc注解告诉框架confirm方法执行啥,cancel方法执行啥即可!其他的交给框架帮你处理!

好了,不多说了,再说下去就是hmily源码解析了,大家有空自己去了解!

挖坑

注意看,《异步服务调用利器(消息队列)》和本文所涉及到的微服务都是同一平台的。

那如果碰到,不同平台之间调用,你要怎么保证事务?比如,我的服务要调银行接口,你觉得可能让银行接你的tcc框架么?或者让银行接你的消息对列?你们觉得现实么?当然,有的人会说:"一个http直接调了。"嗯,少年有想法!

ok,那么业内针对这种涉及到第三方接口的服务调用,如何保证一致性?大家好好思考。

推荐↓↓↓
数据库开发
上一篇:从零单排学Redis【铂金一】 下一篇:浅谈SQL Server内部运行机制