阿里开源分布式事务组件 seata : AT 模式的分支事务处理

AT 模式与 TCC 模式

seata 的事务处理模式主要分为两种，分别是 AT 模式和 TCC 模式，其实在早期的 seata 版本里(还叫 fescar 的时候)，它把模式分为：AT 模式，MT 模式和混合模式。
那时还未深入了解 seata 时，对这样的分类模式感到有点奇怪，咱也不知道，更是不敢问。
不过现在这种只分为 AT 模式 和 TCC 模式的分类方法，我觉得是更合理的。
在王者荣耀这款游戏里，我听说过“万物皆可打野”，“万物皆可百穿”。
在算法的世界里，我听说过“万物皆可动态规划”。
在分布式事务的处理里，我觉得“万物皆可 TCC”。
seata 的 AT 模式主要是针对全局事务只涉及到数据库数据的场景，实际上 seata 的 AT 模式也是一种 TCC 模式，只不过，CC 阶段是程序自动完成的，不需要业务开发人员去关心如何去 Confirm，如何去 Cancel。在 AT 模式中，Try 阶段实际上已经完成本地事务的提交，而 Confirm 阶段则是删除 Undo log，Cancel 阶段则是利用 undo log，做数据的回放。
使用 seata 的朋友，如果 seata 给你一种分布式事务的接入很简单的感觉，你还是要记得你是在使用 TCC 模式。

AT 模式原理

seata 的 AT 模式，采用的是大量运用在数据库软件的 Write Ahead Log 思想，即把事务的信息以事务日志的方式记录下来。
这种处理方式，实际上是对传统两阶段提交的一种改进和优化，在《浅析阿里分布式事务组件 fescar/seata 2pc 的设计思想》 这篇文章我也简单的分析了一下。主要有几个关键点：

1. 传统两阶段提交协议是阻塞协议，性能差
2. 传统两阶段提交协议高可用性不好
3. 传统两阶段提交协议的全局事务隔离机制不支持
4. 根据八二原则，80% 的涉及到全局事务的业务是能正常完成并提交的。

因此，在 AT 模式下，seata 采取的做法是，一个事务分支的数据库操作执行完后，马上进行本地事务的提交，从而释放相关的数据库资源。

本地事务执行流程

不过，进行本地提交的前提是，seata 会解析 SQL，获取数据库表的元数据，根绝 SQL 类型，选择性地生成数据的前置镜像和后置镜像，保存在 undo_log 表中，并且要求与保存 undo_log 与业务 SQL 在同一个本地事务内。这就保证了：

1. 如果一个本地事务被提交，那么必定对应着相应的 undo_log
2. 如果保存 undo_log 保存失败，那么业务 SQL 也会失败

全局事务提交流程

因为每个分支事务的本地事务都已经被提交，所以如果全局事务能够顺利进行到“提交“这一阶段，那么意味着所有事务分支的本地事务都已经被提交了，数据的一致性已经得到了保证。这个时候全局事务的提交就变得十分轻量级，就是把 undo_log 对应的记录删掉即可，即使是当时删除失败了，也已经不会影响全局事务的最终结果，这次删不了，那就待会再删，程序删不了，没事，顶多人工删。

全局事务回滚流程

如果全局事务的任何一个事务分支失败了，那么全局事务就进入“回滚“流程，回滚时依据先前保存好数据镜像，将原来的数据回放回去。如果全局回放成功，那么数据的一致性也就得到了保证，如果回放不成功，那么事务就进入异常。应对异常，可能需要重试，可能需要人工介入。

数据源代理机制

虽然执行一个正常的业务 SQL ，需要附带解析 SQL，生成镜像等等这些操作，不过应用层编程时却不需要自己去实现这些细节。
这些细节 seata 已经自动帮你做好了。应用层看似简单的一个 JDBC 操作，实际上 seata 已经通过代理的方式在这个操作的前前后后加上了这些逻辑，seata 主要是通过代理模式来实现的。
在前面的文章《阿里开源分布式事务组件 seata ：demo 环境搭建以及运行流程简析》 中的 demo 里我们提到了 spring 的配置文件里对于数据源的配置方式，如下所示：

