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

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

什么是柔性事务TCC?

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

整个柔性事务有多种实现的思想,例如:
分布式事务之柔性事务TCC介绍

具体使用

之前的项目开发中,我们也有类似的场景需要保证两个微服务间的一致性,根据具体的场景需要,用到了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) {
基于类似的框架,可以比较方便的满足我们的业务使用场景。欢迎留言补充你在分布式的场景中是通过什么方式来保证一致性的。
分布式事务之柔性事务TCC介绍

本站所有文章均来自互联网,如有侵权,请联系站长删除。极客文库 » 分布式事务之柔性事务TCC介绍
分享到:
赞(0)

评论抢沙发

评论前必须登录!