分布式事务框架Seata原理分析 （一） 客户端

最新推荐文章于 2025-03-21 22:51:41 发布
最新推荐文章于 2025-03-21 22:51:41 发布
阅读量965 收藏 2
点赞数
分类专栏： 微服务 文章标签： 数据库 sql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/LeoHan163/article/details/114898506
版权
Seata在微服务环境中解决分布式事务问题，通过代理数据源实现事务管理。它在执行SQL前保存数据镜像，利用全局锁协调事务，确保数据一致性。在提交事务前，先注册分支事务并保存undo日志，保证全局事务的正确性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

随着微服务、程序性能要求越来越高的情况下，微服务越来越流行，传统的程序都是一个单体应用、单个数据库来搭配，随着微服务的盛行，单个服务单个数据库的搭配慢慢流行起来、微服务虽然在业务拆分和后续扩展带来了不少的便利，但是同时也带来一些问题，传统的单库事务不是难题，但是微服务中如果多个服务的调用需要在单个事务中进行则比较麻烦，Seata则提供了对饮的解决方案。

传统跨数据库的事务有比较著名的两阶段提交、三阶段提交等。

站在一个比较高的角度来看，Seata实际上是在各个库执行前通过代理将执行前的数据保存下来，通过一个中间协调者的角色，来协调所有的事务，当所有事务都执行成功时，则会删除保存的执行前数据，如果有执行失败需要回滚，则通过保存的执行前的数据来回滚数据。
一般Seta中的数据源需要按照如下配置，配置代理数据源

new DataSourceProxy(dataSource)

这里可以作为我们研究的一个入口，我们观察获取连接的方法：

public ConnectionProxy getConnection(String username, String password) throws SQLException {
    Connection targetConnection = targetDataSource.getConnection(username, password);
    return new ConnectionProxy(this, targetConnection);
}

这里获取到的实际上是一个’ConnectionProxy’:

public class ConnectionProxy extends AbstractConnectionProxy

在父类AbstractConnectionProxy中获取Statement:

public Statement createStatement() throws SQLException {
    Statement targetStatement = getTargetConnection().createStatement();
    return new StatementProxy(this, targetStatement);
}

@Override
public PreparedStatement prepareStatement(String sql) throws SQLException {
    String dbType = getDbType();
    // support oracle 10.2+
    PreparedStatement targetPreparedStatement = null;
    if (BranchType.AT == RootContext.getBranchType()) {
        List<SQLRecognizer> sqlRecognizers = SQLVisitorFactory.get(sql, dbType);
        if (sqlRecognizers != null && sqlRecognizers.size() == 1) {
            SQLRecognizer sqlRecognizer = sqlRecognizers.get(0);
            if (sqlRecognizer != null && sqlRecognizer.getSQLType() == SQLType.INSERT) {
                TableMeta tableMeta = TableMetaCacheFactory.getTableMetaCache(dbType).getTableMeta(getTargetConnection(),
                        sqlRecognizer.getTableName(), getDataSourceProxy().getResourceId());
                String[] pkNameArray = new String[tableMeta.getPrimaryKeyOnlyName().size()];
                tableMeta.getPrimaryKeyOnlyName().toArray(pkNameArray);
                targetPreparedStatement = getTargetConnection().prepareStatement(sql,pkNameArray);
            }
        }
    }
    if (targetPreparedStatement == null) {
        targetPreparedStatement = getTargetConnection().prepareStatement(sql);
    }
    return new PreparedStatementProxy(this, targetPreparedStatement, sql);
}

这里我们以Statement.execute为例来进行说明，


public StatementProxy(AbstractConnectionProxy connectionWrapper, T targetStatement, String targetSQL)
    throws SQLException {
    super(connectionWrapper, targetStatement, targetSQL);
}
public int executeUpdate(String sql) throws SQLException {
    this.targetSQL = sql;
    return ExecuteTemplate.execute(this, (statement, args) -> statement.executeUpdate((String) args[0]), sql);
}

@Override
public boolean execute(String sql) throws SQLException {
    this.targetSQL = sql;
    return ExecuteTemplate.execute(this, (statement, args) -> statement.execute((String) args[0]), sql);
}

在ExecuteTemplate中，