实际上，spring 的 jdbc template 的入参是一个由 seata 实现的 DataSource 的 Proxy，在 JDBC 的 API 设计中，Connection 通过 DataSource 获得，Statement 或者 PreparedStatement 则通过 Connection 获得。
seata 代理了 DataSource，相当于控制了源头，既然从源头代理了 DataSource，那么我也同样可以代理你的 Connection，同样可以代理你的 Statement 或者 PreparedStatement。(万物皆可代理......)
当应用层代码拿到一个普通的 JDBC Connection，进行着天真无邪的数据库操作时，其实这个 Connection 是个 proxy，而且由 Connection 生成的 Statement 或者 PreparedStatement，都是 proxy。如下图所示：

镜像生成机制

Template 模式

普通 SQL 执行时，织入的逻辑主要 StatementProxy 和 PreparedStatementProxy 里实现。当使用 StatementProxy 执行 executeUpdate 方法时：

@Override
public int executeUpdate(String sql) throws SQLException {
    this.targetSQL = sql;
    return ExecuteTemplate.execute(this, new StatementCallback() {
        @Override
        public Integer execute(Statement statement, Object... args) throws SQLException {
            return statement.executeUpdate((String) args[0]);
        }
    }, sql);
}

这里使用 ExecuteTemplate 类去做主要的逻辑，这里其实也是一个 Template 模式的运用，seata 的很多地方都用了这种方式，在前面《阿里开源分布式事务组件 seata ：demo 环境搭建以及运行流程简析》 这篇文章中，我们就提到过一个 TransactionTemplate 的事务执行模板，通常这种机制运用在个性化的业务逻辑需要运行在固定的执行顺序中的时候。我们看一下 ExecuteTemplate 的 execute 方法是一个怎样的模板：

/**
 * Execute t.
 *
 * @param                the type parameter
 * @param                the type parameter
 * @param sqlRecognizer     the sql recognizer
 * @param statementProxy    the statement proxy
 * @param statementCallback the statement callback
 * @param args              the args
 * @return the t
 * @throws SQLException the sql exception
 */
public static  T execute(SQLRecognizer sqlRecognizer,
                                                 StatementProxy statementProxy,
                                                 StatementCallback statementCallback,
                                                 Object... args) throws SQLException {

    if (!RootContext.inGlobalTransaction() && !RootContext.requireGlobalLock()) {
        // Just work as original statement
        return statementCallback.execute(statementProxy.getTargetStatement(), args);
    }

    if (sqlRecognizer == null) {
        sqlRecognizer = SQLVisitorFactory.get(
                statementProxy.getTargetSQL(),
                statementProxy.getConnectionProxy().getDbType());
    }
    Executor executor = null;
    if (sqlRecognizer == null) {
        executor = new PlainExecutor(statementProxy, statementCallback);
    } else {
        switch (sqlRecognizer.getSQLType()) {
            case INSERT:
                executor = new InsertExecutor(statementProxy, statementCallback, sqlRecognizer);
                break;
            case UPDATE:
                executor = new UpdateExecutor(statementProxy, statementCallback, sqlRecognizer);
                break;
            case DELETE:
                executor = new DeleteExecutor(statementProxy, statementCallback, sqlRecognizer);
                break;
            case SELECT_FOR_UPDATE:
                executor = new SelectForUpdateExecutor(statementProxy, statementCallback, sqlRecognizer);
                break;
            default:
                executor = new PlainExecutor(statementProxy, statementCallback);
                break;
        }
    }
    T rs = null;
    try {
        rs = executor.execute(args);
    } catch (Throwable ex) {
        if (!(ex instanceof SQLException)) {
            // Turn other exception into SQLException
            ex = new SQLException(ex);
        }
        throw (SQLException)ex;
    }
    return rs;
}

通过这个方法，我们可以看到一个语句的执行模板大致是怎样的：

