踩坑指南：從@Transactional失效到性能殺手，大廠為何慎用)
在Java后端圈子里Transactional幾乎是每個Spring開發(fā)者最早接觸的幾個注解之一。剛?cè)胄械臅r候很多人對它的理解就是“在方法上加上這個注解方法里的數(shù)據(jù)庫操作要么全成功要么全失敗”省去了手動begin、commit、rollback的樣板代碼看起來確實是神器。但在大廠里待過幾年后你會發(fā)現(xiàn)代碼評審時如果有人在核心鏈路上直接甩一個Transactional大概率會被追問“這個事務(wù)是非開不可嗎能不能去掉”不是大廠故意刁難而是這個注解背后的坑遠(yuǎn)比表面看上去的要多。這篇文章我想從實際踩坑經(jīng)歷出發(fā)把Transactional在真實業(yè)務(wù)場景里的“原罪”講清楚。它為什么會失效、什么時候會拖垮性能、單庫事務(wù)在分布式環(huán)境下又是怎么變成隱患的、以及大廠更傾向于用什么方案替代。不管是剛寫Spring沒多久的新人還是被線上事故折騰過的老手這篇文章應(yīng)該都能給你一些參考。1. 內(nèi)容整體設(shè)計與思路拆解在展開細(xì)節(jié)之前我想先聊聊為什么大家會集中吐槽Transactional。它本身不是壞東西但因為它太“方便”了反而容易被人用在不合適的地方。理解這個問題的關(guān)鍵在于要弄清楚一件事事務(wù)的本質(zhì)是鎖和日志的組合而鎖意味著串行化日志意味著額外的IO開銷。1.1 從一次線上事故說起誰動了我的數(shù)據(jù)我之前帶過一個支付對賬相關(guān)的項目有一個“批量入賬”的接口。當(dāng)時新來的同學(xué)很自然地在這個方法上加了Transactional他的邏輯很簡單把所有入賬操作放在一個事務(wù)里任何一個失敗就全部回滾這樣數(shù)據(jù)不會出現(xiàn)“一半成功一半失敗”的狀態(tài)。聽起來毫無問題對不對但上線后第三天線上就開始出現(xiàn)大量超時告警。我讓他查數(shù)據(jù)庫慢查詢?nèi)罩窘Y(jié)果發(fā)現(xiàn)表雖然不大但大量SQL都集中在同一行記錄上長時間持鎖。再追下去發(fā)現(xiàn)這個批量入賬方法在事務(wù)里還調(diào)用了一個遠(yuǎn)程賬戶通知服務(wù)網(wǎng)速稍微抖一下事務(wù)就遲遲不提交鎖就捏在手里不放。這個案例非常典型他做對了事務(wù)的一致性保證卻忽略了事務(wù)的隔離性代價。一個簡單的Transactional把“批量寫庫”和“外部RPC調(diào)用”綁定在了同一個生命周期里。類似的問題在大廠代碼評審中幾乎是每周都會出現(xiàn)。1.2 大廠不推薦的真正理由不是禁用而是慎用大廠并不是給Transactional判了死刑而是把它從“默認(rèn)選項”降級成了“需要充分理由才能使用”。核心原因是三方面的職責(zé)邊界被破壞一個方法一旦加了事務(wù)這個方法的邏輯就被迫變成一個原子單元。但現(xiàn)實業(yè)務(wù)中很多操作天然就是“可補(bǔ)償”的不需要原子化。性能邊界模糊事務(wù)的隔離級別、傳播行為、鎖粒度很多人并沒有真正理解。默認(rèn)配置直接套上去長事務(wù)、大事務(wù)、死鎖問題接踵而至。分布式環(huán)境下能力不足單庫事務(wù)只能在本地生效一旦涉及微服務(wù)間調(diào)用、消息隊列、多數(shù)據(jù)源Transactional反而給人制造“我好像有事務(wù)保護(hù)”的錯覺。所以我更愿意把這篇內(nèi)容理解為什么時候你別用Transactional以及如果你真的要用怎么把風(fēng)險降到最低。2. 核心細(xì)節(jié)解析與實操要點可能有人會覺得“不就是一個注解嗎我用了這么多年也沒出過事?！蹦俏抑荒苷f你比較幸運還沒有被線上事故教育過。下面我挑幾個最容易踩的坑展開說一下這些都是我在實際項目里真真切切遇到過的。2.1 事務(wù)失效的若干種姿勢如果面試被問到“Transactional為什么會失效”很多人能回答出“自調(diào)用失效”和“異常被吞了”這兩條。但真實場景里的失效情況遠(yuǎn)不止這兩類我整理了一個我親手排查過的問題列表失效場景真實原因現(xiàn)象同類內(nèi)部方法調(diào)用this.xxx()不走代理對象事務(wù)切面不生效異常拋出但數(shù)據(jù)部分更新try-catch吞掉異常Spring默認(rèn)只對RuntimeException回滾異常沒拋出去數(shù)據(jù)出現(xiàn)“半成功”狀態(tài)方法不是publicSpring AOP默認(rèn)只攔截public方法事務(wù)不生效數(shù)據(jù)庫引擎不支持事務(wù)比如MyISAM表寫操作照常但無法回滾多線程調(diào)用事務(wù)上下文不傳遞到子線程子線程里的寫操作不在事務(wù)內(nèi)每個場景背后幾乎都有一次血淚線上事故。拿“異常被吞”來說很多同學(xué)寫代碼時喜歡在catch塊里記錄日志然后返回一個錯誤碼這在普通業(yè)務(wù)方法里沒問題但如果方法上有Transactional事務(wù)不會因為你返回了錯誤碼就回滾。你必須在catch塊里手動TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()否則數(shù)據(jù)就悄悄寫進(jìn)去了。2.2 默認(rèn)隔離級別與鎖升級MySQL 默認(rèn)的隔離級別是REPEATABLE_READ也就是可重復(fù)讀。Spring 的Transactional如果你不指定isolation屬性它走的是數(shù)據(jù)庫默認(rèn)隔離級別所以大多數(shù)情況下你實際用的是REPEATABLE_READ。這有什么問題呢REPEATABLE_READ為了保證同一事務(wù)內(nèi)多次讀取結(jié)果一致會在SELECT上加S鎖共享鎖在UPDATE/DELETE上加X鎖排他鎖。在高并發(fā)寫入場景下多個事務(wù)同時更新同一行或相鄰的索引范圍就容易觸發(fā)間隙鎖Gap Lock和Next-Key Lock進(jìn)而產(chǎn)生死鎖。舉個我在訂單系統(tǒng)中實際遇到過的案例有一個“訂單自動確認(rèn)收貨”的定時任務(wù)和用戶手動點擊“確認(rèn)收貨”的接口都會去更新同一批訂單的狀態(tài)。兩個事務(wù)同時掃描status 待收貨的訂單區(qū)間時互相持有了對方需要的間隙鎖MySQL 檢測到死鎖后會隨機(jī)kill掉一個事務(wù)。被kill的那個事務(wù)如果沒有正確處理死鎖異常用戶就會看到“操作失敗”。這類問題用Transactional不是完全不能解決但你得非常清楚自己操作的數(shù)據(jù)范圍、索引設(shè)計、鎖順序任何一環(huán)沒考慮到就是一個隱患。2.3 事務(wù)內(nèi)調(diào)用遠(yuǎn)程RPC時間黑洞這是我認(rèn)為最不值得踩的坑。在事務(wù)方法里調(diào)用RPC、HTTP接口、消息發(fā)送、文件上傳本質(zhì)上是在用一個數(shù)據(jù)庫事務(wù)去控制一個毫秒級甚至秒級延遲的外部系統(tǒng)。這么做有兩個后果事務(wù)持有時間變長數(shù)據(jù)庫連接池被長期占用高并發(fā)下連接耗盡外部系統(tǒng)調(diào)用失敗時事務(wù)回滾了但外部系統(tǒng)已經(jīng)做了操作兩邊數(shù)據(jù)不一致。我見過最夸張的一個案例是有人在一個Transactional方法里循環(huán)調(diào)用了20多次外部供應(yīng)商接口每次平均耗時300毫秒。一次請求這個事務(wù)至少要跑6秒數(shù)據(jù)庫連接直接被卡死。這已經(jīng)不是在寫事務(wù)性代碼了這是在制造線上事故。正確的做法是什么把外部調(diào)用放在事務(wù)外或者干脆去掉事務(wù)靠狀態(tài)機(jī)重試冪等來控制數(shù)據(jù)一致性。這個后面我會詳細(xì)講。3. 實操過程與核心環(huán)節(jié)實現(xiàn)既然吐槽了這么多那總得告訴你怎么做是合理的。下面我結(jié)合幾個真實場景分別給出“別用Transactional的替代方案”以及“如果確實要用怎么把傷害降到最低”。3.1 方案一用自研輕量級事務(wù)工具類控制邊界大廠里很多基礎(chǔ)架構(gòu)團(tuán)隊會給業(yè)務(wù)方提供一個TransactionTemplate的封裝核心思路就是把事務(wù)邊界顯式化而不是靠注解的隱式切面。你可以在代碼里精確控制“在哪個方法里開啟事務(wù)、在哪個節(jié)點提交”。Service public class OrderService { Autowired private TransactionTemplate transactionTemplate; Autowired private OrderMapper orderMapper; Autowired private AccountService accountService; public void createOrder(OrderDO order) { // 前置校驗、冪等檢查都可以放在事務(wù)外面 boolean created transactionTemplate.execute(status - { try { orderMapper.insert(order); // 注意這里不要調(diào)RPC只做純DB操作 return true; } catch (Exception e) { status.setRollbackOnly(); throw e; } }); if (created) { // 事務(wù)提交之后再發(fā)MQ通知、調(diào)外部接口 accountService.deductBalance(order.getUserId(), order.getAmount()); } } }這個方式相比Transactional最大的好處是事務(wù)邊界肉眼可見。你把“數(shù)據(jù)庫原子寫入”和“外部動作”徹底拆開事務(wù)只保護(hù)真正需要對一致性負(fù)責(zé)的那一小段邏輯。很多大廠的基礎(chǔ)架構(gòu)規(guī)范里都會明確推薦TransactionTemplate因為它更顯式、更能強(qiáng)迫開發(fā)者思考事務(wù)的真實邊界。3.2 方案二拆分為獨立事務(wù) 冪等補(bǔ)償很多業(yè)務(wù)操作本質(zhì)上是“本地數(shù)據(jù)庫寫操作 下游系統(tǒng)操作”的組合。比如“下單成功后發(fā)優(yōu)惠券”、“支付成功后發(fā)積分”。這類需求用Transactional去包住下游操作是完全不現(xiàn)實的因為你既不能回滾別人的數(shù)據(jù)庫也不能因為下游失敗而撤銷主業(yè)務(wù)。業(yè)內(nèi)通用的做法是本地事務(wù)只保護(hù)主流程數(shù)據(jù) 可靠消息/事件驅(qū)動下游。流程大致是開啟本地事務(wù)寫入業(yè)務(wù)表數(shù)據(jù)同時插入一張“事件表”或“消息表”狀態(tài)為“待發(fā)送”。本地事務(wù)提交后通過一個后臺任務(wù)或MQ把事件表中的記錄異步推送出去。下游系統(tǒng)處理成功后回調(diào)確認(rèn)事件表狀態(tài)更新為“已發(fā)送”。如果推送失敗后臺任務(wù)不斷重試消費方保證冪等。這樣做的好處是本地事務(wù)非常短鎖持有時間短下游失敗不會影響主流程已完成的數(shù)據(jù)最終通過重試機(jī)制達(dá)到最終一致性。3.3 方案三如果一定要用Transactional這幾條紅線你得守住如果你評估完發(fā)現(xiàn)自己就是“單庫、單服務(wù)、操作不復(fù)雜、沒有外部調(diào)用”那用Transactional也無可厚非。但有幾條經(jīng)驗紅線你最好牢牢記住。首先方法體內(nèi)絕對不能有RPC、HTTP、MQ等外部網(wǎng)絡(luò)操作這個已經(jīng)不需要再解釋了就是血的教訓(xùn)。其次能用小事務(wù)解決的就不要搞大事務(wù)比如一個批量導(dǎo)入幾十萬數(shù)據(jù)的場景拆分批次提交而不是一個事務(wù)包到底否則undo log膨脹和長時間鎖等待會把你壓垮。還有一點很多人容易忽略Transactional上盡量顯式指定rollbackFor因為默認(rèn)值只對RuntimeException和Error生效受檢異常如Exception是不會觸發(fā)回滾的。Transactional(rollbackFor Exception.class) public void updateData() { // 你的業(yè)務(wù)邏輯 }如果你在代碼里把Exception通過try-catch捕獲那rollbackFor也沒用。所以我的習(xí)慣是異常一律往外拋由最外層的事務(wù)切面統(tǒng)一處理回滾邏輯。如果你確實想在事務(wù)方法內(nèi)部消化異常那就手動調(diào)用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()這是唯一能確保事務(wù)回滾的方式。3.4 給“不得不開事務(wù)”的場景做瘦身有時候業(yè)務(wù)就是需要一個比較大的事務(wù)范圍比如“同時更新主單、更新明細(xì)、更新庫存”。這種情況下你需要做的是盡可能縮小鎖定范圍具體可以從這幾個方向切入控制數(shù)據(jù)量不要在事務(wù)里for循環(huán)一條條查再一條條改盡量用批量SQL減少往返次數(shù)和鎖的持有時間。保證索引有效更新操作務(wù)必走索引否則全表掃描時會在所有記錄上加上鎖后果非?？膳隆＝y(tǒng)一鎖順序如果兩個方法分別需要更新A表和B表盡量保持一致的加鎖順序。例如先更新A再更新B避免兩個事務(wù)互相持鎖等待形成死鎖。降低隔離級別如果業(yè)務(wù)允許可以把事務(wù)隔離級別從默認(rèn)的可重復(fù)讀降到READ_COMMITTED。這個調(diào)整能顯著減少間隙鎖死鎖的概率代價是同一事務(wù)內(nèi)可能讀到其他事務(wù)已提交的新數(shù)據(jù)。我們當(dāng)時處理訂單自動確認(rèn)收貨的死鎖問題最終就是靠“走索引降低隔離級別”雙管齊下解決的。4. 常見問題與排查技巧實錄在我?guī)F(tuán)隊這幾年里關(guān)于Transactional的排查問題幾乎每個月都能碰到一兩個。下面我把一些高頻問題和排查思路整理成速查表方便大家直接抄作業(yè)。4.1 高頻問題速查表問題現(xiàn)象排查方向常見根因解決建議方法拋異常后數(shù)據(jù)依然寫入檢查是否被catch吞掉異常沒有拋到事務(wù)切面要么外層拋異常要么手動setRollbackOnly()事務(wù)完全沒有生效檢查方法是否為publicSpring AOP只攔截public方法改為public或者用TransactionTemplate同事內(nèi)部調(diào)用事務(wù)失效檢查是否是this.xxx()調(diào)用沒有經(jīng)過代理對象注入自身代理或拆分到另一個Bean高并發(fā)下大量死鎖檢查SQL是否走索引間隙鎖范圍過大優(yōu)化索引、降低隔離級別、統(tǒng)一鎖順序數(shù)據(jù)庫連接池被打滿檢查事務(wù)內(nèi)是否有RPC事務(wù)持有時間過長外部調(diào)用移出事務(wù)異步化批量操作很慢檢查是否一個事務(wù)包太多undo日志、鎖競爭嚴(yán)重分批提交控制單事務(wù)數(shù)據(jù)量4.2 排查事務(wù)失效的定位技巧如果你懷疑某個Transactional根本沒生效最快的驗證方法是開debug日志觀察spring的TransactionInterceptor有沒有攔截到方法調(diào)用。配置如下logging.level.org.springframework.transaction.interceptorDEBUG logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManagerDEBUG看到日志里有Creating new transaction with name [com.xxx.YourService.xxxMethod]說明事務(wù)已經(jīng)開啟。如果沒有任何輸出說明這個方法壓根沒走代理先檢查是不是public、是不是內(nèi)部調(diào)用。這個方法在排查問題時比看代碼快得多我基本每次都會先用它確認(rèn)方向。4.3 從日志里撈死鎖信息死鎖問題最麻煩的是你不知道它什么時候發(fā)生。MySQL在處理死鎖時會立刻回滾其中一個事務(wù)并在錯誤日志里記錄詳細(xì)的死鎖信息。我的排查習(xí)慣是打開死鎖日志SHOW ENGINE INNODB STATUS\G重點看LATEST DETECTED DEADLOCK部分里面會列出兩個事務(wù)各自持有哪些鎖、等待哪個鎖以及執(zhí)行的SQL語句。看到 SQL 基本就能判斷是哪段業(yè)務(wù)代碼了再配合業(yè)務(wù)日志里的請求參數(shù)基本能定位到具體方法。這里分享一個小技巧我在定位一次訂單系統(tǒng)死鎖時日志里顯示兩個事務(wù)都在操作order_status狀態(tài)字段一個更新的是“待發(fā)貨”到“已發(fā)貨”另一個更新的是“待發(fā)貨”到“已取消”。單獨看都不覺得有問題但打開執(zhí)行計劃后發(fā)現(xiàn)更新條件沒走索引全表掃描把鎖散到了所有記錄上這才導(dǎo)致兩個事務(wù)互相等待。后面給狀態(tài)字段加了聯(lián)合索引死鎖直接消失。4.4 避免事務(wù)問題的一些設(shè)計習(xí)慣除了上面這些排查手段我更想分享的是幾個能從根本上減少事務(wù)問題概率的設(shè)計習(xí)慣。一是寫操作的方法簽名上不要帶返回值之外的副作用。也就是說一個事務(wù)方法只做數(shù)據(jù)變更不做遠(yuǎn)程通知、不拼裝大報文、不做復(fù)雜的JSON解析。這些臟活累活放到事務(wù)外面去。二是在領(lǐng)域?qū)訁^(qū)分“服務(wù)方法”和“基礎(chǔ)設(shè)施方法”。領(lǐng)域服務(wù)里的方法可以放心用Transactional因為它處理的是純粹的領(lǐng)域邏輯但 Controller 層、Facade 層、RPC 入站接口層這些方法里盡量別直接加事務(wù)因為這一層往往涉及參數(shù)校驗、多服務(wù)聚合事務(wù)邊界容易被拉大。三是讀寫分離場景要格外小心。如果項目用了主從分離默認(rèn)情況下Transactional會讓整個方法綁定在主庫上。哪怕你方法里只有一個查詢操作也會因為開啟了事務(wù)而走了主庫把讀壓力全部壓到主庫上。很多人發(fā)現(xiàn)“為什么我的從庫一點流量都沒有”很可能就是這個原因。解決辦法是對于只讀場景顯式指定事務(wù)為只讀或者干脆去掉事務(wù)。5. 從“能不能用”到“怎么用對”事務(wù)控制的進(jìn)階思考聊了這么多如果只記住“別用Transactional”那還是沒理解透。這個東西不是毒藥只是很容易用錯。我自己在項目里也經(jīng)常用但會在用之前問自己幾個問題這里整理出來供大家參考。5.1 用之前先問自己四個問題第一個問題這個操作是不是必須原子生效如果不是那就別開事務(wù)。很多業(yè)務(wù)場景其實只是“順序執(zhí)行多個操作”并不要求每個操作都成功失敗的話后面補(bǔ)償就行。第二個問題事務(wù)范圍能不能控制在純DB操作內(nèi)如果方法里有任何非DB調(diào)用那你需要重新審視這個方法的邊界。記住一個原則事務(wù)里只做數(shù)據(jù)操作業(yè)務(wù)編排放在事務(wù)外。第三個問題這個事務(wù)的粒度是否夠小如果你要更新1萬條數(shù)據(jù)拆成每500條一個事務(wù)遠(yuǎn)比一個事務(wù)包到底要好。這樣如果中途失敗不需要回滾全部數(shù)據(jù)鎖競爭也小得多。第四個問題回滾之后下游系統(tǒng)知不知道你回滾了如果你的事務(wù)里發(fā)了MQ消息事務(wù)回滾了但消息已經(jīng)發(fā)出去了消費方那邊依然會執(zhí)行。這種情況下就算你用Transactional包住了本地數(shù)據(jù)庫仍然無法保證全局一致性。5.2 本地事務(wù)和分布式事務(wù)的邊界意識很多人對大廠不推薦Transactional的另一個誤解是因為大廠都是微服務(wù)架構(gòu)所以單庫事務(wù)沒用了。這個說法不完全對。微服務(wù)架構(gòu)下每個服務(wù)內(nèi)部依然有本地數(shù)據(jù)庫事務(wù)只是你不能再指望用本地事務(wù)去約束跨服務(wù)的數(shù)據(jù)一致性。真正合理的架構(gòu)是本地事務(wù)管住自己的狀態(tài)跨服務(wù)的狀態(tài)用可靠消息/事件驅(qū)動來同步。你可以把Transactional用在“下單主流程”中但它只管本地訂單表和事件表的寫入。至于下游的積分服務(wù)、優(yōu)惠券服務(wù)、物流服務(wù)都是通過事件異步觸發(fā)的不會和主事務(wù)放在同一個事務(wù)里。有一個非常好的實踐叫本地消息表。這個模式的核心就是利用本地事務(wù)把業(yè)務(wù)操作和消息發(fā)送放在同一個事務(wù)里事務(wù)提交后消息表里的記錄就是可靠的后臺任務(wù)再把消息發(fā)出去。這個方案既保證了本地數(shù)據(jù)的一致性又為跨系統(tǒng)的最終一致性提供了基礎(chǔ)。在這個模式里Transactional反而扮演了非常關(guān)鍵的角色。5.3 謹(jǐn)慎使用REQUIRES_NEW它不是銀彈事務(wù)傳播行為里的REQUIRES_NEW經(jīng)常被拿來當(dāng)“局部事務(wù)獨立提交”的解法。比如有人說“我在外層事務(wù)里調(diào)用一個方法希望它單獨提交即使外層回滾它也不受影響那就用REQUIRES_NEW。”這個思路在特定場景下是對的但要特別謹(jǐn)慎。REQUIRES_NEW會掛起當(dāng)前事務(wù)開啟一個新事務(wù)新事務(wù)提交后再恢復(fù)原事務(wù)。這意味著這個方法的數(shù)據(jù)庫操作和原事務(wù)不在同一個原子單元里而且會額外占用一個數(shù)據(jù)庫連接。我見過有同學(xué)在循環(huán)中調(diào)用REQUIRES_NEW方法結(jié)果連接池直接被打滿。因為外層事務(wù)一直持有一個連接內(nèi)層的REQUIRES_NEW每循環(huán)一次就要從連接池拿一個新連接即使連接池默認(rèn)有20個連接也不能這么造。如果你確實需要“部分?jǐn)?shù)據(jù)獨立提交”優(yōu)先考慮把這一部分抽到獨立服務(wù)去調(diào)用或者用事務(wù)同步鉤子處理器TransactionSynchronizationManager.registerSynchronization在事務(wù)提交后異步執(zhí)行。6. 寫在最后事務(wù)是工具但別讓它替你思考做技術(shù)這行久了你會發(fā)現(xiàn)很多問題都不是“技術(shù)不夠”導(dǎo)致的而是“默認(rèn)配置太方便思考變懶了”導(dǎo)致的。Transactional就是最典型的例子。它讓你一行注解就拿到了事務(wù)能力卻也把事務(wù)的代價、邊界、異常處理邏輯全部隱去了。當(dāng)你面對的僅僅是“單表單庫的簡單CRUD”時它確實省心。但一旦你的方法開始變得復(fù)雜涉及外部調(diào)用、多表關(guān)聯(lián)、批量處理、異步邏輯這個注解就會變成一把沒有安全栓的槍。我自己現(xiàn)在的習(xí)慣是新項目里默認(rèn)不用Transactional標(biāo)注業(yè)務(wù)方法而是根據(jù)實際場景去選。純DB小操作用TransactionTemplate或直接在Mapper層做跨服務(wù)一致性直接用可靠消息只有那種“必須原子更新若干張表且不摻雜任何外部動作”的場景我才會把事務(wù)注解加上并且嚴(yán)格限定rollbackFor、走索引、控制數(shù)據(jù)量。最后送你一個排查口訣看到事務(wù)先問邊界看到異常先看回滾看到鎖先查索引看到慢先抓連接。這四個問題想清楚了Transactional對你來說就不再是玄學(xué)而是一個真正可控的工具。 Spring事務(wù)踩坑指南：從@Transactional失效到性能殺手，大廠為何慎用
在Java后端圈子里Transactional幾乎是每個Spring開發(fā)者最早接觸的幾個注解之一。剛?cè)胄械臅r候很多人對它的理解就是“在方法上加上這個注解方法里的數(shù)據(jù)庫操作要么全成功要么全失敗”省去了手動begin、commit、rollback的樣板代碼看起來確實是神器。但在大廠里待過幾年后你會發(fā)現(xiàn)代碼評審時如果有人在核心鏈路上直接甩一個Transactional大概率會被追問“這個事務(wù)是非開不可嗎能不能去掉”不是大廠故意刁難而是這個注解背后的坑遠(yuǎn)比表面看上去的要多。這篇文章我想從實際踩坑經(jīng)歷出發(fā)把Transactional在真實業(yè)務(wù)場景里的“原罪”講清楚。它為什么會失效、什么時候會拖垮性能、單庫事務(wù)在分布式環(huán)境下又是怎么變成隱患的、以及大廠更傾向于用什么方案替代。不管是剛寫Spring沒多久的新人還是被線上事故折騰過的老手這篇文章應(yīng)該都能給你一些參考。1. 內(nèi)容整體設(shè)計與思路拆解在展開細(xì)節(jié)之前我想先聊聊為什么大家會集中吐槽Transactional。它本身不是壞東西但因為它太“方便”了反而容易被人用在不合適的地方。理解這個問題的關(guān)鍵在于要弄清楚一件事事務(wù)的本質(zhì)是鎖和日志的組合而鎖意味著串行化日志意味著額外的IO開銷。1.1 從一次線上事故說起誰動了我的數(shù)據(jù)我之前帶過一個支付對賬相關(guān)的項目有一個“批量入賬”的接口。當(dāng)時新來的同學(xué)很自然地在這個方法上加了Transactional他的邏輯很簡單把所有入賬操作放在一個事務(wù)里任何一個失敗就全部回滾這樣數(shù)據(jù)不會出現(xiàn)“一半成功一半失敗”的狀態(tài)。聽起來毫無問題對不對但上線后第三天線上就開始出現(xiàn)大量超時告警。我讓他查數(shù)據(jù)庫慢查詢?nèi)罩窘Y(jié)果發(fā)現(xiàn)表雖然不大但大量SQL都集中在同一行記錄上長時間持鎖。再追下去發(fā)現(xiàn)這個批量入賬方法在事務(wù)里還調(diào)用了一個遠(yuǎn)程賬戶通知服務(wù)網(wǎng)速稍微抖一下事務(wù)就遲遲不提交鎖就捏在手里不放。這個案例非常典型他做對了事務(wù)的一致性保證卻忽略了事務(wù)的隔離性代價。一個簡單的Transactional把“批量寫庫”和“外部RPC調(diào)用”綁定在了同一個生命周期里。類似的問題在大廠代碼評審中幾乎是每周都會出現(xiàn)。1.2 大廠不推薦的真正理由不是禁用而是慎用大廠并不是給Transactional判了死刑而是把它從“默認(rèn)選項”降級成了“需要充分理由才能使用”。核心原因是三方面的職責(zé)邊界被破壞一個方法一旦加了事務(wù)這個方法的邏輯就被迫變成一個原子單元。但現(xiàn)實業(yè)務(wù)中很多操作天然就是“可補(bǔ)償”的不需要原子化。性能邊界模糊事務(wù)的隔離級別、傳播行為、鎖粒度很多人并沒有真正理解。默認(rèn)配置直接套上去長事務(wù)、大事務(wù)、死鎖問題接踵而至。分布式環(huán)境下能力不足單庫事務(wù)只能在本地生效一旦涉及微服務(wù)間調(diào)用、消息隊列、多數(shù)據(jù)源Transactional反而給人制造“我好像有事務(wù)保護(hù)”的錯覺。所以我更愿意把這篇內(nèi)容理解為什么時候你別用Transactional以及如果你真的要用怎么把風(fēng)險降到最低。2. 核心細(xì)節(jié)解析與實操要點可能有人會覺得“不就是一個注解嗎我用了這么多年也沒出過事?！蹦俏抑荒苷f你比較幸運還沒有被線上事故教育過。下面我挑幾個最容易踩的坑展開說一下這些都是我在實際項目里真真切切遇到過的。2.1 事務(wù)失效的若干種姿勢如果面試被問到“Transactional為什么會失效”很多人能回答出“自調(diào)用失效”和“異常被吞了”這兩條。但真實場景里的失效情況遠(yuǎn)不止這兩類我整理了一個我親手排查過的問題列表失效場景真實原因現(xiàn)象同類內(nèi)部方法調(diào)用this.xxx()不走代理對象事務(wù)切面不生效異常拋出但數(shù)據(jù)部分更新try-catch吞掉異常Spring默認(rèn)只對RuntimeException回滾異常沒拋出去數(shù)據(jù)出現(xiàn)“半成功”狀態(tài)方法不是publicSpring AOP默認(rèn)只攔截public方法事務(wù)不生效數(shù)據(jù)庫引擎不支持事務(wù)比如MyISAM表寫操作照常但無法回滾多線程調(diào)用事務(wù)上下文不傳遞到子線程子線程里的寫操作不在事務(wù)內(nèi)每個場景背后幾乎都有一次血淚線上事故。拿“異常被吞”來說很多同學(xué)寫代碼時喜歡在catch塊里記錄日志然后返回一個錯誤碼這在普通業(yè)務(wù)方法里沒問題但如果方法上有Transactional事務(wù)不會因為你返回了錯誤碼就回滾。你必須在catch塊里手動TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()否則數(shù)據(jù)就悄悄寫進(jìn)去了。2.2 默認(rèn)隔離級別與鎖升級MySQL 默認(rèn)的隔離級別是REPEATABLE_READ也就是可重復(fù)讀。Spring 的Transactional如果你不指定isolation屬性它走的是數(shù)據(jù)庫默認(rèn)隔離級別所以大多數(shù)情況下你實際用的是REPEATABLE_READ。這有什么問題呢REPEATABLE_READ為了保證同一事務(wù)內(nèi)多次讀取結(jié)果一致會在SELECT上加S鎖共享鎖在UPDATE/DELETE上加X鎖排他鎖。在高并發(fā)寫入場景下多個事務(wù)同時更新同一行或相鄰的索引范圍就容易觸發(fā)間隙鎖Gap Lock和Next-Key Lock進(jìn)而產(chǎn)生死鎖。舉個我在訂單系統(tǒng)中實際遇到過的案例有一個“訂單自動確認(rèn)收貨”的定時任務(wù)和用戶手動點擊“確認(rèn)收貨”的接口都會去更新同一批訂單的狀態(tài)。兩個事務(wù)同時掃描status 待收貨的訂單區(qū)間時互相持有了對方需要的間隙鎖MySQL 檢測到死鎖后會隨機(jī)kill掉一個事務(wù)。被kill的那個事務(wù)如果沒有正確處理死鎖異常用戶就會看到“操作失敗”。這類問題用Transactional不是完全不能解決但你得非常清楚自己操作的數(shù)據(jù)范圍、索引設(shè)計、鎖順序任何一環(huán)沒考慮到就是一個隱患。2.3 事務(wù)內(nèi)調(diào)用遠(yuǎn)程RPC時間黑洞這是我認(rèn)為最不值得踩的坑。在事務(wù)方法里調(diào)用RPC、HTTP接口、消息發(fā)送、文件上傳本質(zhì)上是在用一個數(shù)據(jù)庫事務(wù)去控制一個毫秒級甚至秒級延遲的外部系統(tǒng)。這么做有兩個后果事務(wù)持有時間變長數(shù)據(jù)庫連接池被長期占用高并發(fā)下連接耗盡外部系統(tǒng)調(diào)用失敗時事務(wù)回滾了但外部系統(tǒng)已經(jīng)做了操作兩邊數(shù)據(jù)不一致。我見過最夸張的一個案例是有人在一個Transactional方法里循環(huán)調(diào)用了20多次外部供應(yīng)商接口每次平均耗時300毫秒。一次請求這個事務(wù)至少要跑6秒數(shù)據(jù)庫連接直接被卡死。這已經(jīng)不是在寫事務(wù)性代碼了這是在制造線上事故。正確的做法是什么把外部調(diào)用放在事務(wù)外或者干脆去掉事務(wù)靠狀態(tài)機(jī)重試冪等來控制數(shù)據(jù)一致性。這個后面我會詳細(xì)講。3. 實操過程與核心環(huán)節(jié)實現(xiàn)既然吐槽了這么多那總得告訴你怎么做是合理的。下面我結(jié)合幾個真實場景分別給出“別用Transactional的替代方案”以及“如果確實要用怎么把傷害降到最低”。3.1 方案一用自研輕量級事務(wù)工具類控制邊界大廠里很多基礎(chǔ)架構(gòu)團(tuán)隊會給業(yè)務(wù)方提供一個TransactionTemplate的封裝核心思路就是把事務(wù)邊界顯式化而不是靠注解的隱式切面。你可以在代碼里精確控制“在哪個方法里開啟事務(wù)、在哪個節(jié)點提交”。Service public class OrderService { Autowired private TransactionTemplate transactionTemplate; Autowired private OrderMapper orderMapper; Autowired private AccountService accountService; public void createOrder(OrderDO order) { // 前置校驗、冪等檢查都可以放在事務(wù)外面 boolean created transactionTemplate.execute(status - { try { orderMapper.insert(order); // 注意這里不要調(diào)RPC只做純DB操作 return true; } catch (Exception e) { status.setRollbackOnly(); throw e; } }); if (created) { // 事務(wù)提交之后再發(fā)MQ通知、調(diào)外部接口 accountService.deductBalance(order.getUserId(), order.getAmount()); } } }這個方式相比Transactional最大的好處是事務(wù)邊界肉眼可見。你把“數(shù)據(jù)庫原子寫入”和“外部動作”徹底拆開事務(wù)只保護(hù)真正需要對一致性負(fù)責(zé)的那一小段邏輯。很多大廠的基礎(chǔ)架構(gòu)規(guī)范里都會明確推薦TransactionTemplate因為它更顯式、更能強(qiáng)迫開發(fā)者思考事務(wù)的真實邊界。3.2 方案二拆分為獨立事務(wù) 冪等補(bǔ)償很多業(yè)務(wù)操作本質(zhì)上是“本地數(shù)據(jù)庫寫操作 下游系統(tǒng)操作”的組合。比如“下單成功后發(fā)優(yōu)惠券”、“支付成功后發(fā)積分”。這類需求用Transactional去包住下游操作是完全不現(xiàn)實的因為你既不能回滾別人的數(shù)據(jù)庫也不能因為下游失敗而撤銷主業(yè)務(wù)。業(yè)內(nèi)通用的做法是本地事務(wù)只保護(hù)主流程數(shù)據(jù) 可靠消息/事件驅(qū)動下游。流程大致是開啟本地事務(wù)寫入業(yè)務(wù)表數(shù)據(jù)同時插入一張“事件表”或“消息表”狀態(tài)為“待發(fā)送”。本地事務(wù)提交后通過一個后臺任務(wù)或MQ把事件表中的記錄異步推送出去。下游系統(tǒng)處理成功后回調(diào)確認(rèn)事件表狀態(tài)更新為“已發(fā)送”。如果推送失敗后臺任務(wù)不斷重試消費方保證冪等。這樣做的好處是本地事務(wù)非常短鎖持有時間短下游失敗不會影響主流程已完成的數(shù)據(jù)最終通過重試機(jī)制達(dá)到最終一致性。3.3 方案三如果一定要用Transactional這幾條紅線你得守住如果你評估完發(fā)現(xiàn)自己就是“單庫、單服務(wù)、操作不復(fù)雜、沒有外部調(diào)用”那用Transactional也無可厚非。但有幾條經(jīng)驗紅線你最好牢牢記住。首先方法體內(nèi)絕對不能有RPC、HTTP、MQ等外部網(wǎng)絡(luò)操作這個已經(jīng)不需要再解釋了就是血的教訓(xùn)。其次能用小事務(wù)解決的就不要搞大事務(wù)比如一個批量導(dǎo)入幾十萬數(shù)據(jù)的場景拆分批次提交而不是一個事務(wù)包到底否則undo log膨脹和長時間鎖等待會把你壓垮。還有一點很多人容易忽略Transactional上盡量顯式指定rollbackFor因為默認(rèn)值只對RuntimeException和Error生效受檢異常如Exception是不會觸發(fā)回滾的。Transactional(rollbackFor Exception.class) public void updateData() { // 你的業(yè)務(wù)邏輯 }如果你在代碼里把Exception通過try-catch捕獲那rollbackFor也沒用。所以我的習(xí)慣是異常一律往外拋由最外層的事務(wù)切面統(tǒng)一處理回滾邏輯。如果你確實想在事務(wù)方法內(nèi)部消化異常那就手動調(diào)用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()這是唯一能確保事務(wù)回滾的方式。3.4 給“不得不開事務(wù)”的場景做瘦身有時候業(yè)務(wù)就是需要一個比較大的事務(wù)范圍比如“同時更新主單、更新明細(xì)、更新庫存”。這種情況下你需要做的是盡可能縮小鎖定范圍具體可以從這幾個方向切入控制數(shù)據(jù)量不要在事務(wù)里for循環(huán)一條條查再一條條改盡量用批量SQL減少往返次數(shù)和鎖的持有時間。保證索引有效更新操作務(wù)必走索引否則全表掃描時會在所有記錄上加上鎖后果非?？膳隆＝y(tǒng)一鎖順序如果兩個方法分別需要更新A表和B表盡量保持一致的加鎖順序。例如先更新A再更新B避免兩個事務(wù)互相持鎖等待形成死鎖。降低隔離級別如果業(yè)務(wù)允許可以把事務(wù)隔離級別從默認(rèn)的可重復(fù)讀降到READ_COMMITTED。這個調(diào)整能顯著減少間隙鎖死鎖的概率代價是同一事務(wù)內(nèi)可能讀到其他事務(wù)已提交的新數(shù)據(jù)。我們當(dāng)時處理訂單自動確認(rèn)收貨的死鎖問題最終就是靠“走索引降低隔離級別”雙管齊下解決的。4. 常見問題與排查技巧實錄在我?guī)F(tuán)隊這幾年里關(guān)于Transactional的排查問題幾乎每個月都能碰到一兩個。下面我把一些高頻問題和排查思路整理成速查表方便大家直接抄作業(yè)。4.1 高頻問題速查表問題現(xiàn)象排查方向常見根因解決建議方法拋異常后數(shù)據(jù)依然寫入檢查是否被catch吞掉異常沒有拋到事務(wù)切面要么外層拋異常要么手動setRollbackOnly()事務(wù)完全沒有生效檢查方法是否為publicSpring AOP只攔截public方法改為public或者用TransactionTemplate同事內(nèi)部調(diào)用事務(wù)失效檢查是否是this.xxx()調(diào)用沒有經(jīng)過代理對象注入自身代理或拆分到另一個Bean高并發(fā)下大量死鎖檢查SQL是否走索引間隙鎖范圍過大優(yōu)化索引、降低隔離級別、統(tǒng)一鎖順序數(shù)據(jù)庫連接池被打滿檢查事務(wù)內(nèi)是否有RPC事務(wù)持有時間過長外部調(diào)用移出事務(wù)異步化批量操作很慢檢查是否一個事務(wù)包太多undo日志、鎖競爭嚴(yán)重分批提交控制單事務(wù)數(shù)據(jù)量4.2 排查事務(wù)失效的定位技巧如果你懷疑某個Transactional根本沒生效最快的驗證方法是開debug日志觀察spring的TransactionInterceptor有沒有攔截到方法調(diào)用。配置如下logging.level.org.springframework.transaction.interceptorDEBUG logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManagerDEBUG看到日志里有Creating new transaction with name [com.xxx.YourService.xxxMethod]說明事務(wù)已經(jīng)開啟。如果沒有任何輸出說明這個方法壓根沒走代理先檢查是不是public、是不是內(nèi)部調(diào)用。這個方法在排查問題時比看代碼快得多我基本每次都會先用它確認(rèn)方向。4.3 從日志里撈死鎖信息死鎖問題最麻煩的是你不知道它什么時候發(fā)生。MySQL在處理死鎖時會立刻回滾其中一個事務(wù)并在錯誤日志里記錄詳細(xì)的死鎖信息。我的排查習(xí)慣是打開死鎖日志SHOW ENGINE INNODB STATUS\G重點看LATEST DETECTED DEADLOCK部分里面會列出兩個事務(wù)各自持有哪些鎖、等待哪個鎖以及執(zhí)行的SQL語句。看到 SQL 基本就能判斷是哪段業(yè)務(wù)代碼了再配合業(yè)務(wù)日志里的請求參數(shù)基本能定位到具體方法。這里分享一個小技巧我在定位一次訂單系統(tǒng)死鎖時日志里顯示兩個事務(wù)都在操作order_status狀態(tài)字段一個更新的是“待發(fā)貨”到“已發(fā)貨”另一個更新的是“待發(fā)貨”到“已取消”。單獨看都不覺得有問題但打開執(zhí)行計劃后發(fā)現(xiàn)更新條件沒走索引全表掃描把鎖散到了所有記錄上這才導(dǎo)致兩個事務(wù)互相等待。后面給狀態(tài)字段加了聯(lián)合索引死鎖直接消失。4.4 避免事務(wù)問題的一些設(shè)計習(xí)慣除了上面這些排查手段我更想分享的是幾個能從根本上減少事務(wù)問題概率的設(shè)計習(xí)慣。一是寫操作的方法簽名上不要帶返回值之外的副作用。也就是說一個事務(wù)方法只做數(shù)據(jù)變更不做遠(yuǎn)程通知、不拼裝大報文、不做復(fù)雜的JSON解析。這些臟活累活放到事務(wù)外面去。二是在領(lǐng)域?qū)訁^(qū)分“服務(wù)方法”和“基礎(chǔ)設(shè)施方法”。領(lǐng)域服務(wù)里的方法可以放心用Transactional因為它處理的是純粹的領(lǐng)域邏輯但 Controller 層、Facade 層、RPC 入站接口層這些方法里盡量別直接加事務(wù)因為這一層往往涉及參數(shù)校驗、多服務(wù)聚合事務(wù)邊界容易被拉大。三是讀寫分離場景要格外小心。如果項目用了主從分離默認(rèn)情況下Transactional會讓整個方法綁定在主庫上。哪怕你方法里只有一個查詢操作也會因為開啟了事務(wù)而走了主庫把讀壓力全部壓到主庫上。很多人發(fā)現(xiàn)“為什么我的從庫一點流量都沒有”很可能就是這個原因。解決辦法是對于只讀場景顯式指定事務(wù)為只讀或者干脆去掉事務(wù)。5. 從“能不能用”到“怎么用對”事務(wù)控制的進(jìn)階思考聊了這么多如果只記住“別用Transactional”那還是沒理解透。這個東西不是毒藥只是很容易用錯。我自己在項目里也經(jīng)常用但會在用之前問自己幾個問題這里整理出來供大家參考。5.1 用之前先問自己四個問題第一個問題這個操作是不是必須原子生效如果不是那就別開事務(wù)。很多業(yè)務(wù)場景其實只是“順序執(zhí)行多個操作”并不要求每個操作都成功失敗的話后面補(bǔ)償就行。第二個問題事務(wù)范圍能不能控制在純DB操作內(nèi)如果方法里有任何非DB調(diào)用那你需要重新審視這個方法的邊界。記住一個原則事務(wù)里只做數(shù)據(jù)操作業(yè)務(wù)編排放在事務(wù)外。第三個問題這個事務(wù)的粒度是否夠小如果你要更新1萬條數(shù)據(jù)拆成每500條一個事務(wù)遠(yuǎn)比一個事務(wù)包到底要好。這樣如果中途失敗不需要回滾全部數(shù)據(jù)鎖競爭也小得多。第四個問題回滾之后下游系統(tǒng)知不知道你回滾了如果你的事務(wù)里發(fā)了MQ消息事務(wù)回滾了但消息已經(jīng)發(fā)出去了消費方那邊依然會執(zhí)行。這種情況下就算你用Transactional包住了本地數(shù)據(jù)庫仍然無法保證全局一致性。5.2 本地事務(wù)和分布式事務(wù)的邊界意識很多人對大廠不推薦Transactional的另一個誤解是因為大廠都是微服務(wù)架構(gòu)所以單庫事務(wù)沒用了。這個說法不完全對。微服務(wù)架構(gòu)下每個服務(wù)內(nèi)部依然有本地數(shù)據(jù)庫事務(wù)只是你不能再指望用本地事務(wù)去約束跨服務(wù)的數(shù)據(jù)一致性。真正合理的架構(gòu)是本地事務(wù)管住自己的狀態(tài)跨服務(wù)的狀態(tài)用可靠消息/事件驅(qū)動來同步。你可以把Transactional用在“下單主流程”中但它只管本地訂單表和事件表的寫入。至于下游的積分服務(wù)、優(yōu)惠券服務(wù)、物流服務(wù)都是通過事件異步觸發(fā)的不會和主事務(wù)放在同一個事務(wù)里。有一個非常好的實踐叫本地消息表。這個模式的核心就是利用本地事務(wù)把業(yè)務(wù)操作和消息發(fā)送放在同一個事務(wù)里事務(wù)提交后消息表里的記錄就是可靠的后臺任務(wù)再把消息發(fā)出去。這個方案既保證了本地數(shù)據(jù)的一致性又為跨系統(tǒng)的最終一致性提供了基礎(chǔ)。在這個模式里Transactional反而扮演了非常關(guān)鍵的角色。5.3 謹(jǐn)慎使用REQUIRES_NEW它不是銀彈事務(wù)傳播行為里的REQUIRES_NEW經(jīng)常被拿來當(dāng)“局部事務(wù)獨立提交”的解法。比如有人說“我在外層事務(wù)里調(diào)用一個方法希望它單獨提交即使外層回滾它也不受影響那就用REQUIRES_NEW。”這個思路在特定場景下是對的但要特別謹(jǐn)慎。REQUIRES_NEW會掛起當(dāng)前事務(wù)開啟一個新事務(wù)新事務(wù)提交后再恢復(fù)原事務(wù)。這意味著這個方法的數(shù)據(jù)庫操作和原事務(wù)不在同一個原子單元里而且會額外占用一個數(shù)據(jù)庫連接。我見過有同學(xué)在循環(huán)中調(diào)用REQUIRES_NEW方法結(jié)果連接池直接被打滿。因為外層事務(wù)一直持有一個連接內(nèi)層的REQUIRES_NEW每循環(huán)一次就要從連接池拿一個新連接即使連接池默認(rèn)有20個連接也不能這么造。如果你確實需要“部分?jǐn)?shù)據(jù)獨立提交”優(yōu)先考慮把這一部分抽到獨立服務(wù)去調(diào)用或者用事務(wù)同步鉤子處理器TransactionSynchronizationManager.registerSynchronization在事務(wù)提交后異步執(zhí)行。6. 寫在最后事務(wù)是工具但別讓它替你思考做技術(shù)這行久了你會發(fā)現(xiàn)很多問題都不是“技術(shù)不夠”導(dǎo)致的而是“默認(rèn)配置太方便思考變懶了”導(dǎo)致的。Transactional就是最典型的例子。它讓你一行注解就拿到了事務(wù)能力卻也把事務(wù)的代價、邊界、異常處理邏輯全部隱去了。當(dāng)你面對的僅僅是“單表單庫的簡單CRUD”時它確實省心。但一旦你的方法開始變得復(fù)雜涉及外部調(diào)用、多表關(guān)聯(lián)、批量處理、異步邏輯這個注解就會變成一把沒有安全栓的槍。我自己現(xiàn)在的習(xí)慣是新項目里默認(rèn)不用Transactional標(biāo)注業(yè)務(wù)方法而是根據(jù)實際場景去選。純DB小操作用TransactionTemplate或直接在Mapper層做跨服務(wù)一致性直接用可靠消息只有那種“必須原子更新若干張表且不摻雜任何外部動作”的場景我才會把事務(wù)注解加上并且嚴(yán)格限定rollbackFor、走索引、控制數(shù)據(jù)量。最后送你一個排查口訣看到事務(wù)先問邊界看到異常先看回滾看到鎖先查索引看到慢先抓連接。這四個問題想清楚了Transactional對你來說就不再是玄學(xué)而是一個真正可控的工具。