@Transactional 竟也能解决分布式事务?

简介: @Transactional 竟也能解决分布式事务?

这篇文章就以球友的提问来聊一下Sharding-JDBC中的本地事务

本地事务

Sharding-JDBC中的本地事务可能会让大家有一个误解,还是以商品表为例:将商品表根据商品ID进行水平分库,分为两个库,如下:

分库的配置这里就不贴了,详情看源码

此时向其中批量插入数据,伪代码如下:

@Transactional
public int insertBatch(){
    for(int i=0;i<10;i++){
        insert(product);
        .......
    }
}

上述案例中使用了@Transactional开启了本地事务,但是内部在插入数据时,Sharding-JDB会根据product_id这个分片键进行分库,那么这个业务方法肯定是跨了DB1DB2这两个库,@Transactional这个注解能解决吗?

假象:手动在内部模拟抛出异常,还真的是都rollback

此时很多人都迷糊了,Sharding-JDBC中的本地事务真的是可以保证分布式事务?

真实结论:Sharding-JDBC中的本地事务无法保证分布式事务

Sharding-JDBC中的本地事务在以下两种情况是完全支持的

  1. 支持非跨库事务,比如仅分表、在单库中操作
  2. 支持因逻辑异常导致的跨库事务,比如上述的操作,跨两个库插入数据,插入完成后抛出异常

本地事务不支持的情况

  1. 不支持因网络硬件异常导致的跨库事务;例如:同一事务中,跨两个库更新,更新完毕后、未提交之前,第一个库宕机,则只有第二个库数据提交

对于因网络、硬件异常导致的跨库事务无法支持很好理解,在分布式事务中无论是两阶段还是三阶段提交都是直接或者间接满足以下两个条件:

  1. 有一个事务协调者
  2. 事务日志记录

本地事务并未满足上述条件,自然是无法支持

为什么逻辑异常导致的跨库事务能够支持?

Spring的本地事务大家都很了解,也经常用,并不支持的跨库事务,那么为什么Sharding-JDBC中却能支持呢?

想要了解其中的猫腻必然需要从Sharding-JDBC的源码入手,下图是在Sharding-JDBC一条SQL处理的流程:

Sharding-JDBC中的一条SQL会经过改写,拆分成不同数据源的SQL,比如一条select语句,会按照其中分片键拆分成对应数据源的SQL,然后在不同数据源中的执行,最终会提交或者回滚

想要解释上述的问题,只需要看ShardingConnection,这是Sharding-JDBC自定义实现的,继承关系如下图:

可以看到ShardingConnection继承了java.sql.Connection,这个类就不必多解释了,在学习JDBC的时候应该都有所接触,直接和数据库打交道的一个类。

想要知道为什么支持跨库事务的回滚,肯定要找到其中的rollback方法,如下:

@Override
public void rollback() throws SQLException {
    //① 本地事务
 f (TransactionType.LOCAL == transactionType) {
     super.rollback();
    } else {
       //② 非本地事务
     shardingTransactionManager.rollback();
    }
}

rollback的方法中区分了本地事务分布式事务,如果是本地事务将调用父类的rollback方法,如下:

//父类:AbstractConnectionAdapter#rollback
@Override
public void rollback() throws SQLException {
    //cachedConnections中存储了数据源,这里是ds1/ds2
    forceExecuteTemplate.execute(cachedConnections.values(), Connection::rollback);
}

这里是调用ForceExecuteTemplate#execute()方法执行,其实内部就是遍历数据源去执行对应的rollback方法,如下:

public void execute(final Collection<T> targets, final ForceExecuteCallback<T> callback) throws SQLException {
        Collection<SQLException> exceptions = new LinkedList<>();
        for (T each : targets) {
            try {
                callback.execute(each);
            } catch (final SQLException ex) {
                exceptions.add(ex);
            }
        }
        throwSQLExceptionIfNecessary(exceptions);
    }

看到这里已经很明了了,rollback 在各个数据源中回滚且未记录任何事务日志,因此在非硬件、网络的情况下都是可以正常回滚的,一旦因为网络、硬件故障,可能导致某个数据源rollback失败,这样即使程序恢复了正常,也无undo日志继续进行rollback,因此这里就造成了数据不一致了。

总结

仅仅依靠Spring自带的本地事务(@Transactional)是无法保证跨库的分布式事务,不要被Sharding-JDBC的假象迷惑了。

当然Sharding-JDBC对于跨库事务也是有一定的支持,大致分成三类:

  • 强一致性的XA协议事务
  • 基于Base的柔性事务
  • 通过SPI机制自定义扩展的分布式事务解决方案

本文只是抛砖引玉简单的介绍下分库分表后的事务处理,后文会针对以上三类方案详细介绍一下。

相关文章
|
6月前
|
Java 编译器 数据库
@Transactional中指定rollbackFor,弊端以及不能回滚的时候
@Transactional中指定rollbackFor,弊端以及不能回滚的时候
190 3
|
6月前
|
消息中间件 Java 关系型数据库
Spring事务与分布式事务
这篇文档介绍了事务的概念和数据库事务的ACID特性:原子性、一致性、隔离性和持久性。在并发环境下,事务可能出现更新丢失、脏读和不可重复读等问题,这些问题通过设置事务隔离级别(如读未提交、读已提交、可重复读和序列化)来解决。Spring事务传播行为有七种模式,影响嵌套事务的执行方式。`@Transactional`注解用于管理事务,其属性包括传播行为、隔离级别、超时和只读等。最后提到了分布式事务,分为跨库和跨服务两种情况,跨服务的分布式事务通常通过最终一致性策略,如消息队列实现。
71 0
|
Java 关系型数据库 MySQL
Spring的事务传播行为有哪些呢?Spring事务的隔离级别?讲下嵌套事务?
Spring的事务传播行为有哪些呢?Spring事务的隔离级别?讲下嵌套事务?
115 1
|
数据库
Seata中的四种不同的事务模式之一 TCC
TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过人工编码来实现数据恢复。
151 0
|
消息中间件 存储 关系型数据库
一个注解搞定分布式事务
一个注解搞定分布式事务
|
缓存 NoSQL Java
Spring事务解读,一文让你彻底了解事务
Spring事务解读,一文让你彻底了解事务
285 0
|
缓存 Java 数据库连接
Spring源码剖析之Transactional事务
我们知道使用@Transactional,要满足以下条件 1、配置数据源 DataSource 2、配置事务管理器 PlatformTransactionManager 3、配置类上标识 @EnableTransactionManagement
185 0
分布式事务Seata【四】事务补偿(TCC)
常见的分布式事务解决方案有 TCC、全局消息、基于可靠消息服务的分布式事务、最大努力通知等
1006 1
分布式事务Seata【四】事务补偿(TCC)
|
SQL Java 关系型数据库
分布式事务之数据库事务与JDBC事务实现(一)
分布式事务之数据库事务与JDBC事务实现
分布式事务之数据库事务与JDBC事务实现(一)
|
开发框架 Oracle Java
分布式事务之JTA原理与实现(三)
分布式事务之JTA原理与实现
1015 0
分布式事务之JTA原理与实现(三)