詳解 Seata AT 模式事務隔離級別與全局鎖設計

作者：張乘輝 2021-12-27 09:20:13

Seata AT 模式是一種非侵入式的分布式事務解決方案，Seata 在內部做了對數據庫操作的代理層，我們使用 Seata AT 模式時，實際上用的是 Seata 自帶的數據源代理 DataSourceProxy，Seata 在這層代理中加入了很多邏輯，比如插入回滾 undo_log 日志，檢查全局鎖等。

[[442164]]

為什么要檢查全局鎖呢，這是由于 Seata AT 模式的事務隔離是建立在支事務的本地隔離級別基礎之上的，在數據庫本地隔離級別讀已提交或以上的前提下，Seata 設計了由事務協調器維護的全局寫排他鎖，來保證事務間的寫隔離，同時，將全局事務默認定義在讀未提交的隔離級別上。

Seata 事務隔離級別解讀

在講 Seata 事務隔離級之前，我們先來回顧一下數據庫事務的隔離級別，目前數據庫事務的隔離級別一共有 4 種，由低到高分別為：

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

數據庫一般默認的隔離級別為讀已提交，比如 Oracle，也有一些數據的默認隔離級別為可重復讀，比如 Mysql，一般而言，數據庫的讀已提交能夠滿足業務絕大部分場景了。

我們知道 Seata 的事務是一個全局事務，它包含了若干個分支本地事務，在全局事務執行過程中(全局事務還沒執行完)，某個本地事務提交了，如果 Seata 沒有采取任務措施，則會導致已提交的本地事務被讀取，造成臟讀，如果數據在全局事務提交前已提交的本地事務被修改，則會造成臟寫。

由此可以看出，傳統意義的臟讀是讀到了未提交的數據，Seata 臟讀是讀到了全局事務下未提交的數據，全局事務可能包含多個本地事務，某個本地事務提交了不代表全局事務提交了。

在絕大部分應用在讀已提交的隔離級別下工作是沒有問題的，而實際上，這當中又有絕大多數的應用場景，實際上工作在讀未提交的隔離級別下同樣沒有問題。

在極端場景下，應用如果需要達到全局的讀已提交，Seata 也提供了全局鎖機制實現全局事務讀已提交。但是默認情況下，Seata 的全局事務是工作在讀未提交隔離級別的，保證絕大多數場景的高效性。

全局鎖實現

AT 模式下，會使用 Seata 內部數據源代理 DataSourceProxy，全局鎖的實現就是隱藏在這個代理中。我們分別在執行、提交的過程都做了什么。

1、執行過程

執行過程在 StatementProxy 類，在執行過程中，如果執行 SQL 是 select for update，則會使用 SelectForUpdateExecutor 類，如果執行方法中帶有 @GlobalTransactional or @GlobalLock注解，則會檢查是否有全局鎖，如果當前存在全局鎖，則會回滾本地事務，通過 while 循環不斷地重新競爭獲取本地鎖和全局鎖。

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 注冊分支

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 注冊分支的時候，獲取全局鎖

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(); 
}

GlobalLock 注解說明

從執行過程和提交過程可以看出，既然開啟全局事務 @GlobalTransactional注解可以在事務提交前，查詢全局鎖是否存在，那為什么 Seata 還要設計多處一個 @GlobalLock注解呢?

因為并不是所有的數據庫操作都需要開啟全局事務，而開啟全局事務是一個比較重的操作，需要向 TC 發起開啟全局事務等 RPC 過程，而@GlobalLock注解只會在執行過程中查詢全局鎖是否存在，不會去開啟全局事務，因此在不需要全局事務，而又需要檢查全局鎖避免臟讀臟寫時，使用@GlobalLock注解是一個更加輕量的操作。

如何防止臟寫

先來看一下使用 Seata AT 模式是怎么產生臟寫的：

注：分支事務執行過程省略其它過程。

業務一開啟全局事務，其中包含分支事務A(修改 A)和分支事務 B(修改 B)，業務二修改 A，其中業務一執行分支事務 A 先獲取本地鎖，業務二則等待業務一執行完分支事務 A 之后，獲得本地鎖修改 A 并入庫，業務一在執行分支事務時發生異常了，由于分支事務 A 的數據被業務二修改，導致業務一的全局事務無法回滾。

如何防止臟寫?

1、業務二執行時加 @GlobalTransactional注解：