一段被 try-catch 包裹后的代碼在產(chǎn)線穩(wěn)定運(yùn)行了 200 天后忽然發(fā)生了異常，而這個(gè)異常竟然導(dǎo)致了產(chǎn)線事務(wù)回滾。

[[328106]]

圖片來自 Pexels

這期間究竟發(fā)生了什么?日常在項(xiàng)目過程中該如何避免事務(wù)異常?就在這個(gè)時(shí)候，老板拿著《XX 公司關(guān)于三十歲員工優(yōu)化通知》走了過來......

01

產(chǎn)線部分?jǐn)?shù)據(jù)丟失了，因?yàn)橐粋€(gè)蹊蹺的事務(wù)回滾。而造成事務(wù)回滾的，竟然是一段被 try-cath 包裹后的代碼，一段已經(jīng)在產(chǎn)線穩(wěn)定運(yùn)行了 200 天的代碼，穩(wěn)定到我們已經(jīng)把它遺忘了。

誰也沒想到的是，它竟然以這樣一種方式重新回到了我們的視野，宣告著它的存在!

小九九是一個(gè)永遠(yuǎn) 19 歲的程序員，和所有程序員一樣地陽光、帥氣(這句話不管你信不信，反正我自己也不信。為了能夠開始今天的文章，就這么瞎編吧，總比以“一個(gè)沒有頭發(fā)的程序員”開頭的好)。

當(dāng)他告訴我一段 try-catch 的代碼造成產(chǎn)線事務(wù)回滾后，我溫柔、耐心地對(duì)他說：“滾一邊去，沒看我正忙著嗎?”，然后他給我甩出了一段代碼，用猥瑣又真誠的眼睛告訴我，他說的是真的。

02

我們來看一下這段導(dǎo)致了產(chǎn)線事務(wù)回滾的代碼，類似于下面這樣的：

@Transactional 
public void main() { 
    // 假設(shè)有多個(gè)user的操作，需要事務(wù)控制 
    methodA(); 
 
    try { 
        orderService.methodB(); 
    } catch (Exception e) { 
        // order失敗了不能影響該方法,不回滾。 
        // 異常處理，略 
    } 
    userOtherProcess(); 
} 

methodA 方法需要事務(wù)控制，methodB 方法不管遇到什么異常都不能影響 A 事務(wù)，所以加了 try-catch。

可能有的人和我的第一反應(yīng)一樣，是不是最后的 userOtherProcess 方法執(zhí)行異常造成了 methodA 的事務(wù)回滾?

小九九告訴我真的是因?yàn)?methodB，這段代碼當(dāng)初經(jīng)過嚴(yán)格的測(cè)試，而且已經(jīng) 200 天沒人碰過了。

也可能已經(jīng)有人猜出了問題的原因了，這里先賣個(gè)關(guān)子，因?yàn)檫@件事情里，最重要的是這個(gè)坑是如何一步步產(chǎn)生的。

為了更形象地描述這個(gè)事情我畫一個(gè)圖，紅色背景表示該方法是有事務(wù)控制的，白色背景表示該方法沒有事務(wù)：

一開始的時(shí)候，正如大家所看到的代碼，methodA 方法有事務(wù)，methodB 無事務(wù)且被 try-catch 包裹了，運(yùn)行得很完美。

過了一段時(shí)間后來到了階段二，因?yàn)橐恍┬枨笞兏略隽?methodC，該業(yè)務(wù)也依賴了 methodB，依然很完美地上線了。

過了一段時(shí)間來到了階段 3，依賴 methodC 相關(guān)業(yè)務(wù)再次發(fā)生了變更，需要在 methodB 里增加一些邏輯且需要事務(wù)控制。

經(jīng)過評(píng)估確實(shí)對(duì) methodA 沒有影響，于是經(jīng)過充分測(cè)試后再次完美地上線了，然而隱藏的炸彈就在這個(gè)時(shí)候埋下了。

小伙伴們這個(gè)時(shí)候應(yīng)該已經(jīng)猜到原因了，是的，你猜的沒錯(cuò)。某一天 methodA 調(diào)用 methodB 時(shí) methodB 發(fā)生了異常，由于是繼承性事務(wù)，雖然 methodB 發(fā)生了異常被 try-catch 了，依然造成了 methodA 事務(wù)回滾。

還沒有理解的小伙伴，可以看下面這張圖：

我們可以把事務(wù)控制機(jī)制理解為上圖這樣一個(gè)紅色的長(zhǎng)長(zhǎng)的房間，這個(gè)房間是有人看守的，他負(fù)責(zé)事務(wù)的開始、提交，還有一項(xiàng)重要的任務(wù)就是監(jiān)控異常。

