Seata AT 模式事务隔离级别与全局锁设计

hundan_520520

已于 2023-02-01 15:14:18 修改

阅读量1k

点赞数 1

分类专栏： # Spring Cloud 文章标签：数据库 java mysql

于 2023-02-01 15:12:02 首次发布

本文链接：https://blog.csdn.net/hundan_520520/article/details/128833977

版权

Spring Cloud 专栏收录该内容

7 篇文章 2 订阅

订阅专栏

Seata作为分布式事务解决方案，其全局事务默认工作在读未提交隔离级别，以保证效率。全局锁机制用于防止脏读和脏写，通过全局锁确保事务的隔离性。在AT模式下，Seata使用内部数据源代理实现全局锁，执行和提交过程中检查并获取锁。全局锁和`@GlobalLock`注解结合`selectforupdate`用于防止脏读和脏写，`@GlobalLock`在不需要全局事务时提供轻量级的锁检查。

摘要由CSDN通过智能技术生成

Seata 事务隔离级别解读

在讲 Seata 事务隔离级之前，我们先来回顾一下数据库事务的隔离级别，目前数据库事务的隔离级别一共有 4 种，由低到高分别为：

Read uncommitted：读未提交
Read committed：读已提交
Repeatable read：可重复读
Serializable：序列化

数据库一般默认的隔离级别为读已提交，比如 Oracle，也有一些数据的默认隔离级别为可重复读，比如 Mysql，一般而言，数据库的读已提交能够满足业务绝大部分场景了。

我们知道 Seata 的事务是一个全局事务，它包含了若干个分支本地事务，在全局事务执行过程中（全局事务还没执行完），某个本地事务提交了，如果 Seata 没有采取任务措施，则会导致已提交的本地事务被读取，造成脏读，如果数据在全局事务提交前已提交的本地事务被修改，则会造成脏写。

由此可以看出，传统意义的脏读是读到了未提交的数据，Seata 脏读是读到了全局事务下未提交的数据，全局事务可能包含多个本地事务，某个本地事务提交了不代表全局事务提交了。

在绝大部分应用在读已提交的隔离级别下工作是没有问题的，而实际上，这当中又有绝大多数的应用场景，实际上工作在读未提交的隔离级别下同样没有问题。

在极端场景下，应用如果需要达到全局的读已提交，Seata 也提供了全局锁机制实现全局事务读已提交。但是默认情况下，Seata 的全局事务是工作在读未提交隔离级别的，保证绝大多数场景的高效性。

Seata全局锁

Seata中的分布式事务，都有各自的 XID，每个 XID 都会把 “行锁”（也叫全局锁）注册到 TC 里面
注意加了引号，它不是数据库的那个行锁，它是把分支事务数据库中的数据的主键的某个值注册到 TC，它是全局的
这是 Seata 自己实现的，保证了先拿到全局锁的全局事务做完了所有事之后，其它全局事务才能提交本地事务，并且，高并发下它也不会出现死锁，只是会有等待，性能有点衰减

那么新问题来了：比如商品增加库存，它不是一个分布式事务，既然没有分布式事务去管理它，那就不会被全局锁锁住

于是 AT 还支持管理这种单次操作（加一个注解 @GlobalLock ），让它也注册到 AT（虽然不是分布式事务，但可以使用里面的锁）

所以它在操作库存时，也会到 TC 里找所要操作的记录是否被锁住，这就搞定了隔离性

不会出现下单操作还没回滚呢，库存就被修改了，这就保证了不会脏写

全局锁实现

AT 模式下，会使用 Seata 内部数据源代理 DataSourceProxy，全局锁的实现就是隐藏在这个代理中。我们分别在执行、提交的过程都做了什么。

1、执行过程

执行过程在 StatementProxy 类，在执行过程中，如果执行 SQL 是 select for update，则会使用 SelectForUpdateExecutor 类，如果执行方法中带有 @GlobalTransactional or @GlobalLock注解，则会检查是否有全局锁，如果当前存在全局锁，则会回滚本地事务，通过 while 循环不断地重新竞争获取本地锁和全局锁。

io.seata.rm.datasource.exec.SelectForUpdateExecutor#doExecute

