高手通用分布式事务框架！

一个TCC事务框架需要解决的当然是分布式事务的管理。关于TCC事务机制的介绍，可以参考TCC事务机制简介。

TCC

事务模型虽然说起来简单，然而要基于TCC实现一个通用的分布式事务框架，却比它看上去要复杂的多，不只是简单的调用一下Confirm/Cancel业务就可以了的。

本文将以Spring容器为例，试图分析一下，实现一个通用的TCC分布式事务框架需要注意的一些问题。

一、TCC全局事务必须基于RM本地事务来实现

TCC服务是由Try/Confirm/Cancel业务构成的，其Try/Confirm/Cancel业务在执行时，会访问资源管理器（Resource

Manager，下文简称RM）来存取数据。

这些存取操作，必须要参与RM本地事务，以使其更改的数据要么都commit，要么都rollback。

这一点不难理解，考虑一下如下场景：

假设图中的服务B没有基于RM本地事务（以RDBS为例，可通过设置auto-commit为true来模拟），那么一旦[B:Try]操作中途执行失败，TCC事务框架后续决定回滚全局事务时，该[B:Cancel]则需要判断[B:Try]中哪些操作已经写到DB、哪些操作还没有写到DB.

假设[B:Try]业务有5个写库操作，[B:Cancel]业务则需要逐个判断这5个操作是否生效，并将生效的操作执行反向操作。不幸的是，由于[B:Cancel]业务也有n（0<=n<=5）个反向的写库操作，此时一旦[B:Cancel]也中途出错，则后续的[B:Cancel]执行任务更加繁重。

因为相比第一次[B:Cancel]操作，后续的[B:Cancel]操作还需要判断先前的[B:Cancel]操作的n（0<=n<=5）个写库中哪几个已经执行、哪几个还没有执行.

这就涉及到了幂等性问题，而对幂等性的保障，又很可能还需要涉及额外的写库操作，该写库操作又会因为没有RM本地事务的支持而存在类似问题。。。

可想而知，如果不基于RM本地事务，TCC事务框架是无法有效的管理TCC全局事务的。

反之，基于RM本地事务的TCC事务，这种情况则会很容易处理。

[B:Try]操作中途执行失败，TCC事务框架将其参与RM本地事务直接rollback即可。后续TCC事务框架决定回滚全局事务时，在知道“[B:Try]操作涉及的RM本地事务已经rollback”的情况下，根本无需执行[B:Cancel]操作。

换句话说，基于RM本地事务实现TCC事务框架时，一个TCC型服务的cancel业务要么执行，要么不执行，不需要考虑部分执行的情况。

二、TCC事务框架应该接管Spring容器的TransactionManager

基于RM本地事务的TCC事务框架，可以将各Try/Confirm/Cancel业务看成一个原子服务：一个RM本地事务提交，参与该RM本地事务的所有Try/Confirm/Cancel业务操作都生效；反之，则都不生效。

掌握每个RM本地事务的状态以及它们与Try/Confirm/Cancel业务方法之间的对应关系，以此为基础，TCC事务框架才能有效的构建TCC全局事务。

TCC服务的Try/Confirm/Cancel业务方法在RM上的数据存取操作，其RM本地事务是由Spring容器的PlatformTransactionManager来commit/rollback的，TCC事务框架想要了解RM本地事务的状态，只能通过接管Spring的事务管理器功能。

2.1. 为什么TCC事务框架需要掌握RM本地事务的状态？首先，根据TCC机制的定义，TCC事务是通过执行Cancel业务来达到回滚效果的。仔细分析一下，这里暗含一个事实：只有生效的Try业务操作才需要执行对应的Cancel业务操作。

换句话说，只有Try业务操作所参与的RM本地事务被commit了，后续TCC全局事务回滚时才需要执行其对应的Cancel业务操作