1. 如果当前不处于分布式事务的上下文中，那么使用原来的 Statement 执行
2. 解析 sql，并结合数据库的类型，指派对应类型的执行器，例如对于 insert 语句，它就指派 InsertExecutor 来执行
3. 使用对应的执行器，执行相应的 sql

SQL 解析器

不同的 SQL 类型，会使用不同类型的 SQL 执行器来执行，这需要在执行器执行之前，先对 SQL 进行解析，得到 SQL 的元信息，例如类型、表名、where 条件，涉及到的列等等，这些信息由 SQLRecognizer 来表示。

public interface SQLRecognizer {

    /**
     * Type of the SQL. INSERT/UPDATE/DELETE ...
     *
     * @return sql type
     */
    SQLType getSQLType();

    /**
     * 获取表的别名
     */
    String getTableAlias();

    String getTableName();

    String getOriginalSQL();
}

但是这个接口定义的 API 得到的信息都较为基础，只是 SQL 类型，表名，表别名以及原 SQL 而已。实际上在应对不同类型的 SQL 时，需要获取的关于 SQL 的信息都不太一样，更具体更复杂的功能，其实是在具体实现的 XXXRecognizer 中。

seata 的 SQL 解析器采用的是它们自家的 druid，druid 的核心功能是一个数据库连接池，但伴随着它 druid 也自带了标准的 SQL 解析器，支持多种 SQL 方言。并且 druid 的 SQL 解析器模块相对比较独立，基本上可以单独拿出来用。
关于 druid 的 SQL 解析器的原理，可以看看我之前写的文章：

• 《提取 Druid 的 SQL 解析器》
• 《Druid SQL 解析器概览》
• 《Druid SQL 解析器的解析过程》

基本上，seata 对于 druid 的使用方式，就这两个核心的步骤：

1. 利用 druid 的 API 解析 SQL，生成一棵 AST(通常类名为 xxxStatement)
2. 可以直接通过 AST 获得的信息就直接获得
3. 无法通过 AST 直接获得的，则编写 visitor，从 AST 中提取想要的信息

seata 中的 visitor 大多数都是 OutputVisitor，即可以让 druid 把想要的信息自动追加到你传进去的 StringBuilder 里面，获取信息时只需要调用 StringBuilder.toString 即可。
例如在 MySQLInsertRecognizer 这个类中，语法树的表示：

直接从语法树上获取 insert 对应的字段：

使用 visitor 获取信息：

其它类型 Recognizer 基本上大同小异，这里不展开了。

数据库表元信息

seata 在生成镜像时，需要生成前后镜像查询 SQL，这些 SQL 的 where 条件，并不是一味地依赖于原 SQL 的 where 条件，特别是原 SQL 的 where 条件十分复杂，且字段繁多的时候。因此 seata 会将数据库表的元信息查询出来，缓存在本地，在构造镜像查询 SQL 时，可以将 where 条件优化成带有主键字段或者带有索引字段的查询条件，提高查询的效率。
这些缓存下来的元信息主要包括：

1. 表的主键信息
2. 表的索引信息
3. 表的字段信息

在 seata 中，用 TableMeta 表示表的元信息，ColumnMeta 表示字段的元信息，IndexMeta 表示索引的信息。除了将这些元信息缓存在本地，seata 还会定期去更新表的元信息。

private static final Cache TABLE_META_CACHE = Caffeine.newBuilder().maximumSize(CACHE_SIZE)
    .expireAfterWrite(EXPIRE_TIME, TimeUnit.MILLISECONDS).softValues().build();


/**
 * Clear the table meta cache
 * @param dataSourceProxy
 */
public static void refresh(final DataSourceProxy dataSourceProxy){
    ConcurrentMap tableMetaMap = TABLE_META_CACHE.asMap();
    for (Entry entry : tableMetaMap.entrySet()) {
        try {
            TableMeta tableMeta = fetchSchema(dataSourceProxy, entry.getValue().getTableName());
            if (tableMeta == null){
                LOGGER.error("get table meta error");
            }
            if (!tableMeta.equals(entry.getValue())){
                TABLE_META_CACHE.put(entry.getKey(), tableMeta);
                LOGGER.info("table meta change was found, update table meta cache automatically.");
            }
        } catch (SQLException e) {
            LOGGER.error("get table meta error:{}", e.getMessage(), e);
        }
    }
}

