今天就跟大家聊聊有关如何在springcloud中使用bytetcc实现数据的强一致性,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
1使用背景和约束
公司使用的是springcloud,面临分布式事务的场景的时候,可以使用对springcloud支持比较好的byte-tcc框架,git目前2600星,使用起来也非常方便,原理也很清晰,非常适合学习。https://github.com/liuyangmin..。,结合云有几个重点约束如下,
(1)一个业务接口,需要有三种实现类,分别是尝试,确认取消,符合苑的思路。实现方法必须加事务,且传播必须是必需的,RequiresNew,强制中的一种。
(2)服务提供方控制器必须添加@Compensable注解,不允许对假装/带/创建RestTemplate等HTTP请求自行进行封装。想想看为什么?
(3)在每个参与太极拳事务的数据库中创建bytejta表。
配置上也非常简单,@ import (SpringCloudConfiguration.class)服务提供方,尝试上面加上
确认和取消对应的
尝试确认取消对应业务可以理解为冻结库存/真正扣减库存/恢复库存,或者冻结优惠券/核销优惠券/恢复优惠券这种实际业务场景。
0.5以后数据源自动使用LocalXADataSource,之前需要手动配置
所以,从配置上看,bytetcc和springcloud结合,一个应该是通过引入自己的SpringCloudConfiguration封装了装/带/hystrix调用,一个是提供了自己的数据源管理事务。有了自己的数据源,定制自己的transactionManager,就可以在事务前后动手脚,2 pc/3 pc对事务的管理,体现在控制不同数据库连接上,微服务为主的太极拳,对事务的管理体现在控制各个服务的调用上。
2业务场景思考
bytetcc的太极拳,其实试和取消是配套的,考虑下业务场景:
(1)如果一服务试成功了,b服务尽失败,则一个服务需要回滚,调用的取消。这是普遍流程。
(2)如果a和b都试一试成功了,然后一个确认成功,b的确认失败,是没有取消和确认配对的。b的确认会不断调用直到成功为止。
因为bytetcc的设计思路是,通过试做好准备工作(如锁定资源),试着如果能成功,那么逻辑上确认一定要成功。如果确认不成功,则可能是外部环境问题,如网络问题等,那么环境恢复了迟早应该成功确认。基于这个思想,试着和取消是互逆的,确认一旦执行就不可逆。
如果要设计确认也可逆的,那要么取消里判断是该回滚还尝试是回滚尝试+确认,不清晰且实现很麻烦,或者做成“完成”加一个对应确认的取消,由事务管理器统一判断调用几个取消,引入太多不确定。所以业务上可以直接这么设计:试成功,那么确认是一定要成功的。
3核心组件SpringCloudConfiguration原理分析
第一步就进口的SpringCloudConfiguration是重点,通过它的各种自动装配基本可以实现bytetcc的全逻辑。要想扩展春天,那就得扩展各种BeanFactoryPostProcessor, SpringCloudConfiguration本身就是个BeanFactoryPostProcessor,但是postProcessBeanFactory没干啥,应该是引入了各种其他处理器进行扩展。如何扩展面临几个问题
(1)如何识别核心的@Compensable注解?
在byte-tcc的一堆资源文件里,配置了各种豆子。既然都springcloud了为啥还用这种文件bean可能是兼容云之外的场景,增强通用性。在bytetcc-supports-tcc。xml里,有个豆& lt; bean类=皁rg.bytesoft.bytetcc.supports.spring.CompensableAnnotationConfigValidator"/祝辞,通过关键代码
clazz.getAnnotation (Compensable.class);扫描得到所有注解了补偿的类,同时解析出来取消,确认对应的类。同时校验一下有没有加事务注解。后面很多类似的处理器都是用这种注解识别需要的bean
(2)如何改造事务管理器,使之适应分布式微服务环境?
在bytetcc-supports-tcc。xml中,定义了改造过的transactionManager,
