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

分布式事务之柔性事务TCC介绍

技术杂谈 勤劳的小蚂蚁 3个月前 (02-03) 82次浏览 已收录 0个评论 扫描二维码

近两年微服务变得越来越火热,各种框架与组件的出现,更是为微服务的开发提供了便利。
我们都知道,每个微服务都是一个对应的小服务,多个服务之间可以方便的进行功能的组合,来形成功能更强大的服务。服务间数据与部署都是独立的,这样故障也可以做到相互隔离。但是这也带来了分布式应用都会面对的问题:
如何保证多个服务间的事务?怎样才能使操作的原子性、一致性等得到保证?
对于传统的应用开发与部署,可以通过数据的事务来保证所谓的ACID,而微服务的场景下,数据库就力不从心了。
这个时候,2PC、3PC轮番登场,来解决这类的问题。但有些场景下,我们根据自己的真实需要,并不需要纯的2PC,比如你只关心数据的原子性与最终一致性,那2PC阶段的阻塞是你不能忍受的,那就有聪明的人想到了一种新的办法。就是我们今天要说的柔性事务TCC

什么是柔性事务TCC?

我们今天说的柔性事务,「柔」主要是相对于「传统」ACID的刚而言,柔性事务只需要遵循BASE原则。而TCC是柔性事务的一种实现。TCC是三个首字母,Try-Confirm-Cancel,具体描述是将整个操作分为上面这三步。两个微服务间同时进行Try,在Try的阶段会进行数据的校验,检查,资源的预创建,如果都成功就会分别进行Confirm,如果两者都成功则整个TCC事务完成。如果Confirm时有一个服务有问题,则会转向Cancel,相当于进行Confirm的逆向操作。

整个柔性事务有多种实现的思想,例如:

具体使用

之前的项目开发中,我们也有类似的场景需要保证两个微服务间的一致性,根据具体的场景需要,用到了TCC事务。当时是通过部门的一个基础组件,是通过异步补偿的形式来保证。
目前也有一些开源的TCC实现,可以直接在GitHub上获取到,例如下面这个https://github.com/changmingxie/tcc-transaction

基本实现原理

这些TCC的框架,基本都是通过「注解」的形式,在注解中声明Confirm方法Cancel方法,再通过AOP对带点该注解的方法统一进行拦截,之后根据结果分别再执行 Confirm 或者 Cancel。
代码类似这个样子:
@Compensable(confirmMethod = “confirmRecord”, cancelMethod = “cancelRecord”, transactionContextEditor = MethodTransactionContextEditor.class)
public String record(TransactionContext transactionContext, CapitalTradeOrderDto tradeOrderDto) {
confirm方法
public void confirmRecord(TransactionContext transactionContext, CapitalTradeOrderDto tradeOrderDto) {
cancel方法:
public void cancelRecord(TransactionContext transactionContext, RedPacketTradeOrderDto tradeOrderDto) {
基于类似的框架,可以比较方便的满足我们的业务使用场景。欢迎留言补充你在分布式的场景中是通过什么方式来保证一致性的。


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

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

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

客服QQ


QQ:2248886839


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