"LCN并不生产事务,LCN只是本地事务的搬运工"
LCN分布式事务框架是一款事务协调性的框架,框架本身并不创建事务,只是对本地事务做协调控制。因此该框架与其他第三方的框架兼容性强,支持所有的关系型数据库事务,支持多数据源,支持与第三方数据库框架一块使用(例如 sharding-jdbc),在使用框架的时候只需要添加分布式事务的注解即可,对业务的侵入性低。LCN框架主要是为微服务框架提供分布式事务的支持,在微服务框架上做了进一步的事务机制优化,在一些负载场景上LCN事务机制要比本地事务机制的性能更好,4.0以后框架开方了插件机制可以让更多的第三方框架支持进来。
transaction-dubbo LCN dubbo rpc框架扩展支持
transaction-springcloud LCN springcloud rpc框架扩展支持
transaction-motan LCN motan rpc框架扩展支持
tx-client 是LCN核心tx模块端控制框架
tx-manager 是LCN 分布式事务协调器
tx-plugins-db 是LCN 对关系型数据库的插件支持
tx-plugins-nodb 是LCN 对于无数据库模块的插件支持
tx-plugins-redis 是LCN 对于redis模块的插件支持(功能暂未实现)
分布式事务发起方:
@Override
@TxTransaction
@Transactional
public boolean hello() {
//本地调用
testDao.save();
//远程调用方
boolean res = test2Service.test();
//模拟异常
int v = 100/0;
return true;
}
分布式事务被调用方(test2Service的业务实现类)
@Override
@Transactional
public boolean test() {
//本地调用
testDao.save();
return true;
}
如上代码执行完成以后两个模块都将回滚事务。
说明:在使用LCN分布式事务时,只需要将事务的开始方法添加@TxTransaction
注解即可。详细见demo教程
@TxTransaction注解是分布式事务的标示。
若存在业务方法:a->b b->c b->d,那么开启分布式事务注解的话,只需要在a方法上添加@TxTransaction即可。
@TxTransaction
@Transactional
public void a(){
b();
}
public void b(){
c();
d();
}
public void c(){}
public void d(){}
com.codingapi
tx-client
${lcn.last.version}
com.codingapi
tx-plugins-db
${lcn.last.version}
com.codingapi
tx-plugins-nodb
${lcn.last.version}
com.codingapi
transaction-dubbo
${lcn.last.version}
com.codingapi
transaction-motan
${lcn.last.version}
com.codingapi
transaction-springcloud
${lcn.last.version}
依赖gradle等形式,见中心库
http://mvnrepository.com/search?q=codingapi
每个demo下有区分为 jdbc/hibernate/mybatis不同框架的版本demo
技术交流群:554855843
一、环境搭建(搭建TxManager) (1)导入依赖 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.3.12.RELEASE</version> </parent> <dependency
TX-LCN 主要有两个模块: Tx-Client(TC):每个微服务都可以是一个TC,只需引入TC的依赖 Tx-Manager(TM):TM是独立的微服务,注册到注册中心 搭建步骤: 一 Tx-Manager服务搭建 创建MySQL数据库, 名称为: tx-manager CREATE DATABASE IF NOT EXISTS `tx-manager` DEFAULT CHARSET
TX-LCN和Seata两种分布式事务各有优点。LCN是采取代理数据源的模式,再根据发起方执行本地事务的结果进行回滚和提交。可以保证强一致性,但可能发生死锁的现象。Seata采取的是根据undo_log日志表,进行逆向生成sql语句,来解决回滚。Seata能保证最终一致性,但可能造成脏读。其实所有的分布式事务方案都不完美。一致性、可用性、分区容忍性,只能同时满足两个。
主要内容:1.2PC,2.三阶段提交(3PC),3.补偿事务(TCC),4.本地消息表,5.消息事务,6.最大努力通知,7.Sagas 事务模型1.2PC 两阶段提交 mysql是通过日志系统完成事务的。就是两阶段提交:undolog和binlog的两阶段提交。 两阶段协议可以用于单机集中式系统,由事务管理器协调多个资源管理器;也可以用于分布式系统,由一个全局的事务管理器协调各个子系统的局部事务管理器完成两阶段提交。 第一阶段:投票阶段 1.协调者写命令进写入日志 2.协调者发一个prepare
ShardingSphereTransactionManager SPI 名称 详细说明 ShardingSphereTransactionManager 分布式事务管理器 已知实现类 详细说明 XAShardingSphereTransactionManager 基于 XA 的分布式事务管理器 SeataATShardingSphereTransactionManager 基于 Seata 的分
ShardingSphere-Proxy 接入的分布式事务 API 同 ShardingSphere-JDBC 保持一致,支持 LOCAL,XA,BASE 类型的事务。 XA 事务 ShardingSphere-Proxy 原生支持 XA 事务,默认的事务管理器为 Atomikos。 可以通过在 ShardingSphere-Proxy 的 conf 目录中添加 jta.properties 来定
通过 Apache ShardingSphere 使用分布式事务,与本地事务并无区别。 除了透明化分布式事务的使用之外,Apache ShardingSphere 还能够在每次数据库访问时切换分布式事务类型。 支持的事务类型包括 本地事务、XA事务 和 柔性事务。可在创建数据库连接之前设置,缺省为 Apache ShardingSphere 启动时的默认事务类型。
背景 数据库事务需要满足 ACID(原子性、一致性、隔离性、持久性)四个特性。 原子性(Atomicity)指事务作为整体来执行,要么全部执行,要么全不执行。 一致性(Consistency)指事务应确保数据从一个一致的状态转变为另一个一致的状态。 隔离性(Isolation)指多个事务并发执行时,一个事务的执行不应影响其他事务的执行。 持久性(Durability)指已提交的事务修改数据会被持久
单文档原子性可满足大多数业务需求 在 MongoDB 中,对单个文档的操作是原子操作。 由于 MongoDB 文档数据模型,一个文档中通过嵌入式的文档和数组来表示传统关系数据库模型中的一对一、一对多关系,而不是通过文档之间的复杂关系来描述业务需求中的一对一、一对多关系。 所以单文档原子性可以满足实际生产中大多数关于事务的需求。 对于需要对多个文档(在单个或多个集合中)进行原子读写的情况,Mongo
两阶段提交协议 通常在复杂场景下是不推荐使用的,除非是非常简单的场景,非常容易提供回滚,而且依赖的服务也非常少的情况。 这种实现方式会造成代码量庞大,耦合性高。而且非常有局限性,因为有很多的业务是无法很简单的实现回滚的,如果串行的服务很多,回滚的成本实在太高。 本地消息表 这种实现方式的思路,其实是源于ebay,后来通过支付宝等公司的布道,在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一
分布式事务基于 JTA/XA 规范实现 1。 两阶段提交: 1. 本功能暂未实现 ↩