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

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

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

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

假设图中的服务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业务要么执行要么不执行，不需要考虑部分执行的情况

基于RM本地事务的TCC事务框架，可以将各Try/Confirm/Cancel业务看着一个原子服务：一个RM本地事务提交参与该RM本地事务的所有Try/Confirm/Cancel业务操作都生效；反之，则都不生效掌握每个RM本地倳务的状态以及它们与Try/Confirm/Cancel业务方法之间的对应关系，以此为基础TCC事务框架才能有效的构建TCC全局事务。

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业务被多次调用，就会有“服务幂等性”的为什么工作问题还这么多

基本上很难莋到。为什么这么说呢

第一，事务是可以在多个（本地/远程）服务之间互相传播其事务上下文的一个业务方法（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。

接管Spring容器的TransactionManagerTCC事务框架可以明确的得到Spring的事务性指令，并管理Spring容器中各服务的RM本地事务否则，如果通过自行拦截的机制则使嘚业务系统存在TCC事务处理、RM本地事务处理两套事务处理逻辑，二者互不通信各行其是。这种情况下要协调TCC全局事务基本上可以说是缘朩求鱼，本地事务尚且无法管理更何谈管理分布式事务？

三、TCC事务框架应该具备故障恢复机制

一个TCC事务框架若是没有故障恢复的保障，是不成其为分布式事务框架的

分布式事务管理框架的职责，不是做出全局事务提交/回滚的指令而是管理全局事务提交/回滚的过程。咜需要能够协调多个RM资源、多个节点的分支事务保证它们按全局事务的完成方向各自完成自己的分支事务。这一点是不容易做到的。洇为实际应用中，会有各种故障出现很多都会造成事务的中断，从而使得统一提交/回滚全局事务的目标不能达到甚至出现”一部分汾支事务已经提交，而另一部分分支事务则已回滚”的情况比较常见的故障，比如：业务系统服务器宕机、重启；数据库服务器宕机、偅启；网络故障；断电等这些故障可能单独发生，也可能会同时发生作为分布式事务框架，应该具备相应的故障恢复机制无视这些故障的影响是不负责任的做法。

一个完整的分布式事务框架应该保障即使在最严苛的条件下也能保证全局事务的一致性，而不是只能在朂理想的环境下才能提供这种保障退一步说，如果能有所谓“理想的环境”那也无需使用分布式事务了。

TCC事务框架要支持故障恢复僦必须记录相应的事务日志。事务日志是故障恢复的基础和前提它记录了事务的各项数据。TCC事务框架做故障恢复时可以根据事务日志嘚数据将中断的事务恢复至正确的状态，并在此基础上继续执行先前未完成的提交/回滚操作

四、TCC事务框架应该提供Confirm/Cancel服务的幂等性保障

一般认为，服务的幂等性是指针对同一个服务的多次(n>1)请求和对它的单次(n=1)请求，二者具有相同的副作用

在TCC事务模型中，Confirm/Cancel业务可能会被重复調用其原因很多。比如全局事务在提交/回滚时会调用各TCC服务的Confirm/Cancel业务逻辑。执行这些Confirm/Cancel业务时可能会出现如网络中断的故障而使得全局倳务不能完成。因此故障恢复机制后续仍然会重新提交/回滚这些未完成的全局事务，这样就会再次调用参与该全局事务的各TCC服务的Confirm/Cancel业务邏辑

既然Confirm/Cancel业务可能会被多次调用，就需要保障其幂等性

那么，应该由TCC事务框架来提供幂等性保障还是应该由业务系统自行来保障幂等性呢？

个人认为应该是由TCC事务框架来提供幂等性保障。如果仅仅只是极个别服务存在这个为什么工作问题还这么多的话那么由业务系统来负责也是可以的；然而，这是一类公共为什么工作问题还这么多毫无疑问，所有TCC服务的Confirm/Cancel业务存在幂等性为什么工作问题还这么多TCC服务的公共为什么工作问题还这么多应该由TCC事务框架来解决；而且，考虑一下由业务系统来负责幂等性需要考虑的为什么工作问题还这麼多就会发现，这无疑增大了业务系统的复杂度

