读完这一篇,我不信你还不懂分布式事务TCC

码农在囧途

你现在的苦闷、内心斗争、理想与现实的差距,我都知道,但是我没有办法替你承担,这些都需要你自己去慢慢体会、琢磨、看开、悟透,总结,然后继续向前!

前言

前面我们说了两期分布式事务模型,分别是2PC和3PC,2PC模型它的效率比较低,并且会出现事务阻塞等问题,所以引入了3PC模型, 3PC模型在2PC模型的基础上进行了改进,避免了事务阻塞问题,不过对于2PC和3PC模型,他们依然是阻塞的,也就是说当前事务在 执行的过程中,其他事务都会被阻塞,所以实际上他们的效率都不高,如果对于并发量不发的系统,那么可以选择它们,但是在高并发的 场景下,用2PC模型和3PC模型,显然就不行了,所以今天我们引入了TCC模型。

TCC解释

前面的2PC,3PC属于强一致性分布式事务,TCC属于最终一致性分布式事务,T是Try,第一个C是Confirm,第二个C是Concel,这三个过程都需要工程师自己去编码,所以TCC对业务的入侵很大,它的作用就是帮我们协调,但实际逻辑需要 我们自己去编码,但是TCC的效率比较高,不存在事务阻塞,高并发场景下比较适合。

深入分析

我们用一个下单过程来说明TCC的工作机制,正常的下单会包含创建订单,扣减库存,扣减账户余额,增加积分等功能,所以会调用这些子系统, 有的系统使用http进行远程调用,有的使用rpc进行调用,我们这个例子中有五个微服务,分别为业务微服务(BusinessMicroservice),库存微服务(StockMicroservice),订单微服务(OrderMicroservice),积分微服务(IntegralMicroservice),账户微服务(AccountMicroservice),在业务微服务中通过rpc统一调用其他微服务。

使用TCC就需要设计三部分的业务代码,分别是Try阶段,Confirm阶段,Concel阶段。

Try

从字面意思我们看出Try是尝试的意思,这个阶段其实就是对资源进行预留,需要工程师自己去设计,在Try阶段代码设计的好坏,在很大程度上影响 整个分布式事务的结果,所以对工程师的设计能力和思考能力有一定的考验。

预扣减库存

这一步并没有真正地扣减库存,所以叫做预扣减库存,首先先检查库存是否被扣减,比如我下单量为2,此时库存为1,那么显然不能扣减,如果库存为 10,那么证明可以扣减,但是此时并不会真正地扣减库存,我们需要对其进行一些设计,这需要根据自己的业务场景去设计,比如可以新建一个冻结库存 的表,因为下单量为2,库存为10,所以此时执行10-2,库存为8,我们就将库存更新为8,然后在库存冻结表中插入一条扣减记录,记录是某个用户的下单数量, ,那么扣减库存这一步就完成了。

预创建订单

预创建订单也不是真正地创建订单,我们可以将订单的状态改为创建中,这个状态值只是用来表示订单的状态,这个状态并非真实订单的状态,而是为了使用 分布式事务而使用的状态,并不是商品生命周期中的属性。

预增加积分

这里也不是真正地增加积分,我们可以在积分记录中添加一个冻结积分字段,例如,积分余额为100,需要增加的积分20,那么此时积分余额值就变为120(100+20), 冻结积分为20。

预扣减余额

扣减余额我们在账户表中添加一个冻结字段,例如,如果账户余额为1000,本次需要扣减200,那么此时余额就变为800(1000-200), 冻结金额为200。

到这里,Try阶段我们就说完了,我们发现,在Try阶段我们做的事就是在预留资源。

Confirm

如果Try阶段所有的业务都成功地执行完毕,没有出现错误,那么在Confirm阶段就会执行所有分支事务,这个阶段唯一做的就是提交事务(完成我们自己定义的逻辑), 不会再去校验数据,比如库存是否充足等,因为第一阶段已经检验过并且通过了。

扣减库存

因为库存表中在Try阶段已经减过库存,只是扣减记录保存在了库存冻结表,所以这一步就需要删除冻结表的记录,通过用户Id去删除。

设置订单状态为已创建

Try阶段将订单状态设置为创建中,到了这里就需要将订单状态设置为已创建,代表订单事务已经完成。

增加积分

这里的增加积分在Try阶段其实已经做了,只是预留了一个冻结积分,所以这里就需要更新冻结积分,将其更新为0,代表增加积分这个事务已经完成。

扣减余额

这里的扣减余额在Try阶段已经做了,只是预留了一个冻结金额,所以这里就需要更新冻结金额,将其更新为0,代表扣减余额事务已经完成。

到这里TCC的Confirm就完成了,Confirm阶段唯一做的事情就是执行任务,不做任何的数据校验。

Cancel

上面的Confirm阶段是Try阶段所有的操作都正常,没有出错,如果有一种的一个操作出现异常或资源出错,那么就会进入Cancel阶段,Cancel阶段会对Try阶段的所有操作进行回滚,也就是将数据恢复到刚开始的时候。

恢复库存

恢复库存就是查询库存冻结表中的冻结库存,然后加上库存表中库存(库存表库存 = 库存表库存 + 冻结库存), 8 + 2 = 10 , 然后删除冻结库存记录, 代表事务回滚成功。

设置订单状态为取消

Try阶段订单状态为创建中,那么因为在Try阶段某个分支事务出错,所以需要将订单状态置为已取消(这个状态并不是订单生命周期中的状态), 而是为事务设计的状态,代表事务回滚成功。

恢复积分

用冻结积分加上积分余额(积分余额 = 积分余额 + 冻结积分),然后更新到积分余额上,随后将冻结积分更新为0,代表事务回滚成功。

恢复余额

用冻结余额加上余额(余额 = 余额+ 冻结余额),更新到余额上面,将冻结余额更新为0,代表事务回滚成功。

Cancel阶段就完成了,Cancel阶段主要是对各个事务进行恢复,他是基于Try阶段的数据进行恢复。

总结

完成了TCC的分析,我们可以看出TCC事务之间并没有阻塞,但是事务的成败很大一部分是掌握在开发人员的手上,因为它不像2PC模式的 框架完全是由框架来帮我们完成事务的提交和回滚,在TCC模式中,事务的提交回滚都是要由我们去编写业务代码来实现,TCC帮我们做的是对任务 的调度,感知分支事务是否正常,再根据结果进行提交或者回滚,所以,我们编写代码的好坏直接影响到TCC事务是否成功。

从上面的例子中,我们其实不难看出,TCC事务并不能完全保证事务的一致性,在Try阶段,如果所有分支都正常,那么其实在Confirm阶段 基本上都能成功,如果Try阶段失败,那么在Cancel阶段其实也基本能成功,如果在Confirm阶段和Cancel没成功,那么TCC框架就会重试, 或者需要人工进行处理,所以数据的一致性并不能完全得到保障。

今天的分享就到这里,感谢你的观看,我们下期再见。

你可能感兴趣的:(读完这一篇,我不信你还不懂分布式事务TCC)