看图秒懂tcc分布式事务

来理解下什么是tcc分布式事务！

下面我们来简单看一个微服务分布式事务的场景！来看图

图中有用户系统！积分系统！资金系统！三个微服务也就是三个小系统！每个系统对应自己的一个数据库，场景是这样的！用户注册。会在用户系统去生成一条用户的纪录。然后在积分系统开通用户的积分纪录！然后会在资金系统去开通用户的资金账户！用户注册的逻辑就是完成这三步操作！用户注册横跨了三个小系统！而且用户注册必须要有事务的保证！也就是说这三步操作其中任何一步操作失败！其它操作都必须回滚！比如说生成用户纪录成功！但生成积分纪录失败！生成成功的用户纪录必须回滚！

 

传统的单点项目是将生成用户纪录生成积分纪录、生成资金账户逻辑都写到一个方法里面！单点项目要实现注册用户的事务很简单。只要在这个方法上面加上个@transaction注解就可以了！开发环境中我们的数据库事物是交给spring框架去处理的。但我们当前的这个场景是横跨了三个系统，三个数据库！！三个jvm!!!!spring也只能回滚当前环境下的jvm应用！说白了spring主能处理同一个数据库的事务！如何实现这个多系统、多数据库之间的事务一致性呢！这就需要我们的分布式事务解决方案来处理了！分布式事务的实现方案方案有几种！目前性能最高的，使用最多的还是tcc 二阶段提交方案！这个也是我们开发人员可控性最高的！后续的章节我们会对cc分布式式调度引擎底层的源码实现做一个深入的分析！

下面我们来了解下什么是tcc 

tcc是分布式事物的一种实现

从字面上的意义主要包含三个方面,try,confirm,cancel

try和confirm称之为两阶段提交

cancel是代码回滚

======2:怎么理解两阶段提交和代码回滚，下面我们去和传统数据库

事物作个对比，就能很清晰易懂了。。

下面大家来看一份demo

这份demo主要功能是使用jdbc往数据库插入数据

开启了手动提交事物

执行了三条insert dml语句

最后提交整个事

如果有catch到异常。回滚整个事物

其实传统数据库事物就存两阶段提交

大家看！！

执行这三条dml语句 其实就一阶段提交。。就是这三个insert

等于我们tcc里面的try..

commit其实就是二阶段提交。等于我们tcc的confirm

这三dml语句的执行就属于一阶段提交,也就等于我们的try阶段,

因为我们开启了手动事物

数据还没有真正提交到数据库。(其实底层是有提交到数据库里去，只是给这些数据加了锁，select查不出这种数据，)

commit  真正提交到数据中去 二阶段提交。 也就是对应的confirm阶段。

rollback等于tcc的cancel

tcc其实就是在模拟数据库事物这一块。。

只不过不同的是，传统数据库事物的两阶段提交和回滚是通过数据内部实现的

而我们的tcc的两阶段提交和回滚是通过代码去做的。

简单来理解tcc其实就是把数据库事物这一块搬到应用层上去。也就是代码层面

====3传统数据库事物和tcc的相同点和不同点。

第一点前面有提到过数据库事物的2阶段提交，回滚是通过数据内部去实现的

，而tcc则是通过设计tcc接口来实现两阶段提交和回滚操作

第二点。传统数据库事物只能操纵当前数据库的事物。不能跨库操作

这句话大家应该能理解吧？

我这个connection只对应一个库。只能提交回滚当前数据库的事物。

保障不了跨库跨应用事物一致性问题。

不能操纵其它的库

但是tcc能作跨库，跨应用的事物提交回滚。保障跨库跨应用的事物一致性问题

更多tcc分布式事务知识www.java52.com