public static <T, S extends Statement> T execute(StatementProxy<S> statementProxy,
                                                 StatementCallback<T, S> statementCallback,
                                                 Object... args) throws SQLException {
    return execute(null, statementProxy, statementCallback, args);
}
public static <T, S extends Statement> T execute(List<SQLRecognizer> sqlRecognizers,
                                                 StatementProxy<S> statementProxy,
                                                 StatementCallback<T, S> statementCallback,
                                                 Object... args) throws SQLException {
    if (!RootContext.requireGlobalLock() && BranchType.AT != RootContext.getBranchType()) {
        // Just work as original statement
        return statementCallback.execute(statementProxy.getTargetStatement(), args);
    }

    String dbType = statementProxy.getConnectionProxy().getDbType();
    if (CollectionUtils.isEmpty(sqlRecognizers)) {
        sqlRecognizers = SQLVisitorFactory.get(
                statementProxy.getTargetSQL(),
                dbType);
    }
    Executor<T> executor;
    if (CollectionUtils.isEmpty(sqlRecognizers)) {
        executor = new PlainExecutor<>(statementProxy, statementCallback);
    } else {
        if (sqlRecognizers.size() == 1) {
            SQLRecognizer sqlRecognizer = sqlRecognizers.get(0);
            switch (sqlRecognizer.getSQLType()) {
                case INSERT:
                    executor = EnhancedServiceLoader.load(InsertExecutor.class, dbType,
                            new Class[]{StatementProxy.class, StatementCallback.class, SQLRecognizer.class},
                            new Object[]{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;
            }
        } else {
            executor = new MultiExecutor<>(statementProxy, statementCallback, sqlRecognizers);
        }
    }
    T rs;
    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;
}

可以看到，执行的时候，先获取执行的sql语句，得到需要执行的是’INSERT’、UPDATE、DELETE、SELECT_FOR_UPDATE其他类型sql语句，则按照一般sql直接执行：

public PlainExecutor(StatementProxy<S> statementProxy, StatementCallback<T, S> statementCallback) {
    this.statementProxy = statementProxy;
    this.statementCallback = statementCallback;
}
public T execute(Object... args) throws Throwable {
    return statementCallback.execute(statementProxy.getTargetStatement(), args);
}

可以看到如果是’INSERT’、UPDATE、DELETE、SELECT_FOR_UPDATE则会用对应的Executor去在执行，这里我们看看update的执行逻辑：

// BaseTransactionalExecutor.java
public T execute(Object... args) throws Throwable {
    String xid = RootContext.getXID();
    if (xid != null) {
        statementProxy.getConnectionProxy().bind(xid);
    }

    statementProxy.getConnectionProxy().setGlobalLockRequire(RootContext.requireGlobalLock());
    return doExecute(args);
}

// AbstractDMLBaseExecutor.java
public T doExecute(Object... args) throws Throwable {
    AbstractConnectionProxy connectionProxy = statementProxy.getConnectionProxy();
    if (connectionProxy.getAutoCommit()) {
        return executeAutoCommitTrue(args);
    } else {
        return executeAutoCommitFalse(args);
    }
}
protected T executeAutoCommitFalse(Object[] args) throws Exception {
    if (!JdbcConstants.MYSQL.equalsIgnoreCase(getDbType()) && isMultiPk()) {
        throw new NotSupportYetException("multi pk only support mysql!");
    }
    TableRecords beforeImage = beforeImage();
    T result = statementCallback.execute(statementProxy.getTargetStatement(), args);
    TableRecords afterImage = afterImage(beforeImage);
    prepareUndoLog(beforeImage, afterImage);
    return result;
}

注意这里executeAutoCommitTrue会关闭自动提交，然后执行完之后，这里会立马提交事务。

 protected T executeAutoCommitTrue(Object[] args) throws Throwable {
        ConnectionProxy connectionProxy = statementProxy.getConnectionProxy();
        try {
            connectionProxy.setAutoCommit(false);
            return new LockRetryPolicy(connectionProxy).execute(() -> {
                T result = executeAutoCommitFalse(args);
                connectionProxy.commit();
                return result;
            });
        } catch (Exception e) {
            // when exception occur in finally,this exception will lost, so just print it here
            LOGGER.error("execute executeAutoCommitTrue error:{}", e.getMessage(), e);
            if (!LockRetryPolicy.isLockRetryPolicyBranchRollbackOnConflict()) {
                connectionProxy.getTargetConnection().rollback();
            }
            throw e;
        } finally {
            connectionProxy.getContext().reset();
            connectionProxy.setAutoCommit(true);
        }
    }

如果当前关闭了自动提交，则需要手动的调用commit。

可以看到，在这里能看出执行每个SQL的步骤，在执行前会先对现有数据保存一个镜像，然后执行实际的SQL，执行完之后，在保存执行后的镜像，我们来分析下执行前构造镜像的实现：

// UpdateExecutor.java
protected TableRecords beforeImage() throws SQLException {
    ArrayList<List<Object>> paramAppenderList = new ArrayList<>();
    TableMeta tmeta = getTableMeta();
    String selectSQL = buildBeforeImageSQL(tmeta, paramAppenderList);
    return buildTableRecords(tmeta, selectSQL, paramAppenderList);
}

private String buildBeforeImageSQL(TableMeta tableMeta, ArrayList<List<Object>> paramAppenderList) {
    SQLUpdateRecognizer recognizer = (SQLUpdateRecognizer) sqlRecognizer;
    List<String> updateColumns = recognizer.getUpdateColumns();
    assertContainsPKColumnName(updateColumns);
    StringBuilder prefix = new StringBuilder("SELECT ");
    StringBuilder suffix = new StringBuilder(" FROM ").append(getFromTableInSQL());
    String whereCondition = buildWhereCondition(recognizer, paramAppenderList);
    if (StringUtils.isNotBlank(whereCondition)) {
        suffix.append(WHERE).append(whereCondition);
    }
    String orderBy = recognizer.getOrderBy();
    if (StringUtils.isNotBlank(orderBy)) {
        suffix.append(orderBy);
    }
    ParametersHolder parametersHolder = statementProxy instanceof ParametersHolder ? (ParametersHolder)statementProxy : null;
    String limit = recognizer.getLimit(parametersHolder, paramAppenderList);
    if (StringUtils.isNotBlank(limit)) {
        suffix.append(limit);
    }
    suffix.append(" FOR UPDATE");
    StringJoiner selectSQLJoin = new StringJoiner(", ", prefix.toString(), suffix.toString());
    if (ONLY_CARE_UPDATE_COLUMNS) {
        if (!containsPK(updateColumns)) {
            selectSQLJoin.add(getColumnNamesInSQL(tableMeta.getEscapePkNameList(getDbType())));
        }
        for (String columnName : updateColumns) {
            selectSQLJoin.add(columnName);
        }
    } else {
        for (String columnName : tableMeta.getAllColumns().keySet()) {
            selectSQLJoin.add(ColumnUtils.addEscape(columnName, getDbType()));
        }
    }
    return selectSQLJoin.toString();
}

可以看到，构造事务执行前的数据镜像是通过分析执行SQL，直接将update替换成SELECT,同时需要注意的是，在构造的SQL后面还加上了FOR UPDATE，显示的获取了写锁，这时候其他线程对当前需要操作的数据执行的操作都必须等待当前事务提交完成。
同理，构造执行之后的数据镜像：

protected TableRecords afterImage(TableRecords beforeImage) throws SQLException {
        TableMeta tmeta = getTableMeta();
        if (beforeImage == null || beforeImage.size() == 0) {
            return TableRecords.empty(getTableMeta());
        }
        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);
        }
    }

    private String buildAfterImageSQL(TableMeta tableMeta, TableRecords beforeImage) throws SQLException {
        StringBuilder prefix = new StringBuilder("SELECT ");
        String whereSql = SqlGenerateUtils.buildWhereConditionByPKs(tableMeta.getPrimaryKeyOnlyName(), beforeImage.pkRows().size(), getDbType());
        String suffix = " FROM " + getFromTableInSQL() + " WHERE " + whereSql;
        StringJoiner selectSQLJoiner = new StringJoiner(", ", prefix.toString(), suffix);
        if (ONLY_CARE_UPDATE_COLUMNS) {
            SQLUpdateRecognizer recognizer = (SQLUpdateRecognizer) sqlRecognizer;
            List<String> updateColumns = recognizer.getUpdateColumns();
            if (!containsPK(updateColumns)) {
                selectSQLJoiner.add(getColumnNamesInSQL(tableMeta.getEscapePkNameList(getDbType())));
            }
            for (String columnName : updateColumns) {
                selectSQLJoiner.add(columnName);
            }
        } else {
            for (String columnName : tableMeta.getAllColumns().keySet()) {
                selectSQLJoiner.add(ColumnUtils.addEscape(columnName, getDbType()));
            }
        }
        return selectSQLJoiner.toString();
    }