SQL 执行器

不同的 SQL 类型，会使用不同类型的 SQL 执行器来执行，这个执行器的执行过程中，就会包含前置镜像和后置镜像的生成，undo_log 的插入等，它的代码层次结构是这样的：

其中，PlainExecutor 则是默认执行原本的操作，不添加任何其它逻辑，当本地事务不参与到全局事务的时候，使用这个执行器。

BaseTransactionExecutor 执行器定义了一些公共的执行逻辑，如下所示：

@Override
public Object execute(Object... args) throws Throwable {
    if (RootContext.inGlobalTransaction()) {
        String xid = RootContext.getXID();
        statementProxy.getConnectionProxy().bind(xid);
    }

    if (RootContext.requireGlobalLock()) {
        statementProxy.getConnectionProxy().setGlobalLockRequire(true);
    } else {
        statementProxy.getConnectionProxy().setGlobalLockRequire(false);
    }
    return doExecute(args);
}

1 判断当前是否处于全局事务中，如果是，将全局事务 id 绑定到当前连接上。

1. 判断是否需要加锁
2. 执行抽象方法 doExecute

doExecute 方法是抽象的，留待子类实现。

DML 相关的执行器

AbstractDMLBaseExecutor 中实现了 doExecute 方法：

@Override
public T doExecute(Object... args) throws Throwable {
    AbstractConnectionProxy connectionProxy = statementProxy.getConnectionProxy();
    if (connectionProxy.getAutoCommit()) {
        return executeAutoCommitTrue(args);
    } else {
        return executeAutoCommitFalse(args);
    }
}

这里需要判断一下当前的连接是否是自动提交的，来决定不同的处理方式。
如果当前的连接设置已经是自动提交的，那么需要手动将它设置为非自动提交，也就是手动开启事务，目的是为了将原 SQL 与 undo_log 写数据的 SQL 保持在同一个本地事务里面。如下代码所示：

/**
 * Execute auto commit true t.
 *
 * @param args the args
 * @return the t
 * @throws Throwable the throwable
 */
protected T executeAutoCommitTrue(Object[] args) throws Throwable {
    T result = null;
    AbstractConnectionProxy connectionProxy = statementProxy.getConnectionProxy();
    LockRetryController lockRetryController = new LockRetryController();
    try {
        connectionProxy.setAutoCommit(false);
        while (true) {
            try {
                result = executeAutoCommitFalse(args);
                connectionProxy.commit();
                break;
            } catch (LockConflictException lockConflict) {
                connectionProxy.getTargetConnection().rollback();
                lockRetryController.sleep(lockConflict);
            }
        }

    } catch (Exception e) {
        // when exception occur in finally,this exception will lost, so just print it here
        LOGGER.error("exception occur", e);
        throw e;
    } finally {
        connectionProxy.setAutoCommit(true);
    }
    return result;
}

1. 首先将连接置为非自动提交的状态
2. 构造一个无限循环，以便在锁冲突导致的执行失败后可以重试，循环退出条件是冲突次数达到一定次数或者正常执行完成。
3. 循环体的主体内容是，以非自动提交的状态执行 SQL 处理逻辑，然后手动提交。

如果当前的连接设置是非自动提交的，说明当前已经处于一个本地事务中，不需要手动开启事务。如下代码所示：

/**
 * Execute auto commit false t.
 *
 * @param args the args
 * @return the t
 * @throws Throwable the throwable
 */
protected T executeAutoCommitFalse(Object[] args) throws Throwable {
    TableRecords beforeImage = beforeImage();
    T result = statementCallback.execute(statementProxy.getTargetStatement(), args);
    TableRecords afterImage = afterImage(beforeImage);
    prepareUndoLog(beforeImage, afterImage);
    return result;
}

这里的执行逻辑是

1. 先生成前置镜像
2. 执行原 SQL
3. 生成后置镜像
4. 暂时保存前置镜像和后置镜像作为一条 undo log.

