什么是 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分布式事务?

补充说明:

文中图片来源于「支付宝架构与技术」文档,感兴趣的朋友可以自行搜索获取该文件。


原文发布时间为:2018-09-7

本文作者:xxx

本文来自云栖社区合作伙伴“程序员小灰”,了解相关信息可以关注“程序员小灰”。

上一篇:我的Android进阶之旅------>Android实现用Android手机控制PC端的关机和重启的功能(一)PC服务器端


下一篇:什么是分布式事务? | 带你读《Spring Cloud Alibaba(2019)》之十八