和beforeImage类似，都是通过反向解析当前执行的数据，然后解析出来，并且都加上了FOR UPDATE写锁。

上述步骤执行完之后，这时候我们有执行前的镜像，SQL也执行，然后也获得了执行后的数据镜像，然后准备undolog:

// BaseTransactionalExecutor.java
protected void prepareUndoLog(TableRecords beforeImage, TableRecords afterImage) throws SQLException {
        if (beforeImage.getRows().isEmpty() && afterImage.getRows().isEmpty()) {
            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);
    }
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;
    }
// ConnectionProxy.java
public void appendUndoLog(SQLUndoLog sqlUndoLog) {
        context.appendUndoItem(sqlUndoLog);
    }
// ConnectionContext.java
private List<SQLUndoLog> sqlUndoItemsBuffer = new ArrayList<>();
 void appendUndoItem(SQLUndoLog sqlUndoLog) {
        sqlUndoItemsBuffer.add(sqlUndoLog);
    }

这时候就是把镜像保存到了ConnectionProxy的一个本地缓存中。
需要注意这段逻辑String lockKeys = buildLockKey(lockKeyRecords);,这里构建了一个lockKey,在想TC注册分支事务的时候，同事利用该lockKeys来进行全局锁，锁定的就是我们这次操作所涉及到的所有数据：

