基于Dubbo的分布式事务框架(LCN)

原文地址:http://原文地址:https://github.com/1991wangliang/transaction

该框架依赖Redis/dubbo/txManager服务。依赖第三方框架lorne_core

原理与功能

基于对spring tx PlatformTransactionManager的本地模块事务控制从而达到全局控制事务的目的。该框架兼容任何依赖PlatformTransactionManager的DB框架。利用三阶段提交的方式来确保事务的一致性,支持本地事务和分布式事务框架共存,当方法进入的是本地事务方法,框架将不做任何分布式事务处理。当需要用到分布式事务的时候只需要在方法上添加分布式事务的注解即可。框架由于基于Spring本地事务做的封装,基本支持依赖spring的所有db框架。并在帖子底部提供了对springjdbc/hibernate/mybatis的演示demo。

该框架在设计时就考虑到大型分布式的应用场景,因此框架支持对于dubbo单个模块的集群化。并且TxManager也支持集群化。

框架基于三阶段提交:

锁定事务单元

确认事务模块状态

通知事务

关于LCN框架的详细设计请见txManager说明

框架使用教程

需要先部署redis服务。

部署TxManager全局事务协调管理器。

本地项目依赖transaction库.

maven仓库地址

<repositories>

<repository>

<id>lorne</id>

<url>https://1991wangliang.github.io/repository</url>

</repository>

</repositories>

maven transaction 配置

<dependency>

<groupId>com.lorne.tx</groupId>

<artifactId>transaction</artifactId>

<version>1.0.0.RELEASE</version>

</dependency>

配置dubbo服务

<dubbo:application name="tx-transaction-test"   />

<!--所有参与分布式事务的模块以及TxManager都必须要在同一个服务下-->

<dubbo:registry protocol="zookeeper" address="127.0.0.1:2181" />

<!--依赖TxManager服务-->

<dubbo:reference timeout="3000" interface="com.lorne.tx.mq.service.MQTxManagerService" id="managerService" />

<dubbo:protocol accesslog="true" name="dubbo" port="20882" />

<!--所有需要分布式事务的模块也都必须对外提供服务-->

<!--1. 用户自定义的服务-->

<dubbo:service interface="com.demo.service.MQTestService" ref="testService"  />

<bean id="testService" class="com.demo.service.impl.MQTestServiceImpl"   />

<!--2. 当用户没有需要对外提供的服务时-->

<!--<dubbo:service interface="com.lorne.tx.mq.service.MQTransactionService" ref="transactionService"  />-->

<!--<bean id="transactionService" class="com.lorne.tx.mq.service.impl.MQTransactionServiceImpl"   />-->

若用户是自定义的服务,则服务必须要实现MQTransactionService接口如下:

public interface MQTestService extends MQTransactionService{

String test(String name);

}

MQTransactionService的实现:第一种方式

@Service

public class MQTestServiceImpl extends MQTransactionServiceImpl implements MQTestService {

@Override

public String test(String name) {

//todo 用户业务处理

return "";

}

}

MQTransactionService的实现:第二种方式

@Service

public class MQTestServiceImpl implements MQTestService {

@Autowired

private MQTransactionService transactionService;

@Override

public boolean notify(String kid, boolean state) {

return transactionService.notify(kid, state);

}

@Override

public boolean checkRollback(String kid) {

return transactionService.checkRollback(kid);

}

@Override

public String test(String name) {

//todo 用户业务处理

return "";

}

}

分布式事务的切面配置

<!--本地事务manager  -->

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

<property name="dataSource" ref="dataSource"/>

</bean>

<!--本地事务切面 -->

<tx:annotation-driven transaction-manager="transactionManager"/>

<!--切面 advice 定义-->

<tx:advice id="txAdvice">

<tx:attributes>

<tx:method name="get*" read-only="true"  />

<tx:method name="find*" read-only="true"/>

<tx:method name="load*" read-only="true"/>

<tx:method name="query*" read-only="true"/>

<tx:method name="select*" read-only="true"/>

<tx:method name="*" rollback-for="com.le.core.framework.exception.LEException"/>

</tx:attributes>

</tx:advice>

<!--分布式事务拦截器-->

<bean id="txTransactionInterceptor" class="com.lorne.tx.interceptor.TxManagerInterceptor"/>

<aop:config>

<aop:pointcut id="allManagerMethod" expression="execution(* com.**.service.impl.*Impl.*(..))"/>

<!--本地事务拦截-->

<aop:advisor  order="100" advice-ref="txAdvice" pointcut-ref="allManagerMethod"/>

<!--分布式事务拦截-->

<aop:advisor  order="10" advice-ref="txTransactionInterceptor" pointcut-ref="allManagerMethod"/>

</aop:config>

分布式事务注解(@TxTransaction)

@Override

@TxTransaction

public String test() {

//todo 业务处理

return "";

}

关于@TxTransaction的补充说明: 当添加事务注解时方法将开启分布式事务处理方式。当尽当开始方法是分布式事务方法时才进入分布式事务处理逻辑。 若存在业务方法A调用了业务方法B,当分布式事务注解添加在A上,那么整个A方法将被分布式事务所管理,若注解添加在B上,当调用A时将不会被启用分布式事务,尽当业务启动时的方法添加分布式事务注解时方可开启分布式事务注解。

演示demo:

spring-jdbc版本: transaction_demo1 transaction_demo2

transaction_demo1是发起方,transaction_demo2是被调用方。

hibernate版本:

transaction_hibernate_demo1 transaction_hibernate_demo2

transaction_hibernate_demo1是发起方,transaction_hibernate_demo2是被调用方。

