Fescar - RM undoLog的介绍

简介: 开篇 这篇文章的目的是介绍Fescar当中回滚日志undoLog的数据结构,为后续RM执行回滚动作rollback打下基础,因为undoLog涉及的数据结构用源码表示起来比较简单通俗易懂,所以直接根据源码进行讲解。

开篇

 这篇文章的目的是介绍Fescar当中回滚日志undoLog的数据结构,为后续RM执行回滚动作rollback打下基础,因为undoLog涉及的数据结构用源码表示起来比较简单通俗易懂,所以直接根据源码进行讲解。


undoLog源码介绍

public class TableRecords {
    // 表元数据记录
    private TableMeta tableMeta;
    // 表名
    private String tableName;
    // 查询获得的行记录
    private List<Row> rows = new ArrayList<Row>();
}

public class Row {
    // 表的行记录其实表中列字段的集合,Field是column字段。
    private List<Field> fields = new ArrayList<Field>();
}

public class Field {

    // 列名
    public String name;

    private KeyType keyType = KeyType.NULL;

    // 列的字段类型。
    public int type;

    // 列的值
    public Object value;
}

说明:

  • 介绍UndoLog对象之前必须先了解构建UndoLog的原始记录beforeImage和afterImage对象。
  • TableRecords beforeImage = beforeImage()中TableRecords保存SQL执行前后数据镜像。
  • TableRecords顾名思义就是表当中的数据记录,保存从数据表中查询得到的行记录。
  • TableRecords中的List是行记录的集合。
  • Row中的List是单行当中的列字段column。
  • Field是描述单列的数据结构,包含列的字段名,字段类型,字段值等。


public abstract class BaseTransactionalExecutor<T, S extends Statement> implements Executor {

    protected void prepareUndoLog(TableRecords beforeImage, TableRecords afterImage) throws SQLException {
        if (beforeImage.getRows().size() == 0 && afterImage.getRows().size() == 0) {
            return;
        }

        ConnectionProxy connectionProxy = statementProxy.getConnectionProxy();

        // 生成TC的全局锁对象lockKeys  
        TableRecords lockKeyRecords = sqlRecognizer.getSQLType() == SQLType.DELETE ? beforeImage : afterImage;

        // 根据SQL类型区分生成锁字段的原始素材
        String lockKeys = buildLockKey(lockKeyRecords);

        // 将锁字段保存到connectionProxy的维度
        connectionProxy.appendLockKey(lockKeys);

        // 准备SQLUndoLog
        SQLUndoLog sqlUndoLog = buildUndoItem(beforeImage, afterImage);

       // 将回滚日志保存到connectionProxy的维度
        connectionProxy.appendUndoLog(sqlUndoLog);
    }
}

说明:

  • 根据SQL类型区分生成锁字段的原始素材beforeImage或afterImage。
  • 将锁字段保存到connectionProxy的维度
  • 准备SQLUndoLog,通过beforeImage或afterImage。
  • 将回滚日志sqlUndoLog保存到connectionProxy的维度


public abstract class BaseTransactionalExecutor<T, S extends Statement> implements Executor {

    protected String buildLockKey(TableRecords rowsIncludingPK) {
        if (rowsIncludingPK.size() == 0) {
            return null;
        }
        StringBuilder sb = new StringBuilder();
        sb.append(rowsIncludingPK.getTableMeta().getTableName());
        sb.append(":");

        boolean flag = false;
        for (Field field : rowsIncludingPK.pkRows()) {
            if (flag) {
                sb.append(",");
            } else {
                flag = true;
            }
            sb.append(field.getValue());
        }
        return sb.toString();
    }
}

说明:

  • 锁字段的生成逻辑是表名:primaryKey的列值。
  • 锁字段的生成逻辑是表名加pk的值。
  • 关注外层的for循环,如果变更多条记录即多个row记录,就拼接所有row记录的pk的值。


public class SQLUndoLog {
    // SQL的类型
    private SQLType sqlType;
    // 表名
    private String tableName;
    // 执行前镜像
    private TableRecords beforeImage;
    // 执行后镜像
    private TableRecords afterImage;
}