一旦發(fā)現(xiàn) RuntimeException 異常直接回滾整個(gè)事務(wù)，我們給他一個(gè) title，稱之為“監(jiān)事”吧。

再來看階段三和一開始的代碼，方法的開頭有一個(gè) @Transactional 注解，于是他打開了這個(gè)紅色房間的門，把 methodA 放了進(jìn)去。

接著 methodB 過來了，也開啟了事務(wù)--繼承性事務(wù)，于是監(jiān)事把 methodB 也安排到了這個(gè)房間。

methodB 雖然發(fā)生了異常且被 try-catch 包裹，但逃不過監(jiān)事的火眼金睛，于是他按下了事務(wù)回滾的按鈕。

這樣理解了之后，我們?cè)賮砗?jiǎn)單看一下源碼：

org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only 
    at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:873) 
    at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:710) 
    at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:534) 

根據(jù)異常提示，可以看到錯(cuò)誤發(fā)生在 AbstractPlatformTransactionManager 的 873 行 processRollback 方法。

通過 Find Usages 找到調(diào)用方 commit 方法，顯然這是一段事務(wù)提交的邏輯。

@Override 
public final void commit(TransactionStatus status) throws TransactionException { 
    // 為便于閱讀，刪除部分代碼 
    ...... 
 if (!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()) { 
  // 為便于閱讀，刪除部分代碼 
  processRollback(defStatus, true); 
  return; 
 } 
 processCommit(defStatus); 
} 

shouldCommitOnGlobalRollbackOnly：默認(rèn)實(shí)現(xiàn)是 false，意思是如果發(fā)現(xiàn)事務(wù)被標(biāo)記全局回滾并且該標(biāo)記不需要提交事務(wù)的話，那么則進(jìn)行回滾。

defStatus.isGlobalRollbackOnly()：判斷是否是讀取 DefaultTransactionStatus 中 transaction 對(duì)象的 ConnectionHolder 的 rollbackOnly 標(biāo)志位。

繼續(xù)往上追溯，來到 TransactionAspectSupport.invokeWithinTransaction 方法：

@Nullable 
protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass, 
  final InvocationCallback invocation) throws Throwable { 
 // 為便于閱讀，刪除部分代碼 
    ...... 
    // 如果是聲明式事務(wù) 
 if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) { 
  // Standard transaction demarcation with getTransaction and commit/rollback calls. 
  TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification); 
 
  Object retVal; 
  try { 
   // This is an around advice: Invoke the next interceptor in the chain. 
   // This will normally result in a target object being invoked. 
   // 執(zhí)行事務(wù)方法 
   retVal = invocation.proceedWithInvocation(); 
  } 
  catch (Throwable ex) { 
   // 捕獲異常，并將會(huì)把事務(wù)設(shè)置為Rollback回滾狀態(tài)。 
   completeTransactionAfterThrowing(txInfo, ex); 
   throw ex; 
  } 
  finally { 
   cleanupTransactionInfo(txInfo); 
  } 
  // 提交事務(wù) 
  commitTransactionAfterReturning(txInfo); 
  return retVal; 
 } 
 
 else { 
  // 聲明式事務(wù)，略 
 } 
} 

整個(gè)執(zhí)行過程參見注釋說明，其它源碼就不羅列了。Spring 捕獲異常后，正如我們所猜測(cè)的，事務(wù)將會(huì)被設(shè)置全局 rollback。

而最外層的事務(wù)方法執(zhí)行 commit 操作，這時(shí)由于事務(wù)狀態(tài)為 rollback，Spring 認(rèn)為不應(yīng)該 commit 提交事務(wù)，而應(yīng)該回滾事務(wù)，所以拋出 rollback-only 異常。

03

還有一個(gè)比較典型的事務(wù)問題就是：在同一個(gè)類中，mehtodA 沒有事務(wù)，mehtodB 開啟了(聲明式)事務(wù)。

此時(shí) mehtodA 調(diào)用 mehtodB 時(shí)事務(wù)是不生效的：

如上面這張圖所示，我們還是把 AOP 想像成一個(gè)長(zhǎng)方形的房間，由于 mehtodA 沒有事務(wù)，這個(gè)房間已經(jīng)被標(biāo)志為沒有事務(wù)無人值守了，mehtodB 雖然標(biāo)記了事務(wù)，但很顯然是不生效的。

接下來我們重新回顧一下事務(wù)的幾種配置：