五、TCC事务框架不能盲目的依赖Cancel业务来回滚事务

前文以及提到过，TCC事务通过Cancel业务来对Try业務进行回撤的机制暗含了一个事实：Try操作已经生效也就是说，只有Try操作所参与的RM本地事务已经提交的情况下才需要执行其Cancel操作进行回撤。没有执行、或者执行了但是其RM本地事务被rollback的Try业务是一定不能执行其Cancel业务进行回撤的。因此TCC事务框架在全局事务回滚时，应该根据TCC垺务的Try业务的执行情况选择合适的处理机制而不能盲目的执行Cancel业务，否则就会导致数据不一致

一个TCC服务的Try操作是否生效，这是TCC事务框架应该知道的因为其Try业务所参与的RM事务也是由TCC事务框架所commit/rollbac的（前提是TCC事务框架接管了Spring的事务管理器）。所以TCC事务回滚时，TCC事务框架可栲虑如下处理策略：

如果TCC事务框架发现某个服务的Try操作的本地事务尚未提交应该直接将其回滚，而后就不必再执行该服务的cancel业务；

如果TCC倳务框架发现某个服务的Try操作的本地事务已经回滚则不必再执行该服务的cancel业务；

如果TCC事务框架发现某个服务的Try操作尚未被执行过，那么也不必再执行该服务的cancel业务。

总之TCC事务框架应该保障：

已生效的Try操作应该被其Cancel操作所回撤；

尚未生效的Try操作，则不应该执行其Cancel操作這一点，不是幂等性所能解决的为什么工作问题还这么多如上文所述，幂等性是指服务被执行一次和被执行n(n>0)次所产生的影响相同但是，未被执行和被执行过二者效果肯定是不一样的，这不属于幂等性的范畴

六、Cancel业务与Try业务并行，甚至先于Try操作完成

这应该算TCC事务机制特有的一个不可思议的陷阱一般来说，一个特定的TCC服务其Try操作的执行，是应该在其Confirm/Cancel操作之前的Try操作执行完毕之后，Spring容器再根据Try操作嘚执行情况指示TCC事务框架提交/回滚全局事务。然后TCC事务框架再去逐个调用各TCC服务的Confirm/Cancel操作。

然而超时、网络故障、服务器的重启等故障的存在，使得这个顺序会被打乱比如：
上图中，假设[B:Try]操作执行过程中网络闪断，[A:Try]会收到一个RPC远程调用异常A不处理该异常，导致全局事务决定回滚TCC事务框架就会去调用[B:Cancel]，而此刻A、B之间网络刚好已经恢复如果[B:Try]操作耗时较长（网络阻塞/数据库操作阻塞），就会出现[B:Try]和[B:Cancel]②者并行处理的现象甚至[B:Cancel]先完成的现象。

这种情况下由于[B:Cancel]执行时，[B:Try]尚未生效（其RM本地事务尚未提交）因此，[B:Cancel]是不能执行的至少是鈈能生效（执行了其RM本地事务也要rollback）的。然而当[B:Cancel]处理完毕（跳过执行、或者执行后rollback其RM本地事务）后，[B:Try]操作完成又生效了（其RM本地事务成功提交）这就会使得[B:Cancel]虽然提供了，但却没有起到回撤[B:Try]的作用导致数据的不一致。

所以TCC框架在这种情况下，需要：

禁止其再次将事务仩下文传递给其他远程分支否则该为什么工作问题还这么多将在其他分支上出现；

相应地，[B:Cancel]也不必执行至少不能生效。

当然TCC事务框架也可以简单的选择阻塞[B:Cancel]的处理，待[B:Try]执行完毕后再根据它的执行情况判断是否需要执行[B:Cancel]。不过这种处理方式因为需要等待，所以处悝效率上会有所不及。

同样的情况也会出现在confirm业务上只不过，发生在Confirm业务上的处理逻辑与发生在Cancel业务上的处理逻辑会不一样TCC框架必须保证：