protected String buildLockKey(TableRecords rowsIncludingPK) {
        if (rowsIncludingPK.size() == 0) {
            return null;
        }
        StringBuilder sb = new StringBuilder();
        sb.append(rowsIncludingPK.getTableMeta().getTableName());
        sb.append(":");
        int filedSequence = 0;
        List<Field> pkRows = rowsIncludingPK.pkRows();
        for (Field field : pkRows) {
            sb.append(field.getValue());
            filedSequence++;
            if (filedSequence < pkRows.size()) {
                sb.append(",");
            }
        }
        return sb.toString();
    }

可以看到如果没有主键这里返回直接是null，从侧面说明，seata涉及到分布式事务表必须有主键。
可以看到，这里构建的锁的key的格式为：主键名称:vaue1,value2格式，这个后面再注册分支事务的时候在进行全局锁的时候，用到的就是该数据可以看到，这样能顾将本次操作所涉及的数据全部锁定。

需要注意的时候，这时候事务并未提交，这时候调用commit的时候，就是通过ConnectionProxy.commit来执行：

// ConnectionProxy.java
public void commit() throws SQLException {
        try {
            LOCK_RETRY_POLICY.execute(() -> {
                doCommit();
                return null;
            });
        } catch (SQLException e) {
            if (targetConnection != null && !getAutoCommit()) {
                rollback();
            }
            throw e;
        } catch (Exception e) {
            throw new SQLException(e);
        }
    }
private void doCommit() throws SQLException {
        if (context.inGlobalTransaction()) {
            processGlobalTransactionCommit();
        } else if (context.isGlobalLockRequire()) {
            processLocalCommitWithGlobalLocks();
        } else {
            targetConnection.commit();
        }
    }
private void processGlobalTransactionCommit() throws SQLException {
        try {
            register();
        } catch (TransactionException e) {
            recognizeLockKeyConflictException(e, context.buildLockKeys());
        }
        try {
            UndoLogManagerFactory.getUndoLogManager(this.getDbType()).flushUndoLogs(this);
            targetConnection.commit();
        } catch (Throwable ex) {
            LOGGER.error("process connectionProxy commit error: {}", ex.getMessage(), ex);
            report(false);
            throw new SQLException(ex);
        }
        if (IS_REPORT_SUCCESS_ENABLE) {
            report(true);
        }
        context.reset();
    }

