Seata AT模式前后镜像是如何生成详解

这篇文章主要为大家介绍了Seata AT模式前后镜像是如何生成的方法详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪

前言

在Seata 官网中，我们可以知道AT模式一阶段的处理流程如下：

1.解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = 'TXC'）等相关的信息。

2.查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。

3.执行业务 SQL。

4.查询后镜像：根据前镜像的结果，通过主键定位数据。

5.插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中

......

前镜像的作用是保证在分布式事务失败时能够成功回滚的重要依据，后镜像是在回滚前校验是否脏写的数据依据，那么我们一阶段的前后镜像在真实的代码实现中是如何生成的呢？

前后镜像的生成

为了能够探寻到前后镜像的生成原理，我们需要看一看seata源码。最终我们把入口定位到AbstractDMLBaseExecutor.executeAutoCommitFalse()方法：

    protected T executeAutoCommitFalse(Object[] args) throws Exception { // 获取前镜像 TableRecords beforeImage = beforeImage(); // 执行业务SQL T result = statementCallback.execute(statementProxy.getTargetStatement(), args); // 获取后镜像 TableRecords afterImage = afterImage(beforeImage); // 存储前后镜像 prepareUndoLog(beforeImage, afterImage); return result; }

前镜像

继续深入探究一下到底是怎么获取beforeImage的，根据源码来看，我们发现beforeImage()方法有很多实现：

也就是说，Seata会根据不同的业务SQL来生成beforeImage，有点经验的小伙伴能够看出，这里其实使用到了模版模式加上策略模式，我们挑一个DeleteExecutor来看一下：

@Override protected TableRecords beforeImage() throws SQLException { SQLDeleteRecognizer visitor = (SQLDeleteRecognizer) sqlRecognizer; // 根据表名解析出元数据 TableMeta tmeta = getTableMeta(visitor.getTableName()); ArrayList> paramAppenderList = new ArrayList<>(); // 生成查询beforeImage的SQL语句 // SELECT [列名,] FROM [表名] (别名) (WHERE) (ORDER BY) (LIMIT) FOR UPDATE String selectSQL = buildBeforeImageSQL(visitor, tmeta, paramAppenderList); // 执行SQL查询beforeImage return buildTableRecords(tmeta, selectSQL, paramAppenderList); }

1.关键原理就是根据业务SQL反向查询出被影响的数据；

2.为了保证查询到的数据不是快照数据，一定要记得加上FOR UPDATE；

另外的话，我们发现其实UpdateExecutor的前镜像生成方式和DeleteExecutor也差不多，像普通的insert这种SQL的前镜像就更简单了：

    @Override protected TableRecords beforeImage() throws SQLException { return TableRecords.empty(getTableMeta()); }

因为普通insert语句不存在任何前镜像，所以直接返回空记录；

后镜像

我们再来看一下后镜像是如何生成的，这次我们看一下UpdateExecutor的后镜像生成方法afterImage():

@Override protected TableRecords afterImage(TableRecords beforeImage) throws SQLException { // 获取元数据 TableMeta tmeta = getTableMeta(); // 没有前镜像，也不存在后镜像，说明没有数据被修改 if (beforeImage == null || beforeImage.size() == 0) { return TableRecords.empty(getTableMeta()); } // 生成查询后镜像SQL // SELECT [列名,] FROM [表名] (别名) WHERE 主键 in (前镜像的主键值) // 这里面有一个配置项[client.undo.onlyCareUpdateColumns]，是否只关心被修改的列名，默认是true String selectSQL = buildAfterImageSQL(tmeta, beforeImage); ResultSet rs = null; try (PreparedStatement pst = statementProxy.getConnection().prepareStatement(selectSQL)) { SqlGenerateUtils.setParamForPk(beforeImage.pkRows(), getTableMeta().getPrimaryKeyOnlyName(), pst); // 执行查询后镜像 rs = pst.executeQuery(); // 包装查询结果 return TableRecords.buildRecords(tmeta, rs); } finally { IOUtil.close(rs); } }

后镜像的生成原理与前镜像的生成原理差不多，不过还是有一些小小的区别的：

1.后镜像的查询条件使用的是前镜像对应的主键值，就没有用业务SQL的查询条件；不同的Executor处理方式不同，需要根据具体的业务SQL来区分；

2.查询后镜像的SQL没有使用FOR UPDATE加锁，直接拿的快照数据；