一段被Try-Catch包裹的代碼，差點讓我丟了工作！
一段被 try-catch 包裹后的代碼在產(chǎn)線穩(wěn)定運行了 200 天后忽然發(fā)生了異常，而這個異常竟然導致了產(chǎn)線事務回滾。
圖片來自 Pexels
這期間究竟發(fā)生了什么?日常在項目過程中該如何避免事務異常?就在這個時候，老板拿著《XX 公司關于三十歲員工優(yōu)化通知》走了過來......
01
產(chǎn)線部分數(shù)據(jù)丟失了，因為一個蹊蹺的事務回滾。而造成事務回滾的，竟然是一段被 try-cath 包裹后的代碼，一段已經(jīng)在產(chǎn)線穩(wěn)定運行了 200 天的代碼，穩(wěn)定到我們已經(jīng)把它遺忘了。
誰也沒想到的是，它竟然以這樣一種方式重新回到了我們的視野，宣告著它的存在!
小九九是一個永遠 19 歲的程序員，和所有程序員一樣地陽光、帥氣(這句話不管你信不信，反正我自己也不信。為了能夠開始今天的文章，就這么瞎編吧，總比以“一個沒有頭發(fā)的程序員”開頭的好)。
當他告訴我一段 try-catch 的代碼造成產(chǎn)線事務回滾后，我溫柔、耐心地對他說：“滾一邊去，沒看我正忙著嗎?”，然后他給我甩出了一段代碼，用猥瑣又真誠的眼睛告訴我，他說的是真的。
02
我們來看一下這段導致了產(chǎn)線事務回滾的代碼，類似于下面這樣的：
- @Transactional
- public void main() {
- // 假設有多個user的操作，需要事務控制
- methodA();
- try {
- orderService.methodB();
- } catch (Exception e) {
- // order失敗了不能影響該方法,不回滾。
- // 異常處理，略
- }
- userOtherProcess();
- }
methodA 方法需要事務控制，methodB 方法不管遇到什么異常都不能影響 A 事務，所以加了 try-catch。
可能有的人和我的第一反應一樣，是不是最后的 userOtherProcess 方法執(zhí)行異常造成了 methodA 的事務回滾?
小九九告訴我真的是因為 methodB，這段代碼當初經(jīng)過嚴格的測試，而且已經(jīng) 200 天沒人碰過了。
也可能已經(jīng)有人猜出了問題的原因了，這里先賣個關子，因為這件事情里，最重要的是這個坑是如何一步步產(chǎn)生的。
為了更形象地描述這個事情我畫一個圖，紅色背景表示該方法是有事務控制的，白色背景表示該方法沒有事務：
一開始的時候，正如大家所看到的代碼，methodA 方法有事務，methodB 無事務且被 try-catch 包裹了，運行得很完美。
過了一段時間后來到了階段二，因為一些需求變更新增了 methodC，該業(yè)務也依賴了 methodB，依然很完美地上線了。
過了一段時間來到了階段 3，依賴 methodC 相關業(yè)務再次發(fā)生了變更，需要在 methodB 里增加一些邏輯且需要事務控制。
經(jīng)過評估確實對 methodA 沒有影響，于是經(jīng)過充分測試后再次完美地上線了，然而隱藏的炸彈就在這個時候埋下了。
小伙伴們這個時候應該已經(jīng)猜到原因了，是的，你猜的沒錯。某一天 methodA 調用 methodB 時 methodB 發(fā)生了異常，由于是繼承性事務，雖然 methodB 發(fā)生了異常被 try-catch 了，依然造成了 methodA 事務回滾。
還沒有理解的小伙伴，可以看下面這張圖：
我們可以把事務控制機制理解為上圖這樣一個紅色的長長的房間，這個房間是有人看守的，他負責事務的開始、提交，還有一項重要的任務就是監(jiān)控異常。
一旦發(fā)現(xiàn) RuntimeException 異常直接回滾整個事務，我們給他一個 title，稱之為“監(jiān)事”吧。
再來看階段三和一開始的代碼，方法的開頭有一個 @Transactional 注解，于是他打開了這個紅色房間的門，把 methodA 放了進去。
接著 methodB 過來了，也開啟了事務--繼承性事務，于是監(jiān)事把 methodB 也安排到了這個房間。
methodB 雖然發(fā)生了異常且被 try-catch 包裹，但逃不過監(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ù)異常提示，可以看到錯誤發(fā)生在 AbstractPlatformTransactionManager 的 873 行 processRollback 方法。
通過 Find Usages 找到調用方 commit 方法，顯然這是一段事務提交的邏輯。
- @Override
- public final void commit(TransactionStatus status) throws TransactionException {
- // 為便于閱讀，刪除部分代碼
- ......
- if (!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()) {
- // 為便于閱讀，刪除部分代碼
- processRollback(defStatus, true);
- return;
- }
- processCommit(defStatus);
- }
shouldCommitOnGlobalRollbackOnly：默認實現(xiàn)是 false，意思是如果發(fā)現(xiàn)事務被標記全局回滾并且該標記不需要提交事務的話，那么則進行回滾。
defStatus.isGlobalRollbackOnly()：判斷是否是讀取 DefaultTransactionStatus 中 transaction 對象的 ConnectionHolder 的 rollbackOnly 標志位。
繼續(xù)往上追溯，來到 TransactionAspectSupport.invokeWithinTransaction 方法：
- @Nullable
- protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass,
- final InvocationCallback invocation) throws Throwable {
- // 為便于閱讀，刪除部分代碼
- ......
- // 如果是聲明式事務
- 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í)行事務方法
- retVal = invocation.proceedWithInvocation();
- }
- catch (Throwable ex) {
- // 捕獲異常，并將會把事務設置為Rollback回滾狀態(tài)。
- completeTransactionAfterThrowing(txInfo, ex);
- throw ex;
- }
- finally {
- cleanupTransactionInfo(txInfo);
- }
- // 提交事務
- commitTransactionAfterReturning(txInfo);
- return retVal;
- }
- else {
- // 聲明式事務，略
- }
- }
整個執(zhí)行過程參見注釋說明，其它源碼就不羅列了。Spring 捕獲異常后，正如我們所猜測的，事務將會被設置全局 rollback。
而最外層的事務方法執(zhí)行 commit 操作，這時由于事務狀態(tài)為 rollback，Spring 認為不應該 commit 提交事務，而應該回滾事務，所以拋出 rollback-only 異常。
03
還有一個比較典型的事務問題就是：在同一個類中，mehtodA 沒有事務，mehtodB 開啟了(聲明式)事務。
此時 mehtodA 調用 mehtodB 時事務是不生效的：
如上面這張圖所示，我們還是把 AOP 想像成一個長方形的房間，由于 mehtodA 沒有事務，這個房間已經(jīng)被標志為沒有事務無人值守了，mehtodB 雖然標記了事務，但很顯然是不生效的。
接下來我們重新回顧一下事務的幾種配置：
- REQUIRED：支持當前事務，如果當前沒有事務，就新建一個事務。這是最常見的選擇。
- REQUIRES_NEW：新建事務，如果當前存在事務，把當前事務掛起。
- SUPPORTS：支持當前事務，如果當前沒有事務，就以非事務方式執(zhí)行。
- MANDATORY：支持當前事務，如果當前沒有事務，就拋出異常。
- NEVER：以非事務方式執(zhí)行，如果當前存在事務，則拋出異常。
- NOT_SUPPORTED：以非事務方式執(zhí)行操作，如果當前存在事務，就把當前事務掛起。
- NESTED：支持當前事務，如果當前事務存在，則執(zhí)行一個嵌套事務，如果當前沒有事務，就新建一個事務。
這方面的文章很多，這里就不做描述了。
04
事務問題本身是比較難通過測試發(fā)現(xiàn)的，我們再來聊一聊項目過程中如何防止事務問題的發(fā)生。
比如筆者之前曾負責過支付及資金處理相關系統(tǒng)，產(chǎn)品的單筆交易額比較大，每筆至少 1 萬+，正常 10 萬+，很多時候一筆支付就是 300 萬，所以容不得出現(xiàn)一筆資金差錯。好在我們資金交易從 0 做到了 3000 億，依然資金 0 差錯。
針對可能的事務問題，我們采取的措施有：
- 通過開發(fā)規(guī)范、產(chǎn)線坑集等文檔、培訓等讓開發(fā)人員對事務有足夠的了解、敏感度。
- 系統(tǒng)設計時，對于關鍵的業(yè)務場景需要寫明是否啟用了事務，哪些方法包裹在一個事務中，并進行評審。
- 代碼 Review 環(huán)節(jié)有很多專項 Review，比如資金 Review、多線程 Review 等等，也有一項專門的事務 Review：需不需要加事務?事務配置是否正確?異常是否處理等。
- 開發(fā)人員構造事務異常場景進行自測、交叉驗證。
- 測試團隊參與系統(tǒng)設計評審，并進行事務相關測試。比如通過防火墻阻斷請求、手動鎖表等方式來模擬可能的事務異常。
筆者在之前一家公司還有一種做法就是通過開發(fā)規(guī)范約束：所有事務的方法全部以 tx 開頭。
比如 methodB 方法需要開啟事務，則新增一個 txMethodB 方法，在該方法中調用 methodB。通過這種方式完全可以避免上面問題的發(fā)生，但很顯然這種方式相當?shù)?ldquo;丑陋”。
05
正和小九九聊著事務問題，老板手里拿著幾張 A4 紙走了過來。
作為公司唯一的 30 歲程序員，我提高了聲音對小九九說：你有沒有發(fā)現(xiàn) @Transactional 中還有一個配置項 readOnly，如果需要使用這個參數(shù)，必須啟動一個事務。
但如果是讀取數(shù)據(jù)，根本就不需要事務啊?為什么會有這么一個自相矛盾的配置項呢?小九九一臉茫然地搖了搖頭。
老板沖我點了點頭，轉身回到了辦公室，坐下思考了一會，然后把手里的 A4 紙《XX 公司關于三十歲員工優(yōu)化通知》放到了抽屜一疊資料的最下面，接著又抽出來放到了資料的中間。
看來我的程序生涯，又可以持續(xù)一段時間了!
作者：劍圣
編輯：陶家龍
出處：轉載自微信公眾號碼大叔(ID：ma_dashu)
