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

語言: CN / TW / HK

時間 2021-12-27 08:41:05 後端進階

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

為什麼要檢查全域性鎖呢，這是由於 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 迴圈不斷地重新競爭獲取本地鎖和全域性鎖。

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

GlobalLock 註解說明

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

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

如何防止髒寫

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

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

業務一開啟全域性事務，其中包含分支事務A（修改 A）和分支事務 B（修改 B），業務二修改 A，其中業務一執行分支事務 A 先獲取本地鎖，業務二則等待業務一執行完分支事務 A 之後，獲得本地鎖修改 A 併入庫，業務一在執行分支事務時發生異常了，由於分支事務 A 的資料被業務二修改，導致業務一的全域性事務無法回滾。

如何防止髒寫？

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