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

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

本地事务

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

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

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

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

上述案例中使用了@Transactional开启了本地事务，但是内部在插入数据时，Sharding-JDB会根据product_id这个分片键进行分库，那么这个业务方法肯定是跨了DB1、DB2这两个库，@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机制自定义扩展的分布式事务解决方案

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