public T doExecute(Object... args) throws Throwable {
    Connection conn = statementProxy.getConnection();
    // ... ...
    try {
        // ... ...
        while (true) {
            try {
                // ... ...
                if (RootContext.inGlobalTransaction() || RootContext.requireGlobalLock()) {
                    // Do the same thing under either @GlobalTransactional or @GlobalLock, 
                    // that only check the global lock  here.
                    statementProxy.getConnectionProxy().checkLock(lockKeys);
                } else {
                    throw new RuntimeException("Unknown situation!");
                }
                break;
            } catch (LockConflictException lce) {
                if (sp != null) {
                    conn.rollback(sp);
                } else {
                    conn.rollback();
                }
                // trigger retry
                lockRetryController.sleep(lce);
            }
        }
    } finally {
        // ...
    }

2、提交过程

提交过程在 ConnectionProxy#doCommit方法中。

1）如果执行方法中带有@GlobalTransactional注解，则会在注册分支时候获取全局锁：

请求 TC 注册分支

io.seata.rm.datasource.ConnectionProxy#register

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

TC 注册分支的时候，获取全局锁

io.seata.server.transaction.at.ATCore#branchSessionLock

protected void branchSessionLock(GlobalSession globalSession, BranchSession branchSession) throws TransactionException {
    if (!branchSession.lock()) {
        throw new BranchTransactionException(LockKeyConflict, String
                                             .format("Global lock acquire failed xid = %s branchId = %s", globalSession.getXid(),
                                                     branchSession.getBranchId()));
    }
}

2）如果执行方法中带有@GlobalLock注解，在提交前会查询全局锁是否存在，如果存在则抛异常：

io.seata.rm.datasource.ConnectionProxy#processLocalCommitWithGlobalLocks

private void processLocalCommitWithGlobalLocks() throws SQLException {
    checkLock(context.buildLockKeys());
    try {
        targetConnection.commit();
    } catch (Throwable ex) {
        throw new SQLException(ex);
    }
    context.reset();
}

写隔离

一阶段本地事务提交前，需要确保先拿到全局锁。
拿不到全局锁，不能提交本地事务。
拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。

以一个示例来说明：
两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。

tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的全局锁，本地提交释放本地锁。 tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的全局锁，tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待 全局锁 。
在这里插入图片描述

在这里插入图片描述
tx1 二阶段全局提交，释放全局锁。tx2 拿到全局锁提交本地事务。

在这里插入图片描述
如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。

此时，如果 tx2 仍在等待该数据的全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的全局锁等锁超时，放弃全局锁并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。

因为整个过程全局锁在 tx1 结束前一直是被 tx1 持有的，所以不会发生脏写的问题。

读隔离

在数据库本地事务隔离级别读已提交（Read Committed）或以上的基础上，Seata（AT 模式）的默认全局隔离级别是读未提交（Read Uncommitted）。

如果应用在特定场景下，必需要求全局的读已提交，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。

在这里插入图片描述
SELECT FOR UPDATE 语句的执行会申请全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。

出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。

如何防止脏写

先来看一下使用 Seata AT 模式是怎么产生脏写的：

在这里插入图片描述
注：分支事务执行过程省略其它过程。

业务一开启全局事务，其中包含分支事务A（修改 A）和分支事务 B（修改 B），业务二修改 A，其中业务一执行分支事务 A 先获取本地锁，业务二则等待业务一执行完分支事务 A 之后，获得本地锁修改 A 并入库，业务一在执行分支事务时发生异常了，由于分支事务 A 的数据被业务二修改，导致业务一的全局事务无法回滚。

如何防止脏写？

1、业务二执行时加 @GlobalTransactional注解：
在这里插入图片描述
注：分支事务执行过程省略其它过程。

业务二在执行全局事务过程中，分支事务 A 提交前注册分支事务获取全局锁时，发现业务业务一全局锁还没执行完，因此业务二提交不了，抛异常回滚，所以不会发生脏写。

2、业务二执行时加 @GlobalLock注解：
在这里插入图片描述
注：分支事务执行过程省略其它过程。

与 @GlobalTransactional注解效果类似，只不过不需要开启全局事务，只在本地事务提交前，检查全局锁是否存在。

3、业务二执行时加 @GlobalLock 注解 + select for update语句：
在这里插入图片描述
如果加了select for update语句，则会在 update 前检查全局锁是否存在，只有当全局锁释放之后，业务二才能开始执行 updateA 操作。

如果单单是 transactional，那么就有可能会出现脏写，根本原因是没有 Globallock 注解时，不会检查全局锁，这可能会导致另外一个全局事务回滚时，发现某个分支事务被脏写了。所以加 select for update 也有个好处，就是可以重试。

如何防止脏读

Seata AT 模式的脏读是指在全局事务未提交前，被其它业务读到已提交的分支事务的数据，本质上是Seata默认的全局事务是读未提交。

那么怎么避免脏读现象呢？

业务二查询 A 时加 @GlobalLock 注解 + select for update语句：
在这里插入图片描述
加select for update语句会在执行 SQL 前检查全局锁是否存在，只有当全局锁完成之后，才能继续执行 SQL，这样就防止了脏读。

GlobalLock 注解说明

从执行过程和提交过程可以看出，既然开启全局事务 @GlobalTransactional注解可以在事务提交前，查询全局锁是否存在，那为什么 Seata 还要设计多处一个 @GlobalLock注解呢？

因为并不是所有的数据库操作都需要开启全局事务，而开启全局事务是一个比较重的操作，需要向 TC 发起开启全局事务等 RPC 过程，而@GlobalLock注解只会在执行过程中查询全局锁是否存在，不会去开启全局事务，因此在不需要全局事务，而又需要检查全局锁避免脏读脏写时，使用@GlobalLock注解是一个更加轻量的操作。

GlobalLock与for update 必须一起使用?

“这里为什么要加上select for update? 只用@GlobalLock能不能防止脏写？” 能。

select for update能带来这么几个好处：

锁冲突更“温柔”些。如果只有@GlobalLock，检查到全局锁，则立刻抛出异常，也许再“坚持”那么一下，全局锁就释放了，抛出异常岂不可惜了。
在updateA()中可以通过select for update获得最新的A，接着再做更新。

参考：

https://www.cnblogs.com/hongdada/p/16796704.html
https://huaweicloud.csdn.net/633578a9d3efff3090b5829e.html

hundan_520520

关注

1
点赞
踩
12

收藏

觉得还不错? 一键收藏
0
评论
Seata AT 模式事务隔离级别与全局锁设计

本地事务提交前，先拿到该记录的全局锁，本地提交释放本地锁。我们知道 Seata 的事务是一个全局事务，它包含了若干个分支本地事务，在全局事务执行过程中（全局事务还没执行完），某个本地事务提交了，如果 Seata 没有采取任务措施，则会导致已提交的本地事务被读取，造成脏读，如果数据在全局事务提交前已提交的本地事务被修改，则会造成脏写。由此可以看出，传统意义的脏读是读到了未提交的数据，Seata 脏读是读到了全局事务下未提交的数据，全局事务可能包含多个本地事务，某个本地事务提交了不代表全局事务提交了。
复制链接

扫一扫

专栏目录