public abstract class BaseTransactionalExecutor<T, S extends Statement> implements Executor {

    protected SQLUndoLog buildUndoItem(TableRecords beforeImage, TableRecords afterImage) {
        SQLType sqlType = sqlRecognizer.getSQLType();
        String tableName = sqlRecognizer.getTableName();

        SQLUndoLog sqlUndoLog = new SQLUndoLog();
        sqlUndoLog.setSqlType(sqlType);
        sqlUndoLog.setTableName(tableName);
        sqlUndoLog.setBeforeImage(beforeImage);
        sqlUndoLog.setAfterImage(afterImage);

        return sqlUndoLog;
    }
}

说明:

  • SQLUndoLog的数据结构如上所示,包括SQL类型、表名、执行前后镜像。
  • buildUndoItem的构建UndoItem的逻辑就是保存上述提到的基础数据。


重点

 个人认为重点在于undoLog的lockKey的生成逻辑以及保存的容器在于connectionProxy对象。

目录
相关文章
|
6月前
|
开发者
seata事务问题之不回滚客户端如何解决
Seata是一款开源的分布式事务解决方案,旨在提供高效且无缝的分布式事务服务;在集成和使用Seata过程中,开发者可能会遇到不同的异常问题,本合集针对Seata常见异常进行系统整理,为开发者提供详细的问题分析和解决方案,助力高效解决分布式事务中的难题。
412 15
|
SQL 数据库
源码解析Seata AT模式中分支事务的提交或回滚是如何被触发的
源码解析Seata AT模式中分支事务的提交或回滚是如何被触发的
334 0
源码解析Seata AT模式中分支事务的提交或回滚是如何被触发的
|
存储 缓存 关系型数据库
undolog回滚日志(MySQL)
undolog回滚日志(MySQL)
214 0
undolog回滚日志(MySQL)
RM在seata AT模式中如何实现分支事务提交或回滚
RM在seata AT模式中如何实现分支事务提交或回滚
447 0
|
XML Java 中间件
Seata 分支事务
前面,我们已经介绍了 Seata 的整体设计思想,接下来我们深入到其实现细节中,本文先来介绍 Seata 中分支事务的整体实现思想。
|
SQL druid 关系型数据库
Seata AT 分支事务
前面,我们已经介绍了 Seata 的整体设计思想,接下来我们深入到其实现细节中,本文介绍 Seata 中 AT 模式分支事务的实现。
|
存储 Dubbo Java
Seata TCC 分支事务
前面,我们已经介绍了 Seata 的整体设计思想,接下来我们深入到其实现细节中,本文介绍 Seata 中 TCC 模式分支事务的实现。
|
Java 数据库连接 FESCAR
Fescar - RM 全局事务提交回滚流程
开篇  这篇文章的目的主要是讲解RM在接收TC的请求后执行全局分支事务提交(doBranchCommit)和全局分支事务回滚(doBranchRollback)的流程。  全局的分支事务提交过程和回滚过程也算RM处理流程中核心的一环,了解以后并结合之前讲解的本地事务提交流程就能够较好的理解整个过程了。
1529 0
|
监控 FESCAR
Fescar - RM 提交本地事务流程
开篇  这篇文章的目的是介绍Fescar的提交流程(Commit)和回滚流程(Rollback),这两个流程其实是Fescar中RM的核心逻辑,涉及和TC交互的流程。  由于RM和TC交互涉及到网络通信,所以这块我们暂时只关注RM端的处理流程而暂时忽略网络通信的过程,网络通信的过程值得通过一篇文章单独进行描述。
1523 0
|
FESCAR SQL
Fescar - RM SelectForUpdateExecutor介绍
开篇  这篇文章的目的是讲解RM Executor模块当中一些通用的方法,这些方法在各个Executor的父类当中实现的,各个子类Executor模块都会复用,因此抽取出来统一的进行讲解。  个人是认为抽取通用的内容放在一篇文章讲解完后可以针对每类Executor讲解特有的功能,这样能够有更好的理解。
1176 0