// AbstractUndoLogManager.java
 public void flushUndoLogs(ConnectionProxy cp) throws SQLException {
        ConnectionContext connectionContext = cp.getContext();
        if (!connectionContext.hasUndoLog()) {
            return;
        }

        String xid = connectionContext.getXid();
        long branchId = connectionContext.getBranchId();

        BranchUndoLog branchUndoLog = new BranchUndoLog();
        branchUndoLog.setXid(xid);
        branchUndoLog.setBranchId(branchId);
        branchUndoLog.setSqlUndoLogs(connectionContext.getUndoItems());

        UndoLogParser parser = UndoLogParserFactory.getInstance();
        byte[] undoLogContent = parser.encode(branchUndoLog);

        if (LOGGER.isDebugEnabled()) {
            LOGGER.debug("Flushing UNDO LOG: {}", new String(undoLogContent, Constants.DEFAULT_CHARSET));
        }

        insertUndoLogWithNormal(xid, branchId, buildContext(parser.getName()), undoLogContent,
            cp.getTargetConnection());
    }

可以看到，如果是一个全局的事务，在提交之前，会把unlog日志保存到库中然后提交事务。在全局事务提交前 ，可以看到注册了当前事务分支。

// ConnectionProxy.java
 private void register() throws TransactionException {
        if (!context.hasUndoLog() || context.getLockKeysBuffer().isEmpty()) {
            return;
        }
        Long branchId = DefaultResourceManager.get().branchRegister(BranchType.AT, getDataSourceProxy().getResourceId(),
            null, context.getXid(), null, context.buildLockKeys());
        context.setBranchId(branchId);
    }

综上所述，可以看到Seata在调用方的逻辑如下：

  1. 通过DatasouceProxy来获取Conneciton，获取到的连接实际上是一个ConnectionProxy
  2. 在我们实际执行SQL的时候，通过ConnectionProxy能够获取到对应要执行的SQL，解析SQL，获取到对应执行前涉及数据的所有记录和执行后涉及到的所有记录（获取执行前的记录时通过select … for update来进行数据库涉及到的记录的锁定，也就是seata所说的本地锁），并构建beforeImage和afterImage，同时基于beforeImage和afterImage来构建lockKey，为后续注册分支事务并锁定来提供key（也就是seata所说的全局锁）
  3. 上述工作完成之后，事务会立马提交（如果是autocommit=true，立马提交，autocommit=false，需要显示调用提交），在提交本地事务前，会去注册分支事务并获得全局锁，如果成功，本地事务会立马提交（注意这时候的全局锁锁定的是本次操作的所有记录的主键，实现实际上在seata tc端是通过insert，借助数据库的ACID属性来保证锁的一致性，如果其他分支事务操作涉及到本次操作所有数据中任意一条，获取全局锁则无法成功）
