你有思考過@Transactional事務(wù)是真的好用嗎？

作者：派大星 2024-04-07 00:00:05

實(shí)際上，若對(duì)阿里巴巴發(fā)布的Java開發(fā)手冊(cè)有過深入研讀，便會(huì)發(fā)現(xiàn)其中很多規(guī)約非常珍貴，有些內(nèi)容可能不易理解，甚至顯得有些生硬。然而，這些規(guī)范實(shí)則由無數(shù)開發(fā)者在實(shí)戰(zhàn)中摸爬滾打后總結(jié)而來。其實(shí)有些東西都是實(shí)踐出真知。

事務(wù)管理在系統(tǒng)開發(fā)中舉足輕重，Spring提供了精妙細(xì)膩的事務(wù)管理機(jī)制，主要分為編程式事務(wù)和聲明式事務(wù)兩大架構(gòu)。

關(guān)于事務(wù)的根本概念，包括事務(wù)的本質(zhì)、數(shù)據(jù)庫中的事務(wù)特性以及Spring事務(wù)的ACID屬性、隔離級(jí)別、傳播規(guī)則和行為方式等，本文將不做深入探討。我也相信讀者對(duì)此有一定的了解。

筆者將以簡(jiǎn)潔方式闡述聲明式事務(wù)和編程式事務(wù)的概念，隨后探討筆者不推崇使用聲明式事務(wù)的理由。

編程式事務(wù)

借助底層API，如PlatformTransactionManager、TransactionDefinition和TransactionTemplate等核心接口，開發(fā)者能夠以編程的方式精準(zhǔn)地進(jìn)行事務(wù)管理。

在編程式事務(wù)模式中，開發(fā)者需在代碼中手動(dòng)管理事務(wù)的啟動(dòng)、提交和回滾等操作。

偽代碼：

public void test() {
    TransactionDefinition definition = new DefaultTransactionDefinition();
    TransactionStatus status = transactionManager.getTransaction(definition);

    try {
        // 執(zhí)行事務(wù)操作
        // 提交事務(wù)
        transactionManager.commit(status);
    } catch (DataAccessException e) {
        // 回滾事務(wù)
        transactionManager.rollback(status);
        throw e;
    }
}

如以上代碼，開發(fā)者可以通過API自己控制事務(wù)。

聲明式事務(wù)

聲明式事務(wù)管理方式允許開發(fā)者在配置的指引下進(jìn)行事務(wù)管理，無需直接操作底層API進(jìn)行硬編碼。開發(fā)者可以通過注解或基于配置的XML來便捷地管理事務(wù)。

@Transactional
public void test() {
    // 執(zhí)行事務(wù)操作  
}

如上使用@Transactional注解即可為test方法添加事務(wù)控制。

當(dāng)然，以上代碼只是簡(jiǎn)化的版本，實(shí)際使用事務(wù)還需要進(jìn)行一些配置。這里不展開詳細(xì)說明。

這兩種事務(wù)管理方式各有優(yōu)缺點(diǎn)，所適用的場(chǎng)景也各有不同。為什么有人會(huì)拒絕使用聲明式事務(wù)呢？

聲明式事務(wù)的優(yōu)點(diǎn)

通過上面的例子，我們很容易看出聲明式事務(wù)的優(yōu)點(diǎn)：它幫助我們節(jié)省大量代碼，自動(dòng)處理事務(wù)啟動(dòng)、提交和回滾等操作，使開發(fā)人員擺脫繁瑣的事務(wù)管理工作。

聲明式事務(wù)管理是通過AOP實(shí)現(xiàn)的，其本質(zhì)是在目標(biāo)方法執(zhí)行前后進(jìn)行攔截。在執(zhí)行方法之前創(chuàng)建或加入一個(gè)事務(wù)，在方法執(zhí)行結(jié)束后根據(jù)情況選擇提交或回滾事務(wù)。

這種方式不會(huì)對(duì)代碼造成侵入性，方法內(nèi)只需編寫業(yè)務(wù)邏輯即可。

然而，是否聲明式事務(wù)就一定完美無缺呢？未必如此。

聲明式事務(wù)的粒度問題

首先，聲明式事務(wù)存在一個(gè)限制，即其最小作用粒度應(yīng)為方法級(jí)別。

換言之，若想向某段代碼塊添加事務(wù)，就需要將該代碼塊獨(dú)立出來作為一個(gè)獨(dú)立方法。

然而，正是由于這個(gè)粒度問題，我個(gè)人并不贊成過度使用聲明式事務(wù)。注意是不建議過度使用，是過度使用