• REQUIRED：支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就新建一個(gè)事務(wù)。這是最常見的選擇。
• REQUIRES_NEW：新建事務(wù)，如果當(dāng)前存在事務(wù)，把當(dāng)前事務(wù)掛起。
• SUPPORTS：支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就以非事務(wù)方式執(zhí)行。
• MANDATORY：支持當(dāng)前事務(wù)，如果當(dāng)前沒有事務(wù)，就拋出異常。
• NEVER：以非事務(wù)方式執(zhí)行，如果當(dāng)前存在事務(wù)，則拋出異常。
• NOT_SUPPORTED：以非事務(wù)方式執(zhí)行操作，如果當(dāng)前存在事務(wù)，就把當(dāng)前事務(wù)掛起。
• NESTED：支持當(dāng)前事務(wù)，如果當(dāng)前事務(wù)存在，則執(zhí)行一個(gè)嵌套事務(wù)，如果當(dāng)前沒有事務(wù)，就新建一個(gè)事務(wù)。

這方面的文章很多，這里就不做描述了。

04

事務(wù)問題本身是比較難通過測(cè)試發(fā)現(xiàn)的，我們?cè)賮砹囊涣捻?xiàng)目過程中如何防止事務(wù)問題的發(fā)生。

比如筆者之前曾負(fù)責(zé)過支付及資金處理相關(guān)系統(tǒng)，產(chǎn)品的單筆交易額比較大，每筆至少 1 萬+，正常 10 萬+，很多時(shí)候一筆支付就是 300 萬，所以容不得出現(xiàn)一筆資金差錯(cuò)。好在我們資金交易從 0 做到了 3000 億，依然資金 0 差錯(cuò)。

針對(duì)可能的事務(wù)問題，我們采取的措施有：

• 通過開發(fā)規(guī)范、產(chǎn)線坑集等文檔、培訓(xùn)等讓開發(fā)人員對(duì)事務(wù)有足夠的了解、敏感度。
• 系統(tǒng)設(shè)計(jì)時(shí)，對(duì)于關(guān)鍵的業(yè)務(wù)場(chǎng)景需要寫明是否啟用了事務(wù)，哪些方法包裹在一個(gè)事務(wù)中，并進(jìn)行評(píng)審。
• 代碼 Review 環(huán)節(jié)有很多專項(xiàng) Review，比如資金 Review、多線程 Review 等等，也有一項(xiàng)專門的事務(wù) Review：需不需要加事務(wù)?事務(wù)配置是否正確?異常是否處理等。
• 開發(fā)人員構(gòu)造事務(wù)異常場(chǎng)景進(jìn)行自測(cè)、交叉驗(yàn)證。
• 測(cè)試團(tuán)隊(duì)參與系統(tǒng)設(shè)計(jì)評(píng)審，并進(jìn)行事務(wù)相關(guān)測(cè)試。比如通過防火墻阻斷請(qǐng)求、手動(dòng)鎖表等方式來模擬可能的事務(wù)異常。

筆者在之前一家公司還有一種做法就是通過開發(fā)規(guī)范約束：所有事務(wù)的方法全部以 tx 開頭。

比如 methodB 方法需要開啟事務(wù)，則新增一個(gè) txMethodB 方法，在該方法中調(diào)用 methodB。通過這種方式完全可以避免上面問題的發(fā)生，但很顯然這種方式相當(dāng)?shù)?ldquo;丑陋”。

05

正和小九九聊著事務(wù)問題，老板手里拿著幾張 A4 紙走了過來。

作為公司唯一的 30 歲程序員，我提高了聲音對(duì)小九九說：你有沒有發(fā)現(xiàn) @Transactional 中還有一個(gè)配置項(xiàng) readOnly，如果需要使用這個(gè)參數(shù)，必須啟動(dòng)一個(gè)事務(wù)。

但如果是讀取數(shù)據(jù)，根本就不需要事務(wù)啊?為什么會(huì)有這么一個(gè)自相矛盾的配置項(xiàng)呢?小九九一臉茫然地?fù)u了搖頭。

老板沖我點(diǎn)了點(diǎn)頭，轉(zhuǎn)身回到了辦公室，坐下思考了一會(huì)，然后把手里的 A4 紙《XX 公司關(guān)于三十歲員工優(yōu)化通知》放到了抽屜一疊資料的最下面，接著又抽出來放到了資料的中間。

看來我的程序生涯，又可以持續(xù)一段時(shí)間了!

作者：劍圣

編輯：陶家龍

出處：轉(zhuǎn)載自微信公眾號(hào)碼大叔(ID：ma_dashu)