建站
咨詢
售后
建站咨詢
新聞中心
一段被 try-catch 包裹后的代碼在產(chǎn)線穩(wěn)定運(yùn)行了 200 天后忽然發(fā)生了異常，而這個(gè)異常竟然導(dǎo)致了產(chǎn)線事務(wù)回滾。
創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括播州網(wǎng)站建設(shè)、播州網(wǎng)站制作、播州網(wǎng)頁(yè)制作以及播州網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃等。多年來(lái)，我們專(zhuān)注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，播州網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到播州省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
圖片來(lái)自 Pexels
這期間究竟發(fā)生了什么?日常在項(xiàng)目過(guò)程中該如何避免事務(wù)異常?就在這個(gè)時(shí)候，老板拿著《XX 公司關(guān)于三十歲員工優(yōu)化通知》走了過(guò)來(lái)......
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)把它遺忘了。
誰(shuí)也沒(méi)想到的是，它竟然以這樣一種方式重新回到了我們的視野，宣告著它的存在!
小九九是一個(gè)永遠(yuǎn) 19 歲的程序員，和所有程序員一樣地陽(yáng)光、帥氣(這句話不管你信不信，反正我自己也不信。為了能夠開(kāi)始今天的文章，就這么瞎編吧，總比以“一個(gè)沒(méi)有頭發(fā)的程序員”開(kāi)頭的好)。
當(dāng)他告訴我一段 try-catch 的代碼造成產(chǎn)線事務(wù)回滾后，我溫柔、耐心地對(duì)他說(shuō)：“滾一邊去，沒(méi)看我正忙著嗎?”，然后他給我甩出了一段代碼，用猥瑣又真誠(chéng)的眼睛告訴我，他說(shuō)的是真的。
02
我們來(lái)看一下這段導(dǎo)致了產(chǎn)線事務(wù)回滾的代碼，類(lèi)似于下面這樣的：
- @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)過(guò)嚴(yán)格的測(cè)試，而且已經(jīng) 200 天沒(méi)人碰過(guò)了。
也可能已經(jīng)有人猜出了問(wèn)題的原因了，這里先賣(mài)個(gè)關(guān)子，因?yàn)檫@件事情里，最重要的是這個(gè)坑是如何一步步產(chǎn)生的。
為了更形象地描述這個(gè)事情我畫(huà)一個(gè)圖，紅色背景表示該方法是有事務(wù)控制的，白色背景表示該方法沒(méi)有事務(wù)：
一開(kāi)始的時(shí)候，正如大家所看到的代碼，methodA 方法有事務(wù)，methodB 無(wú)事務(wù)且被 try-catch 包裹了，運(yùn)行得很完美。
過(guò)了一段時(shí)間后來(lái)到了階段二，因?yàn)橐恍┬枨笞兏略隽?methodC，該業(yè)務(wù)也依賴(lài)了 methodB，依然很完美地上線了。
過(guò)了一段時(shí)間來(lái)到了階段 3，依賴(lài) methodC 相關(guān)業(yè)務(wù)再次發(fā)生了變更，需要在 methodB 里增加一些邏輯且需要事務(wù)控制。
經(jīng)過(guò)評(píng)估確實(shí)對(duì) methodA 沒(méi)有影響，于是經(jīng)過(guò)充分測(cè)試后再次完美地上線了，然而隱藏的炸彈就在這個(gè)時(shí)候埋下了。
小伙伴們這個(gè)時(shí)候應(yīng)該已經(jīng)猜到原因了，是的，你猜的沒(méi)錯(cuò)。某一天 methodA 調(diào)用 methodB 時(shí) methodB 發(fā)生了異常，由于是繼承性事務(wù)，雖然 methodB 發(fā)生了異常被 try-catch 了，依然造成了 methodA 事務(wù)回滾。
還沒(méi)有理解的小伙伴，可以看下面這張圖：
我們可以把事務(wù)控制機(jī)制理解為上圖這樣一個(gè)紅色的長(zhǎng)長(zhǎng)的房間，這個(gè)房間是有人看守的，他負(fù)責(zé)事務(wù)的開(kāi)始、提交，還有一項(xiàng)重要的任務(wù)就是監(jiān)控異常。
一旦發(fā)現(xiàn) RuntimeException 異常直接回滾整個(gè)事務(wù)，我們給他一個(gè) title，稱(chēng)之為“監(jiān)事”吧。
再來(lái)看階段三和一開(kāi)始的代碼，方法的開(kāi)頭有一個(gè) @Transactional 注解，于是他打開(kāi)了這個(gè)紅色房間的門(mén)，把 methodA 放了進(jìn)去。
接著 methodB 過(guò)來(lái)了，也開(kāi)啟了事務(wù)--繼承性事務(wù)，于是監(jiān)事把 methodB 也安排到了這個(gè)房間。
methodB 雖然發(fā)生了異常且被 try-catch 包裹，但逃不過(guò)監(jiān)事的火眼金睛，于是他按下了事務(wù)回滾的按鈕。
這樣理解了之后，我們?cè)賮?lái)簡(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 方法。
通過(guò) 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ù)往上追溯，來(lái)到 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í)行過(guò)程參見(jiàn)注釋說(shuō)明，其它源碼就不羅列了。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ù)問(wèn)題就是：在同一個(gè)類(lèi)中，mehtodA 沒(méi)有事務(wù)，mehtodB 開(kāi)啟了(聲明式)事務(wù)。
此時(shí) mehtodA 調(diào)用 mehtodB 時(shí)事務(wù)是不生效的：
如上面這張圖所示，我們還是把 AOP 想像成一個(gè)長(zhǎng)方形的房間，由于 mehtodA 沒(méi)有事務(wù)，這個(gè)房間已經(jīng)被標(biāo)志為沒(méi)有事務(wù)無(wú)人值守了，mehtodB 雖然標(biāo)記了事務(wù)，但很顯然是不生效的。
接下來(lái)我們重新回顧一下事務(wù)的幾種配置：
- REQUIRED：支持當(dāng)前事務(wù)，如果當(dāng)前沒(méi)有事務(wù)，就新建一個(gè)事務(wù)。這是最常見(jiàn)的選擇。
- REQUIRES_NEW：新建事務(wù)，如果當(dāng)前存在事務(wù)，把當(dāng)前事務(wù)掛起。
- SUPPORTS：支持當(dāng)前事務(wù)，如果當(dāng)前沒(méi)有事務(wù)，就以非事務(wù)方式執(zhí)行。
- MANDATORY：支持當(dāng)前事務(wù)，如果當(dāng)前沒(méi)有事務(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)前沒(méi)有事務(wù)，就新建一個(gè)事務(wù)。
這方面的文章很多，這里就不做描述了。
04
事務(wù)問(wèn)題本身是比較難通過(guò)測(cè)試發(fā)現(xiàn)的，我們?cè)賮?lái)聊一聊項(xiàng)目過(guò)程中如何防止事務(wù)問(wèn)題的發(fā)生。
比如筆者之前曾負(fù)責(zé)過(guò)支付及資金處理相關(guān)系統(tǒng)，產(chǎn)品的單筆交易額比較大，每筆至少 1 萬(wàn)+，正常 10 萬(wàn)+，很多時(shí)候一筆支付就是 300 萬(wàn)，所以容不得出現(xiàn)一筆資金差錯(cuò)。好在我們資金交易從 0 做到了 3000 億，依然資金 0 差錯(cuò)。
針對(duì)可能的事務(wù)問(wèn)題，我們采取的措施有：
- 通過(guò)開(kāi)發(fā)規(guī)范、產(chǎn)線坑集等文檔、培訓(xùn)等讓開(kāi)發(fā)人員對(duì)事務(wù)有足夠的了解、敏感度。
- 系統(tǒng)設(shè)計(jì)時(shí)，對(duì)于關(guān)鍵的業(yè)務(wù)場(chǎng)景需要寫(xiě)明是否啟用了事務(wù)，哪些方法包裹在一個(gè)事務(wù)中，并進(jìn)行評(píng)審。
- 代碼 Review 環(huán)節(jié)有很多專(zhuān)項(xiàng) Review，比如資金 Review、多線程 Review 等等，也有一項(xiàng)專(zhuān)門(mén)的事務(wù) Review：需不需要加事務(wù)?事務(wù)配置是否正確?異常是否處理等。
- 開(kāi)發(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è)試。比如通過(guò)防火墻阻斷請(qǐng)求、手動(dòng)鎖表等方式來(lái)模擬可能的事務(wù)異常。
筆者在之前一家公司還有一種做法就是通過(guò)開(kāi)發(fā)規(guī)范約束：所有事務(wù)的方法全部以 tx 開(kāi)頭。
比如 methodB 方法需要開(kāi)啟事務(wù)，則新增一個(gè) txMethodB 方法，在該方法中調(diào)用 methodB。通過(guò)這種方式完全可以避免上面問(wèn)題的發(fā)生，但很顯然這種方式相當(dāng)?shù)亍俺舐薄?/p>
05
正和小九九聊著事務(wù)問(wèn)題，老板手里拿著幾張 A4 紙走了過(guò)來(lái)。
作為公司唯一的 30 歲程序員，我提高了聲音對(duì)小九九說(shuō)：你有沒(méi)有發(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)化通知》放到了抽屜一疊資料的最下面，接著又抽出來(lái)放到了資料的中間。
看來(lái)我的程序生涯，又可以持續(xù)一段時(shí)間了!
作者：劍圣
編輯：陶家龍
出處：轉(zhuǎn)載自微信公眾號(hào)碼大叔(ID：ma_dashu)
本文名稱(chēng)：一段被Try-Catch包裹的代碼，差點(diǎn)讓我丟了工作！
文章轉(zhuǎn)載：http://m.fisionsoft.com.cn/article/dhigcgg.html