mybatis版本:

transaction_mybatis_demo1 transaction_mybatis_demo2

transaction_mybatis_demo1是发起方,transaction_mybatis_demo2是被调用方。

参考更多免费教程请加入Dubbo技术交流:548209960

Java高并发高可用架构:632103578

时间: 2024-10-12 03:23:54

基于Dubbo的分布式事务框架(LCN)的相关文章

tcc分布式事务框架解析

前言碎语 楼主之前推荐过2pc的分布式事务框架LCN.今天来详细聊聊TCC事务协议. 2pc实现:https://github.com/codingapi/tx-lcn tcc实现:https://github.com/yu199195/hmily 首先我们了解下什么是tcc,如下图 tcc分布式事务协议控制整体业务事务分为三个阶段. try:执行业务逻辑 confirm:确定业务逻辑执行无误后,确定业务逻辑执行完成 cancel:假如try阶段有问题,执行cancel阶段逻辑,取消try阶段的

如何实现一个TCC分布式事务框架的一点思考

一个TCC事务框架需要解决的当然是分布式事务的管理.关于TCC事务机制的介绍,可以参考TCC事务机制简介.http://www.bytesoft.org/tcc-intro TCC事务模型虽然说起来简单,然而要基于TCC实现一个通用的分布式事务框架,却比它看上去要复杂的多,不只是简单的调用一下Confirm/Cancel业务就可以了的. 本文将以Spring容器为例,试图分析一下,实现一个通用的TCC分布式事务框架需要注意的一些问题. 一.TCC全局事务必须基于RM本地事务来实现全局事务 TCC

基于dubbo的分布式项目实例应用(一)

本文主要学习dubbo服务的启动检查.集群容错.服务均衡.线程模型.直连提供者.只定阅.只注册等知识点,希望通过实例演示进一步理解和掌握这些知识点. 启动检查 Dubbo缺省会在启动消费者时检查依赖的服务是否可用,不可用时会抛出异常,阻止Spring初始化完成,以便上线时,能及早发现问题,默认check=true. 关闭没有提供者时报错 <dubbo:reference interface="com.mcweb.api.service.IUserService" id="

谈谈分布式事务之二:基于DTC的分布式事务管理模型[下篇]

[续上篇] 当基于LTM或者KTM的事务提升到基于DTC的分布式事务后,DTC成为了本机所有事务型资源管理器的管理者:此外,当一个事务型操作超出了本机的范 围,出现了跨机器的调用后,本机的DTC需要于被调用者所在机器的DTC进行协助.上级对下级(包括本机DTC对本机所有资源管理器,以及上下级DTC) 的管理得前提是下级在上级那里登记,即事务登记(Transaction Enlist).所有事务参与者,包括所有资源管理器和事务管理器(即DTC)在进行了事务等级完成之后形成了一个树形的层级结构,该结

Percolator:基于BigTable的分布式事务实现

Google为了解决网页索引的增量处理,以及维护数据表和索引表的一致性问题,基于BigTable实现了一个支持分布式事务的存储系统.这里重点讨论这个系统的分布式事务实现,不讨论percolator中为了支持增量计算而实现的Notifications机制. 该系统基于BigTable,支持snapshot isolation隔离级别,这个隔离级别不在ANSI定义的隔离级别范围内.简单来说,就是一个事务看到的是一个stable的数据库的快照.快照隔离相对于可串行化隔离级别的优点是更高的读性能,不需要

构建基于RocketMQ的分布式事务服务

说在前面 Apache RocketMQ-4.3.0正式Release了事务消息的特性,顺着最近的这个热点.第一篇文章,就来聊一下在软件工程学上的长久的难题--分布式事务(Distributed Transaction). 这个技术也在各个诸如阿里,腾讯等大厂的内部,被广泛地实现,利用及优化.但是由于理论上就有难点,所以分布式事务就隐晦得成了大厂对于小厂的技术壁垒.相信来看这篇文章的同学,一定都听过很多关于分布式事务的术语,比较二阶段提交,TCC,最终一致性等,所以这里也不多普及概念. 基于Ro

分布式事务框架-seata初识

摘自:https://www.cnblogs.com/iceggboom/p/12144570.html 分布式事务框架-seata初识 一.事务与分布式事务 事务,在数据库中指的是操作数据库的最小单位,往大了看,事务是应用程序中一系列严密的操作,所有操作必须成功完成,否则在每个操作中所作的所有更改都会被撤消. 那为什么会有分布式事务呢?单机事务是通过将操作限制在一个会话内通过数据库本身的锁以及日志来实现ACID.因为引入了分布式架构,所以事务的参与者.支持事务的服务器.资源服务器以及事务管理器

Dubbo[一个分布式服务框架

http://alibaba.github.io/dubbo-doc-static/User+Guide-zh.htm#UserGuide-zh-API%E9%85%8D%E7%BD%AE http://alibaba.github.io/dubbo-doc-static/Home-zh.htm Dubbo是什么? Dubbo[]是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案. 其核心部分包含: 远程通讯: 提供对多种基于长连接的NIO框架抽象封装

spring boot 分布式事务解决方案LCN

对比LCN和saga(华为apache孵化器项目) ,LCN使用代理连接池封装补偿方法,saga需要手工写补偿方法,相对来说LCN使用更加方便. 参考官方地址: https://github.com/codingapi/tx-lcn/wiki/TxManager%E5%90%AF%E5%8A%A8%E8%AF%B4%E6%98%8E 1.    原理 1.     事务控制原理 LCN事务控制原理是由事务模块TxClient下的代理连接池与TxManager的协调配合完成的事务协调控制. TxC