一文帶你深入理解 Spring 事務原理

作者:xiaolyuh

來源:my.oschina.net/xiaolyuh/blog/3109049

Spring 事務的基本原理

Spring 事務的本質其實就是數據庫對事務的支持,沒有數據庫的事務支持,spring 是無法提供事務功能的。對於純 JDBC 操作數據庫,想要用到事務,可以按照以下步驟進行:

  1. 獲取連接 Connection con = DriverManager.getConnection()

  2. 開啓事務 con.setAutoCommit(true/false);

  3. 執行 CRUD

  4. 提交事務 / 回滾事務 con.commit() / con.rollback();

  5. 關閉連接 conn.close();

使用 Spring 的事務管理功能後,我們可以不再寫步驟 2 和 4 的代碼,而是由 Spirng 自動完成。那麼 Spring 是如何在我們書寫的 CRUD 之前和之後開啓事務和關閉事務的呢?解決這個問題,也就可以從整體上理解 Spring 的事務管理實現原理了。

下面簡單地介紹下,註解方式爲例子

  1. 配置文件開啓註解驅動,在相關的類和方法上通過註解 @Transactional 標識。

  2. spring 在啓動的時候會去解析生成相關的 bean,這時候會查看擁有相關注解的類和方法,並且爲這些類和方法生成代理,並根據 @Transaction 的相關參數進行相關配置注入,這樣就在代理中爲我們把相關的事務處理掉了(開啓正常提交事務,異常回滾事務)。

  3. 真正的數據庫層的事務提交和回滾是通過 binlog 或者 redo log 實現的。


Spring 的事務機制

所有的數據訪問技術都有事務處理機制,這些技術提供了 API 用來開啓事務、提交事務來完成數據操作,或者在發生錯誤的時候回滾數據。

而 Spring 的事務機制是用統一的機制來處理不同數據訪問技術的事務處理。Spring 的事務機制提供了一個 PlatformTransactionManager 接口,不同的數據訪問技術的事務使用不同的接口實現,如表所示。

數據訪問技術及實現

在程序中定義事務管理器的代碼如下:

@Bean 
public PlatformTransactionManager transactionManager() { 

    JpaTransactionManager transactionManager = new JpaTransactionManager(); 
    transactionManager.setDataSource(dataSource()); 
    return transactionManager; 
}

聲明式事務

Spring 支持聲明式事務,即使用註解來選擇需要使用事務的方法,它使用 @Transactional 註解在方法上表明該方法需要事務支持。這是一個基於 AOP 的實現操作。

@Transactional 
public void saveSomething(Long  id, String name) { 
    //數據庫操作 
}

在此處需要特別注意的是,此 @Transactional 註解來自 org.springframework.transaction.annotation 包,而不是 javax.transaction。

在公衆號頂級架構師回覆 “架構整潔”,獲取驚喜禮包。

AOP 代理的兩種實現:


Java 動態代理。

具體有如下四步驟:

  1. 通過實現 InvocationHandler 接口創建自己的調用處理器;

  2. 通過爲 Proxy 類指定 ClassLoader 對象和一組 interface 來創建動態代理類;

  3. 通過反射機制獲得動態代理類的構造函數,其唯一參數類型是調用處理器接口類型;

  4. 通過構造函數創建動態代理類實例,構造時調用處理器對象作爲參數被傳入。


GCLIB 代理

cglib(Code Generation Library)是一個強大的, 高性能, 高質量的 Code 生成類庫。它可以在運行期擴展 Java 類與實現 Java 接口。


原理區別:

java 動態代理是利用反射機制生成一個實現代理接口的匿名類,在調用具體方法前調用 InvokeHandler 來處理。而 cglib 動態代理是利用 asm 開源包,對代理對象類的 class 文件加載進來,通過修改其字節碼生成子類來處理。

  1. 如果目標對象實現了接口,默認情況下會採用 JDK 的動態代理實現 AOP

  2. 如果目標對象實現了接口,可以強制使用 CGLIB 實現 AOP

  3. 如果目標對象沒有實現了接口,必須採用 CGLIB 庫,spring 會自動在 JDK 動態代理和 CGLIB 之間轉換