生成前置镜像和后置镜像的方法 beforeImage 和 afterImage 都是抽象，留给具体的子类去实现。
prepareUndoLog 主要是利用前置镜像和后置镜像，生成一条 undo log：

/**
 * prepare undo log.
 *
 * @param beforeImage the before image
 * @param afterImage  the after image
 * @throws SQLException the sql exception
 */
protected void prepareUndoLog(TableRecords beforeImage, TableRecords afterImage) throws SQLException {
    if (beforeImage.getRows().size() == 0 && afterImage.getRows().size() == 0) {
        return;
    }

    ConnectionProxy connectionProxy = statementProxy.getConnectionProxy();

    TableRecords lockKeyRecords = sqlRecognizer.getSQLType() == SQLType.DELETE ? beforeImage : afterImage;
    String lockKeys = buildLockKey(lockKeyRecords);
    connectionProxy.appendLockKey(lockKeys);

    SQLUndoLog sqlUndoLog = buildUndoItem(beforeImage, afterImage);
    connectionProxy.appendUndoLog(sqlUndoLog);
}

---

update 语句镜像生成

对于 update 语句，需要同时生成前置镜像和后置镜像，因为 update 是会修改已有数据的。

update 前置镜像

UpdateExecutor 封装了前置镜像和后置镜像的生成，下面是前置镜像的生成细节：

@Override
protected TableRecords beforeImage() throws SQLException {

    ArrayList> paramAppenderList = new ArrayList<>();
    TableMeta tmeta = getTableMeta();
    String selectSQL = buildBeforeImageSQL(tmeta, paramAppenderList);
    logger.info("logged by beanlam, original sql = {}, before image query sql = {}", this.sqlRecognizer.getOriginalSQL(), selectSQL);
    return buildTableRecords(tmeta, selectSQL, paramAppenderList);
}

private String buildBeforeImageSQL(TableMeta tableMeta, ArrayList> paramAppenderList) {
    SQLUpdateRecognizer recognizer = (SQLUpdateRecognizer) sqlRecognizer;
    List updateColumns = recognizer.getUpdateColumns();
    StringBuilder prefix = new StringBuilder("SELECT ");
    if (!tableMeta.containsPK(updateColumns)) {
        prefix.append(getColumnNameInSQL(tableMeta.getPkName()) + ", ");
    }
    StringBuilder suffix = new StringBuilder(" FROM " + getFromTableInSQL());
    String whereCondition = buildWhereCondition(recognizer, paramAppenderList);
    if (StringUtils.isNotBlank(whereCondition)) {
        suffix.append(" WHERE " + whereCondition);
    }
    suffix.append(" FOR UPDATE");
    StringJoiner selectSQLJoin = new StringJoiner(", ", prefix.toString(), suffix.toString());
    for (String updateColumn : updateColumns) {
        selectSQLJoin.add(updateColumn);
    }
    return selectSQLJoin.toString();
}

首先通过 buildBeforeImageSQL 方法生成前置镜像查询语句，这里需要用到 SQL 解析器解析到的 SQL 信息，比如更新的字段，更新时的 where 条件是什么。也需要用到已经缓存的表的元数据的信息，比如说判断更新字段是否主键。
这里有两个关键的地方：

1. 一个是如果主键不在更新字段列表里，那么构造后的查询 SQL 里，主键字段必须在查询的字段列表里
2. 查询语句需要加 for update 进行加行锁

前置镜像查询语句构造完成后，便要通过 buildTableRecords 方法进行前置镜像的查询：

protected TableRecords buildTableRecords(TableMeta tableMeta, String selectSQL, ArrayList> paramAppenderList) throws SQLException {
    TableRecords tableRecords = null;
    PreparedStatement ps = null;
    Statement st = null;
    ResultSet rs = null;
    try {
        if (paramAppenderList.isEmpty()) {
            st = statementProxy.getConnection().createStatement();
            rs = st.executeQuery(selectSQL);
        } else {
            if (paramAppenderList.size() == 1) {
                ps = statementProxy.getConnection().prepareStatement(selectSQL);
                List