分布式事务(2）---TCC原理

分布式事务(2)---TCC原理

上篇讲过有关2PC和3PC理论知识，博客：分布式事务(1)---2PC和3PC理论

个人理解：2PC、3PC还有TCC都蛮类似的。3PC大体是把2PC的第一阶段拆分红了两个阶段，而TCC我感受是把2PC的第二阶段拆分红了两个阶段。

1、概念

一、概念

TCC又称补偿事务。其核心思想是："针对每一个操做都要注册一个与其对应的确认和补偿（撤销操做）"。它分为三个操做：

一、Try阶段：主要是对业务系统作检测及资源预留。
二、Confirm阶段：确认执行业务操做。
三、Cancel阶段：取消执行业务操做。

TCC对应 Try、Confirm、Cancel 三种操做能够理解成关系型数据库事务的三种操做：DML、Commit、Rollback。

在一个跨应用的业务操做中

Try：Try操做是先把多个应用中的业务资源预留和锁定住，为后续的确认打下基础，相似的，DML操做要锁定数据库记录行，持有数据库资源。

Confirm：Confirm操做是在Try操做中涉及的全部应用均成功以后进行确认，使用预留的业务资源，和Commit相似；

Cancel：Cancel则是当Try操做中涉及的全部应用没有所有成功，须要将已成功的应用进行取消(即Rollback回滚)。其中Confirm和Cancel操做是一对反向业务操做。

TCC的具体原理图如（盗图）:

从图中咱们能够明显看到Confirm和Cancel操做是一对反向业务操做 即要try返回成功执行Confirm,要么try返回失败执行Cancel操做。

分布式事务协调者：分布式事务协调者管理控制整个业务活动，包括记录维护TCC全局事务的事务状态和每一个从业务服务的子事务状态，并在业务活动提交时确认全部的TCC型

操做的confirm操做，在业务活动取消时调用全部TCC型操做的cancel操做。

二、举例

例子：A服务转30块钱、B服务转50块钱，一块儿到C服务上。

Try：尝试执行业务。完成全部业务检查(一致性)：检查A、B、C的账户状态是否正常，账户A的余额是否很多于30元，账户B的余额是否很多于50元。预留必须业务资源

(准隔离性)：账户A的冻结金额增长30元，账户B的冻结金额增长50元，这样就保证不会出现其余并发进程扣减了这两个账户的余额而致使在后续的真正转账操做过程当中，

账户A和B的可用余额不够的状况。

Confirm：确认执行业务。真正执行业务：若是Try阶段账户A、B、C状态正常，且账户A、B余额够用，则执行账户A给帐户C转帐30元、账户B给帐户C转帐50元的转账

操做。 这时已经不须要作任何业务检查，Try阶段已经完成了业务检查。只使用Try阶段预留的业务资源：只须要使用Try阶段账户A和账户B冻结的金额便可。

Cancel：取消执行业务释放Try阶段预留的业务资源：若是Try阶段部分红功，好比账户A的余额够用，且冻结相应金额成功，账户B的余额不够而冻结失败，则须要

对账户A作Cancel操做，将账户A被冻结的金额解冻掉。

三、TCC和2PC比较

2PC是资源层面的分布式事务，强一致性，在两阶段提交的整个过程当中，一直会持有资源的锁。

XA事务中的两阶段提交内部过程是对开发者屏蔽的，事务管理器在两阶段提交过程当中，从prepare到commit/rollback过程当中，资源实际上一直都是被加锁的。

若是有其余人须要更新这两条记录，那么就必须等待锁释放。

TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

个人理解就是当执行try接口的时候，已经把所需的资源给预扣了，好比上面举例的A服务已经预扣30元，B服务已经预扣50元，它是由try接口实现，这样就保证不会

出现其余并发进程扣减了这两个账户的余额而致使在后续的真正转账操做过程当中，账户A和B的可用余额不够的状况，同时保证不会一直锁住整个资源。（核心点应该就在这）

TCC中的两阶段提交并无对开发者彻底屏蔽，也就是说从代码层面，开发者是能够感觉到两阶段提交的存在。

一、try过程的本地事务，是保证资源预留的业务逻辑的正确性。

二、confirm/cancel执行的本地事务逻辑确认/取消预留资源，以保证最终一致性，也就是所谓的补偿型事务。

因为是多个独立的本地事务，所以不会对资源一直加锁。

总的来说

TCC 实质上是应用层的2PC()，比如把 XA 两阶段提交那种在数据资源层作的事务管理工做提到了数据应用层。

2PC是资源层面的分布式事务，是强一致性，在两阶段提交的整个过程当中，*一直会持有资源的锁*。

TCC是业务层面的分布式事务，最终一致性，*不会一直持有资源的锁*。

TCC相比较于2PC来说性能会好不少，可是由于同时须要改造try、confirm、canel3个接口，开发成本高。

注意 还有一点须要注意的是Confirm和Cancel操做可能被重复调用，故要求Confirm和Cancel两个接口必须是幂等。

参考

分布式事务（一）原理概览

分布式事务之说说TCC事务

分布式事务：深刻理解什么是2PC、3PC及TCC协议

柔性事务 ：TCC两阶段补偿型

只要本身变优秀了，其余的事情才会跟着好起来（上将6）