如果是類內部方法直接不是走代理,這個時候可以通過維護一個自身實例的代理。

@Service
public class PersonServiceImpl implements PersonService {
    @Autowired
    PersonRepository personRepository;

    // 注入自身代理對象,在本類內部方法調用事務的傳遞性纔會生效
    @Autowired
    PersonService selfProxyPersonService;

    /**
     * 測試事務的傳遞性
     *
     * @param person
     * @return
     */
    @Transactional
    public Person save(Person person) {
        Person p = personRepository.save(person);
        try {
            // 新開事務 獨立回滾
            selfProxyPersonService.delete();
        } catch (Exception e) {
            e.printStackTrace();
        }
        try {
            // 使用當前事務 全部回滾
            selfProxyPersonService.save2(person);
        } catch (Exception e) {
            e.printStackTrace();
        }
        personRepository.save(person);

        return p;
    }

    @Transactional
    public void save2(Person person) {
        personRepository.save(person);
        throw new RuntimeException();
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void delete() {
        personRepository.delete(1L);
        throw new RuntimeException();
    }
}

Spring 事務的傳播屬性

所謂 spring 事務的傳播屬性,就是定義在存在多個事務同時存在的時候,spring 應該如何處理這些事務的行爲。這些屬性在 TransactionDefinition 中定義,具體常量的解釋見下表:

數據庫隔離級別


**髒讀:**一事務對數據進行了增刪改,但未提交,另一事務可以讀取到未提交的數據。如果第一個事務這時候回滾了,那麼第二個事務就讀到了髒數據。

**不可重複讀:**一個事務中發生了兩次讀操作,第一次讀操作和第二次操作之間,另外一個事務對數據進行了修改,這時候兩次讀取的數據是不一致的。

**幻讀:**第一個事務對一定範圍的數據進行批量修改,第二個事務在這個範圍增加一條數據,這時候第一個事務就會丟失對新增數據的修改。

總結:

隔離級別越高,越能保證數據的完整性和一致性,但是對併發性能的影響也越大。

大多數的數據庫默認隔離級別爲 Read Commited,比如 SqlServer、Oracle

少數數據庫默認隔離級別爲:Repeatable Read 比如:MySQL InnoDB

Spring 中的隔離級別

事務的嵌套


通過上面的理論知識的鋪墊,我們大致知道了數據庫事務和 spring 事務的一些屬性和特點,接下來我們通過分析一些嵌套事務的場景,來深入理解 spring 事務傳播的機制。

搜索公衆號後端架構師後臺回覆 “面試”,獲取一份驚喜禮包。

假設外層事務 Service A 的 Method A() 調用 內層 Service B 的 Method B()

PROPAGATION_REQUIRED(spring 默認)

如果 ServiceB.methodB() 的事務級別定義爲 PROPAGATION_REQUIRED,那麼執行 ServiceA.methodA() 的時候 spring 已經起了事務,這時調用 ServiceB.methodB(),ServiceB.methodB() 看到自己已經運行在 ServiceA.methodA() 的事務內部,就不再起新的事務。

假如 ServiceB.methodB() 運行的時候發現自己沒有在事務中,他就會爲自己分配一個事務。

這樣,在 ServiceA.methodA() 或者在 ServiceB.methodB() 內的任何地方出現異常,事務都會被回滾。

PROPAGATION_REQUIRES_NEW

比如我們設計 ServiceA.methodA() 的事務級別爲 PROPAGATION_REQUIRED,ServiceB.methodB() 的事務級別爲 PROPAGATION_REQUIRES_NEW。

那麼當執行到 ServiceB.methodB() 的時候,ServiceA.methodA() 所在的事務就會掛起,ServiceB.methodB() 會起一個新的事務,等待 ServiceB.methodB() 的事務完成以後,它才繼續執行。

他與 PROPAGATION_REQUIRED 的事務區別在於事務的回滾程度了。因爲 ServiceB.methodB() 是新起一個事務,那麼就是存在兩個不同的事務。如果 ServiceB.methodB() 已經提交,那麼 ServiceA.methodA() 失敗回滾,ServiceB.methodB() 是不會回滾的。如果 ServiceB.methodB() 失敗回滾,如果他拋出的異常被 ServiceA.methodA() 捕獲,ServiceA.methodA() 事務仍然可能提交 (主要看 B 拋出的異常是不是 A 會回滾的異常)。

PROPAGATION_SUPPORTS

假設 ServiceB.methodB() 的事務級別爲 PROPAGATION_SUPPORTS,那麼當執行到 ServiceB.methodB() 時,如果發現 ServiceA.methodA() 已經開啓了一個事務,則加入當前的事務,如果發現 ServiceA.methodA() 沒有開啓事務,則自己也不開啓事務。這種時候,內部方法的事務性完全依賴於最外層的事務。

PROPAGATION_NESTED

現在的情況就變得比較複雜了, ServiceB.methodB() 的事務屬性被配置爲 PROPAGATION_NESTED, 此時兩者之間又將如何協作呢? ServiceB#methodB 如果 rollback, 那麼內部事務 (即 ServiceB#methodB) 將回滾到它執行前的 SavePoint 而外部事務 (即 ServiceA#methodA) 可以有以下兩種處理方式:

a、捕獲異常,執行異常分支邏輯

void methodA() { 

        try { 

            ServiceB.methodB(); 

        } catch (SomeException) { 

            // 執行其他業務, 如 ServiceC.methodC(); 

        } 

    }

這種方式也是嵌套事務最有價值的地方, 它起到了分支執行的效果, 如果 ServiceB.methodB 失敗, 那麼執行 ServiceC.methodC(), 而 ServiceB.methodB 已經回滾到它執行之前的 SavePoint, 所以不會產生髒數據 (相當於此方法從未執行過), 這種特性可以用在某些特殊的業務中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都沒有辦法做到這一點。

b、 外部事務回滾 / 提交 代碼不做任何修改, 那麼如果內部事務 (ServiceB#methodB) rollback, 那麼首先 ServiceB.methodB 回滾到它執行之前的 SavePoint(在任何情況下都會如此), 外部事務 (即 ServiceA#methodA) 將根據具體的配置決定自己是 commit 還是 rollback

另外三種事務傳播屬性基本用不到,在此不做分析。

總結

對於項目中需要使用到事務的地方,我建議開發者還是使用 spring 的 TransactionCallback 接口來實現事務,不要盲目使用 spring 事務註解,如果一定要使用註解,那麼一定要對 spring 事務的傳播機制和隔離級別有個詳細的瞭解,否則很可能發生意想不到的效果。

Spring Boot 對事務的支持

通過org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration類。我們可以看出 Spring Boot 自動開啓了對註解事務的支持 Spring

只讀事務(@Transactional(readOnly = true))的一些概念

概念:

從這一點設置的時間點開始(時間點 a)到這個事務結束的過程中,其他事務所提交的數據,該事務將看不見!(查詢中不會出現別人在時間點 a 之後提交的數據)。

@Transcational(readOnly=true) 這個註解一般會寫在業務類上,或者其方法上,用來對其添加事務控制。當括號中添加 readOnly=true, 則會告訴底層數據源,這個是一個只讀事務,對於 JDBC 而言,只讀事務會有一定的速度優化。

而這樣寫的話,事務控制的其他配置則採用默認值,事務的隔離級別 (isolation) 爲 DEFAULT, 也就是跟隨底層數據源的隔離級別,事務的傳播行爲(propagation) 則是 REQUIRED,所以還是會有事務存在,一代在代碼中拋出 RuntimeException,依然會導致事務回滾。

應用場合:

【注意是一次執行多次查詢來統計某些信息,這時爲了保證數據整體的一致性,要用只讀事務】

參考:

http://www.codeceo.com/article/spring-transactions.html
http://www.cnblogs.com/fenglie/articles/4097759.html
https://www.zhihu.com/question/39074428/answer/88581202
http://blog.csdn.net/andyzhaojianhui/article/details/51984157

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/4upfOMWYEuLc3wUQm8XvBg