• 极客专栏正式上线!欢迎访问 https://www.jikewenku.com/topic.html
  • 极客专栏正式上线!欢迎访问 https://www.jikewenku.com/topic.html

我说分布式事务之TCC

技术杂谈 勤劳的小蚂蚁 2个月前 (02-10) 87次浏览 已收录 0个评论 扫描二维码
接触分布式相关的开发已经有一段时间了,自然绕不开分布式事务。从本文开始,我将带领大家了解常见的分布式事务的解决方案,深入原理,浅出实践,让我们在今后的开发中对分布式事务不再畏惧。

常见的分布式解决方案有:
  • 最大努力通知型事务
  • 可靠消息一致性事务
  • TCC事务

本文我们就详细的讲解TCC分布式事务的原理及应用场景。Here we go!

TCC是try-confirm-cancel的单词首字母缩写,是一个类2PC的柔性事务解决方案,由支付宝提出后得到广泛的实践。

首先我们看它的一个原理图(网上找到)。

图中的主服务调用两个从服务,这两个从服务属于不同的进程,各自操作不同的数据库表。主服务A调用从服务B后,继续调用从服务C,这个过程要保证调用B、C同时成功,同时失败。如果任何一个服务的操作失败了,就全部一起回滚,撤销已经完成的操作。

那么如何保证多个服务的调用是同时成功、同时失败呢。TCC帮我们实现了这个目标。

TRY阶段

首先进行TRY阶段,该阶段主要做资源的锁定/预留,设置一个预备的状态,冻结部分数据,等等。

比如:电商平台先在订单模块做下单操作,下单成功后调用库存模块做扣减库存,扣减成功调用支付接口进行支付,然后调用积分模块做积分的增加,最后调用发货模块做发货处理。

这个过程中的Try阶段描述如下:
订单服务先做下单操作,这是个本地事务,能够保证ACID的事务特性。下单成功后,订单服务将当前订单状态由初始化改为处理中进行扣库存操作,这里不能直接将库存扣除,应当冻结库存,将库存减去后,将减去的值保存在已冻结的字段中。

例如:本来库存数量是100,要减去5个库存,不能直接100 – 5 = 95,而是要把可销售的库存设置为:100 – 5 = 95,接着在一个单独的库存冻结的字段里,设置一个5。也就是说,有5个库存是给冻结了。

此时订单状态为OrderStatus.DEALING。

接着进行支付操作。那么。为什么不直接进行支付,然后改为支付完成呢?因为存在支付失败甚至支付未知的风险,只要进行了支付操作,订单状态就不是初始化了。也就是说,不能直接把订单状态修改为已支付的确认状态!而是应当先把订单状态修改为DEALING,也就是处理中状态。该状态是个没有任何含义的中间状态,代表分布式事务正在进行中。

积分服务的增加积分接口也是同理,不能直接给用户增加会员积分。可以先在积分表里的一个预增加积分字段加入积分。

比如:用户积分原本是1000,现在要增加100个积分,可以保持积分为1000不变,在一个预增加字段里,设置一个100,表示有100个积分准备增加。

发货服务的发货接口也是同理,可以先创建一个发货订单,并设置这个销售出库单的状态是“DEALING”。

也就是说,刚刚创建这个发货订单,此时不能确定他的状态是什么。需要等真实发货之后再进行状态的修改。

这整个过程也就是所谓的TCC分布式事务中的TRY阶段。

简而言之,TRY阶段的业务的主流程以及各个接口提供的业务含义,不是直接完成那个业务操作,而是完成一个资源的预准备的操作,状态均为过渡态。

CONFIRM阶段

常见的TCC框架,如:ByteTCC、tcc-transaction 均为我们实现了事务管理器,用来执行CONFIRM阶段。他们能够对各个子模块的try阶段执行结果有所感知。

感知各个阶段的执行情况以及推进执行下一个阶段的操作较为复杂,不太可能自己手写实现,我们最好是借助开源框架实现。