否则，如果Try业务操作所参与的RM本地事务被rollback了，后续TCC全局事务回滚时就不能执行其Cancel业务，此时若盲目执行Cancel业务反而会导致数据不一致。

其次，Confirm/Cancel业务操作必须保证生效。Confirm/Cancel业务操作也会涉及RM数据存取操作，其参与的RM本地事务也必须被commit。

TCC事务框架需要在确切的知道所有Confirm/Cancel业务操作参与的RM本地事务都被成功commit后，才能将标记该TCC全局事务为完成。

如果TCC事务框架误判了Confirm/Cancel业务参与RM本地事务的状态，就会造成全局事务不一致。

最后，未完成的TCC全局，TCC事务框架必须重新尝试提交/回滚操作。重试时会再次调用各TCC服务的Confirm/Cancel业务操作。

如果某个服务的Confirm/Cancel业务之前已经生效（其参与的RM本地事务已经提交），重试时就不应该再次被调用。否则，其Confirm/Cancel业务被多次调用，就会有“服务幂等性”的问题。

2.2. 拦截TCC服务的Try/Confirm/Cancel业务方法的执行，根据其异常信息可否知道其RM本地事务是否commit/rollback了呢？

基本上很难做到，为什么这么说？

第一，事务是可以在多个（本地/远程）服务之间互相传播其事务上下文的，一个业务方法（Try/Confirm/Cancel）执行完毕并不一定会触发当前事务的commit/rollback操作。

比如，被传播事务上下文的业务方法，在它开始执行时，容器并不会为其创建新的事务，而是它的调用方参与的事务，使得二者操作在同一个事务中；同样，在它执行完毕时，容器也不会提交/回滚它参与的事务的。

因此，这类业务方法上的异常情况并不能反映他们是否生效。不接管Spring的TransactionManager，就无法了解事务于何时被创建，也无法了解它于何时被提交/回滚。

第二、一个业务方法可能会包含多个RM本地事务的情况。

比如：A(REQUIRED)->B(REQUIRES_NEW)->C(REQUIRED)，这种情况下，A服务所参与的RM本地事务被提交时，B服务和C服务参与的RM本地事务则可能会被回滚。

第三、并不是抛出了异常的业务方法，其参与的事务就回滚了。

Spring容器的声明式事务定义了两类异常，其事务完成方向都不一样：系统异常（一般为Unchecked异常，默认事务完成方向是rollback）、应用异常（一般为Checked异常，默认事务完成方向是commit）。

二者的事务完成方向又可以通过@Transactional配置显式的指定，如rollbackFor/noRollbackFor等。第四、Spring容器还支持使用setRollbackOnly的方式显式的控制事务完成方向；

最后，自行拦截业务方法的拦截器和Spring的事务处理的拦截器还会存在执行先后、拦截范围不同等问题。

例如，如果自行拦截器执行在前，就会出现业务方法虽然已经执行完毕但此时其参与的RM本地事务还没有commit/rollback。

TCC事务框架的定位应该是一个TransactionManager，其职责是负责commit/rollback事务。

而一个事务应该commit、还是rollback，则应该是由Spring容器来决定的：

Spring决定提交事务时，会调用TransactionManager来完成commit操作；Spring决定回滚事务时，会调用TransactionManager来完成rollback操作。

接管Spring容器的TransactionManager，TCC事务框架可以明确的得到Spring的事务性指令，并管理Spring容器中各服务的RM本地事务。

否则，如果通过自行拦截的机制，则使得业务系统存在TCC事务处理、RM本地事务处理两套事务处理逻辑，二者互不通信，各行其是。

这种情况下要协调TCC全局事务，基本上可以说是缘木求鱼，本地事务尚且无法管理，更何谈管理分布式事务？

小编分类整理了许多java进阶学习材料和BAT面试题，需要资料的请加QQ群：731611386 就能领取2019年java进阶学习资料和BAT面试题以及《EffectiveJava》（第3版）电子版书籍。