首先，由于聲明式事務(wù)通常是通過注解或配置實(shí)現(xiàn)的，這可能導(dǎo)致一個(gè)問題，即開發(fā)者有可能忽略了該事務(wù)。

事務(wù)被忽略會(huì)帶來什么問題呢？

首先，如果開發(fā)者未注意到某個(gè)方法被包裹在事務(wù)中，就可能在方法內(nèi)執(zhí)行諸如RPC遠(yuǎn)程調(diào)用、消息發(fā)送、緩存更新、文件寫入等操作。

我們知道，這些操作本身無法回滾，這會(huì)導(dǎo)致數(shù)據(jù)不一致。

例如，RPC調(diào)用成功但本地事務(wù)回滾，此時(shí)RPC調(diào)用無法回滾。
其次，在事務(wù)中存在遠(yuǎn)程調(diào)用將延長(zhǎng)整個(gè)事務(wù)周期。若這種操作過于頻繁，可能導(dǎo)致數(shù)據(jù)庫連接池耗盡。
有時(shí)，即使沒有遠(yuǎn)程操作，某些人可能會(huì)不經(jīng)意地進(jìn)行一些內(nèi)存操作或運(yùn)算。或者在分庫分表情況下，可能會(huì)意外執(zhí)行跨庫操作。

相比之下，如果使用編程式事務(wù)，業(yè)務(wù)代碼將清晰表示何處啟動(dòng)、提交和回滾事務(wù)。這樣，修改代碼時(shí)，開發(fā)人員將被迫考慮所添加代碼是否應(yīng)該處于事務(wù)內(nèi)。

有人或許會(huì)認(rèn)為已經(jīng)存在聲明式事務(wù)，但是開發(fā)人員未留意，這該責(zé)怪誰。

盡管如此說，我們?nèi)韵Ｍㄟ^一些機(jī)制或規(guī)范，減少此類問題發(fā)生的可能性。

例如，建議大家使用編程式事務(wù)而非聲明式事務(wù)。我在多年的工作中多次遇到開發(fā)者未留意聲明式事務(wù)而導(dǎo)致故障。

因?yàn)橛袝r(shí)，聲明式事務(wù)確實(shí)不夠顯著。

聲明式事務(wù)若用錯(cuò)易失效

除了事務(wù)粒度問題外，聲明式事務(wù)還存在另一主要問題，即使看似簡(jiǎn)化了大量代碼，一旦使用不當(dāng)，便很容易導(dǎo)致事務(wù)失效。

以下幾種情景可能導(dǎo)致聲明式事務(wù)失效：

將 @Transactional 應(yīng)用于非公有（non-public）方法
@Transactional 注解中的 propagation 屬性設(shè)置錯(cuò)誤
@Transactional 注解中的 rollbackFor 屬性設(shè)置錯(cuò)誤
同一類中的方法調(diào)用會(huì)使 @Transactional 失效
異常被捕獲導(dǎo)致 @Transactional 失效
數(shù)據(jù)庫引擎不支持事務(wù)

經(jīng)歷過聲明式事務(wù)失效問題

我們團(tuán)隊(duì)不止一次遭遇聲明式事務(wù)失效的情況。或許您也曾有此經(jīng)歷，我是深受其害的一位。

由于Spring事務(wù)基于AOP實(shí)現(xiàn)，在編碼中，我們可能涉及多個(gè)切面，這些切面各自處理不同事務(wù)，相互影響。

在之前的一個(gè)項(xiàng)目中，我曾發(fā)現(xiàn)我們的Service層事務(wù)全部失效，一旦SQL操作失敗未能回滾。我們追查后才發(fā)現(xiàn)，是因?yàn)橐晃煌绿砑恿艘粋€(gè)切面，其中實(shí)施了異常統(tǒng)一捕獲，導(dǎo)致事務(wù)切面無法捕獲異常，從而無法回滾事務(wù)。

此類問題不僅一次發(fā)生，而且難以察覺。

許多人可能會(huì)辯解，畢竟問題源于自身能力不足，對(duì)事務(wù)理解還不夠透徹，因此出現(xiàn)誤用。

然而，我依舊堅(jiān)持認(rèn)為，我們確實(shí)無法期望每個(gè)人都具備高超技能，也不可能要求所有開發(fā)者都能百分之百避免錯(cuò)誤。我們能做的，是盡力通過機(jī)制或規(guī)范，減少或降低此類問題的發(fā)生幾率。

關(guān)于@Transactional的用法，規(guī)約中也有提到過，只不過規(guī)約中的觀點(diǎn)沒有我這么鮮明。