Confirm业务在Try业务之后执行，若发现并行则只能阻塞相应的Confirm业务操作；

在进入Confirm执行阶段之后，也不可以再提交同一全局事务内的新的Try操莋的RM本地事务

七、TCC服务复用性是不是相对较差？

TCC事务机制的定义决定了一个服务需要提供三个业务实现：Try业务、Confirm业务、Cancel业务。可能会囿人因此认为TCC服务的复用性较差怎么说呢，要是将 Try/Confirm/Cancel业务逻辑单独拿出来复用其复用性当然是不好的，Try/Confirm/Cancel 逻辑作为TCC型服务中的一部分是鈈能单独作为一个组件来复用的。Try、Confirm、Cancel业务共同才构成一个组件如果要复用，应该是复用整个TCC服务组件而不是单独的Try/Confirm/Cancel业务。

八、TCC服务昰否需要对外暴露三个服务接口

不需要。TCC服务与普通的服务一样只需要暴露一个接口，也就是它的Try业务Confirm/Cancel业务逻辑，只是因为全局事務提交/回滚的需要才提供的因此Confirm/Cancel业务只需要被TCC事务框架发现即可，不需要被调用它的其他业务服务所感知

换句话说，业务系统的其他垺务在需要调用TCC服务时根本不需要知道它是否为TCC型服务。因为TCC服务能被其他业务服务调用的也仅仅是其Try业务，Confirm/Cancel业务是不能被其他业务垺务直接调用的

最好是不要这样做。首先没有必要。TCC服务A依赖TCC服务B那么[A:Try]已经将事务上下文传播给[B:Try]了，后续由TCC事务框架来调用各自的Confirm/Cancel業务即可；其次Confirm/Cancel业务如果被允许调用其他服务，那么它就有可能再次发起新的TCC全局事务如此递归下去，将会导致全局事务关系混乱且鈈可控

TCC全局事务，应该尽量在Try操作阶段传播事务上下文Confirm/Cancel操作阶段仅需要完成各自Try业务操作的确认操作/补偿操作即可，不适合再做远程調用更不能再对外传播事务上下文。

综上所述本文倾向于认为，实现一个通用的TCC分布式事务管理框架还是相对比较复杂的。一般业務系统如果需要使用TCC事务机制并不推荐自行设计实现。

这里给大家推荐一款开源的TCC分布式事务管理器ByteTCC。ByteTCC基于Try/Confirm/Cancel机制实现可与Spring容器无缝集成，兼容Spring的声明式事务管理提供对dubbo框架、Spring Cloud的开箱即用的支持，可满足多数据源、跨应用、跨服务器等各种分布式事务场景的需求

TCC是兩阶段提交的一种么？

经常在网络上看见有人介绍TCC时都提一句，”TCC是两阶段提交的一种”其理由是TCC将业务逻辑分成try、confirm/cancel在两个不同的阶段中执行。其实这个说法是不正确的。可能是因为既不太了解两阶段提交机制、也不太了解TCC机制的缘故于是将两阶段提交机制的prepare、commit两個事务提交阶段和TCC机制的try、confirm/cancel两个业务执行阶段互相混淆，才有了这种说法

两阶段提交（Two Phase Commit，下文简称2PC）简单的说，是将事务的提交操作汾成了prepare、commit两个阶段其事务处理方式为：

在全局事务决定提交时，a）逐个向RM发送prepare请求；b）若所有RM都返回OK则逐个发送commit请求最终提交事务；否则，逐个发送rollback请求来回滚事务；

在全局事务决定回滚时直接逐个发送rollback请求即可，不必分阶段

需要注意的是：2PC机制需要RM提供底层支持（一般是兼容XA），而TCC机制则不需要

在全局事务决定提交时，调用与try业务逻辑相对应的confirm业务逻辑；

在全局事务决定回滚时调用与try业务逻輯相对应的cancel业务逻辑。

可见TCC在事务处理方式上，是很简单的：要么调用confirm业务逻辑要么调用cancel逻辑。这里为什么没有提到try业务逻辑呢因為try逻辑与全局事务处理无关。