【springcloud微微服务】分布式事务框架Seata使用详解
congge_study的博客
04-25 5069
分布式事务框架Seata使用详解
分布式事务框架Seata的使用
gongsl
02-23 5366
1. 分布式事务入门 事务必须具有的四个特性分别是：原子性(atomicity)、一致性(consistency)、隔离性(isolation，又称独立性)以及持久性(durability)。这就是事务的ACID原则。 下面进行分布式服务的案例演示，看看没有分布式事务时可能会引发的问题。项目工程是seata-demo，主要包含以下三个服务，分别是order-service(订单服务)、account-service(账户服务)以及storage-service(库存服务)： 项目的初始化数据库脚本如下
seata分布式事务原理解析
GOV_D的博客
03-22 1058
seata分布式事务原理解析
Seata分布式事务原理
m0_60491538的博客
11-19 2772
Seata
从零开始学Seata：分布式事务的终极解决方案
最新发布
tang_sy的博客
03-21 1204
Seata是分布式事务的“瑞士军刀”，既能通过AT模式实现强一致性，又支持TCC/Saga灵活应对不同场景。对于大多数互联网项目，尤其是金融和电商领域，Seata是值得优先选择的解决方案。入门虽难，但通过官方文档和社区资源，可以快速上手并落地。其核心目标是**“让开发者专注业务，自动管理事务”**，通过。：资源管理器，管理数据库连接等资源（类似球员）。：事务协调者，统筹全局事务（类似裁判）。：事务管理器，定义事务边界（类似教练）。：基于乐观锁和异步回滚，减少资源阻塞。：允许短暂不一致，但最终状态一致。
Seata简单介绍及其原理(一)
qq_29860591的博客
11-15 2694
Seata 是什么? Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。 AT 模式 前提 基于支持本地 ACID 事务的关系型数据库。 Java 应用，通过 JDBC 访问数据库。 整体机制 两阶段提交协议的演变： 一阶段：业务数据和回...
seata分布式事务的原理
文盲青年的博客
05-27 575
seata分布式事务的原理？ 参考答案： Seata 内部定义了 3个模块来处理全局事务和分支事务的关系和处理过程，这三个组件分别是： •Transaction Coordinator (TC)：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。 •Transaction Manager ™：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。 •Resource Manager (RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支
分布式事务Seata原理
笑小枫
04-09 962
Seata 是一款开源的分布式事务解决方案，致力于提供高性能与简单易用的分布式事务服务，为用户提供了 AT、TCC、SAGA 和 XA 几种不同的事务模式。Seata AT模式是基于XA事务演进而来，需要数据库支持。AT 模式的特点就是对业务无入侵式，用户只需要关注自己的业务SQL，Seata 框架会在第一阶段拦截并解析用户的 SQL，并保存其变更前后的数据镜像，形成undo log，并自动生成事务第二阶段的提交和回滚操作。
【Java】分布式事务框架seata demo_pgj.zip
02-07
Java分布式事务框架Seata的demo项目是用于展示和学习如何在实际的项目中应用Seata框架来管理分布式事务的一个实践案例。Seata是阿里巴巴开源的一款简单易用的分布式事务解决方案，旨在提供高性能和简单易用的分布式...
分布式事务——分布式事务简介、分布式事务框架 Seata（AT模式、Tcc模式、Tcc Vs AT）、分布式事务—MQ
m0_54853503的博客
07-31 5186
最早的分布式事务应用架构很简单，不涉及服务间的访问调用，仅仅是服务内操作涉及到对多个数据库资源的访问。当一个服务操作访问不同的数据库资源，又希望对它们的访问具有事务特性时，就需要采用分布式事务来协调所有的事务参与者。对于上面介绍的分布式事务应用架构，尽管一个服务操作会访问多个数据库资源，但是毕竟整个事务还是控制在单一服务的内部。如果一个服务操作需要调用另外一个服务，这时的事务就需要跨越多个服务了。四种模式，https1.4.01.2.0Seata是什么？一阶段，这些就不再赘述了。总之，...
Seata是一种易于使用高性能基于Java的开源分布式事务解决方案
08-08
Seata是一种易于使用，高性能，基于Java的开源分布式事务解决方案
分布式事务-Seata原理
donghao_1009的博客
12-06 1753
分布式事务-Seata
Seata分布式事务实现原理
m0_62565675的博客
11-08 195
Seata分布式事务实现原理
seata分布式事务原理_分布式事务框架 Seata
weixin_39635314的博客
11-28 289
引言Seata 的前身 Fescar 刚开源的时候，就看过相关的文章和代码，代码写得很好，我还在另一个自己的项目中，借鉴了它的很多设计风格。最近想总结一篇关于分布式事务的文章，所以就想以 Seata 为中心，围绕它来细述分布式事务的点点滴滴。 背景互联网系统最初的设计一般都是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以，在这个阶段一般都会对数据库进行水平拆分，...
seata tcc模式下的一个性能问题
IT云清
09-03 5771
本文解释Seata中，AT模式和MT模式下的一个一阶段的区别。 根据两阶段行为模式的不同，Seata将分支事务划分为2种： Automatic (Branch) Transaction Mode Manual (Branch) Transaction Mode 1.AT模式 AT 模式基于 支持本地 ACID 事务 的 关系型数据库： 一阶段 prepare 行为：在本地事务中，一并提交业务数...
seata分布式事务原理_分布式事务seata集成
weixin_39930711的博客
11-29 135
1、下载安装seata服务1.1、下载 地址：https://github.com/seata/seata/releases1.2、解压后修改 seataconf 目录下的 register.conf ,file.conf,数据库地址、zookeeper地址配置 register.conf,我的注册中心是 zk,去掉多余的配置，只需要修改zk的地址即可;配置file.conf，只需要修改数据库...
关于分布式事务实现原理（Seata篇）
2201_75419152的博客
02-07 3143
本人学习自用，部分图片来自其他b站或其他博主，侵删
seata分布式事务框架原理
学亮编程手记
11-07 671
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值