为了实现这个阶段,我们需要加入CONFIRM操作相关的代码做事务的提交操作。

接着上述的情景来说:
  • 订单服务中的CONFIRM操作,是将订单状态更新为支付成功这样的确定状态。
  • 库存服务中,我们要加入正式扣除库存的操作,将临时冻结的库存真正的扣除,更新冻结字段为0,并修改库存字段为减去库存后的值。
  • 同时积分服务将积分变更为增加积分之后的值,修改预增加的值为0,积分值修改为原值+预增加的100分的和。
  • 发货服务也类似,真实发货后,修改DEALING为已发货。

当TCC框架感知到各个服务的TRY阶段都成功了以后,就会执行各个服务的CONFIRM逻辑。

各个模块内的TCC事务框架会负责跟其他服务内的TCC事务框架进行通信,依次调用各服务的CONFIRM逻辑。正式完成各服务的完整的业务逻辑的执行。

CANCEL阶段


CONFIRM是业务正常执行的阶段,那么异常分支自然交给CANCEL阶段执行了。

接着TRY阶段的业务情景来说。
  • 订单服务中,当支付失败,CANCEL操作需要更改订单状态为支付失败
  • 库存服务中的CANCEL操作要将预扣减的库存加回到原库存,也就是可用库存=90+10=100
  • 积分服务要将预增加的100个积分扣除
  • 发货服务的CANCEL操作将发货订单的状态修改为发货取消

当TCC框架感知到任何一个服务的TRY阶段执行失败,就会在和各服务内的TCC分布式事务框架进行通信的过程中,调用各个服务的CANCEL逻辑,将事务进行回滚。

思考

上述我们举的例子基本描述了一个TCC的执行过程,可以看出:
TCC分布式事务的核心思想,就是当系统出现异常时,比如某服务的数据库宕机了;某个服务自己挂了;系统使用的第三方服务如redis、elasticsearch、MQ等基础设施出现故障了或者某些资源不足了,比如说库存不够等等情况下,先执行TRY操作,而不是一次性把业务逻辑做完,进行预操作,看各个服务能不能基本正常运转,能不能预留出需要的资源。

如果TRY阶段均执行ok,即,数据库、redis、elasticsearch、MQ都是可以写入数据的,并且保留成功需要使用的一些资源(比如库存冻结成功、积分预添加完成)。

接着,再执行各个服务的CONFIRM逻辑,基本上CONFIRM执行完成之后就可以很大概率保证一个分布式事务的完成了。

那如果TRY阶段某个服务就执行失败了,比如说底层的数据库挂了,或者redis挂了,那么此时就自动执行各个服务的CANCEL逻辑,把之前的TRY逻辑都回滚,所有服务都不执行任何设计的业务逻辑。从而保证各个服务模块一起成功,或者一起失败。

到这里还是不能保证完全的事务一致性,试想,如果真的发生服务突发性宕机,比如订单服务挂了,那么重启之后,TCC框架如何保证之前的事务继续执行呢?

这个其实不必担心,成熟的TCC框架比如TCC-transaction中引入了事务的活动日志,它们保存了分布式事务运行的各个阶段的状态。后台会启动一个定时任务,周期性的扫描未执行完成的事务进行重试,保证最终一定会成功或失败。

这里也体现了TCC解决方案是一个保证最终一致性的柔性事务解决方案。

丨极客文库, 版权所有丨如未注明 , 均为原创丨
本网站采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行授权
转载请注明原文链接:我说分布式事务之TCC
喜欢 (0)
[247507792@qq.com]
分享 (0)
勤劳的小蚂蚁
关于作者:
温馨提示:本文来源于网络,转载文章皆标明了出处,如果您发现侵权文章,请及时向站长反馈删除。

您必须 登录 才能发表评论!

  • 精品技术教程
  • 编程资源分享
  • 问答交流社区
  • 极客文库知识库

客服QQ


QQ:2248886839


工作时间:09:00-23:00