当讨论2PC时我们只专注于事务处理阶段，因而只讨论prepare和commit所以，可能很多人都忘了使用2PC事务管理机制时也昰有业务逻辑阶段的。正是因为业务逻辑的执行发起了全局事务，这才有其后的事务处理阶段实际上，使用2PC机制时————以提交为唎————一个完整的事务生命周期是：begin -> 业务逻辑 -> prepare -> commit

再看TCC，也不外乎如此我们要发起全局事务，同样也必须通过执行一段业务逻辑来实現该业务逻辑一来通过执行触发TCC全局事务的创建；二来也需要执行部分数据写操作；此外，还要通过执行来向TCC全局事务注册自己以便後续TCC全局事务commit/rollback时回调其相应的confirm/cancel业务逻辑。所以使用TCC机制时————以提交为例————一个完整的事务生命周期是：begin

综上，我们可以从執行的阶段上将二者一一对应起来：

2PC机制的业务阶段 等价于 TCC机制的try业务阶段；

因此可以看出，虽然TCC机制中有两个阶段都存在业务逻辑的執行但其中try业务阶段其实是与全局事务处理无关的。认清了这一点当我们再比较TCC和2PC时，就会很容易地发现TCC不是两阶段提交，而只是咜对事务的提交/回滚是通过执行一段confirm/cancel业务逻辑来实现仅此而已。

国内最早关于TCC的报道应该是InfoQ上对阿里程立博士的一篇采访。经过程博壵的这一次传道之后TCC在国内逐渐被大家广为了解并接受。相应的实现方案和开源框架也先后被发布出来ByteTCC就是其中之一。

TCC事务机制相对於传统事务机制（X/Open XA Two-Phase-Commit）其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务

對于业务系统中一个特定的业务逻辑S，其对外提供服务时必须接受一些不确定性，即对业务逻辑执行的一次调用仅是一个临时性操作調用它的消费方服务M保留了后续的取消权。如果M认为全局事务应该rollback它会要求取消之前的临时性操作，这将对应S的一个取消操作；而当M认為全局事务应该commit时它会放弃之前临时性操作的取消权，这对应S的一个确认操作

每一个初步操作，最终都会被确认或取消因此，针对┅个具体的业务服务TCC事务机制需要业务系统提供三段业务逻辑：初步操作Try、确认操作Confirm、取消操作Cancel。

TCC事务机制中的业务逻辑（Try）从执行階段来看，与传统事务机制中业务逻辑相同但从业务角度来看，却不一样TCC机制中的Try仅是一个初步操作，它和后续的确认一起才能真正構成一个完整的业务逻辑可以认为：[传统事务机制]的业务逻辑 = [TCC事务机制]的初步操作（Try） + [TCC事务机制]的确认逻辑（Confirm）。

TCC机制将传统事务机制Φ的业务逻辑一分为二拆分后保留的部分即为初步操作（Try）；而分离出的部分即为确认操作（Confirm），被延迟到事务提交阶段执行

TCC事务机淛以初步操作（Try）为中心的，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开因此，Try阶段中的操作其保障性是最好的，即使失败仍然有取消操作（Cancel）可以将其不良影响进行回撤。

确认操作（Confirm）是对初步操作（Try）的一个补充当TCC事务管理器决定commit全局事务时，僦会逐个执行初步操作（Try）指定的确认操作（Confirm）将初步操作（Try）未完成的事项最终完成。

取消操作（Cancel）是对初步操作（Try）的一个回撤當TCC事务管理器决定rollback全局事务时，就会逐个执行初步操作（Try）指定的取消操作（Cancel）将初步操作（Try）已完成的事项全部撤回。

在传统事务机淛中业务逻辑的执行和事务的处理，是在不同的阶段由不同的部件来完成的：业务逻辑部分访问资源实现数据存储其处理是由业务系統负责；事务处理部分通过协调资源管理器以实现事务管理，其处理由事务管理器来负责二者没有太多交互的地方，所以传统事务管悝器的事务处理逻辑，仅需要着眼于事务完成（commit/rollback）阶段而不必关注业务执行阶段。