失效的7個坑與底層原理：從JDBC到分布式事務(wù))
1. 事務(wù)失效的七宗罪我踩過的坑你大概率也會踩先講個真實事故。幾年前我維護過一個電商訂單系統(tǒng)線上出了一個詭異的bug用戶支付成功后訂單狀態(tài)正常更新但庫存卻莫名其妙多扣了一次。代碼看起來完全沒問題——service方法上明明白白標著Transactional數(shù)據(jù)庫也確認是InnoDB。查了兩天才定位到根因同一個類里方法A調(diào)用方法BB的事務(wù)注解根本沒生效。這就是Spring事務(wù)最經(jīng)典的坑之一自調(diào)用繞過代理。Transactional依賴AOP代理生效而Spring的代理機制決定了一個類內(nèi)部的方法調(diào)用是不會經(jīng)過代理對象的。this.orderService.update()拿到的這個this根本不是Spring容器里那個被代理過的bean而是原始對象。原始對象上的注解Spring根本看不見。結(jié)果就是你以為開啟了事務(wù)實際上沒有。庫存扣減在無事務(wù)狀態(tài)下執(zhí)行訂單那邊一旦報錯回滾庫存早就提交了。1.1 自調(diào)用問題最隱蔽的事務(wù)殺手自調(diào)用這個坑的隱蔽之處在于它不會報錯不會警告日志里什么都看不出來只有數(shù)據(jù)對不上賬的時候才會暴露。Service public class OrderService { Transactional public void createOrder(OrderDTO dto) { // 扣庫存 stockService.deduct(dto.getSkuId(), dto.getQuantity()); // 插入訂單 orderMapper.insert(buildOrder(dto)); // 這里調(diào)用了自身方法事務(wù)注解失效 this.sendNotification(dto); } Transactional(propagation Propagation.REQUIRES_NEW) public void sendNotification(OrderDTO dto) { // 通知邏輯 } }上面這段代碼里sendNotification的REQUIRES_NEW完全無效。因為this.sendNotification()走的是原始對象不是代理。解決辦法有三個把需要事務(wù)的方法挪到另一個Service類——最推薦職責也最清晰。注入自身代理Autowired private OrderService self;然后調(diào)用self.sendNotification()。使用AopContext.currentProxy()需要開啟EnableAspectJAutoProxy(exposeProxy true)然后((OrderService) AopContext.currentProxy()).sendNotification()。方案2最實用但要注意循環(huán)依賴問題——Spring 4.3之后字段注入的循環(huán)依賴是允許的但構(gòu)造器注入就不行。方案3代碼看著別扭但確實有效。1.2 非public方法注解白寫了Transactional用在private或者protected方法上Spring容器啟動時根本不報錯但方法執(zhí)行時事務(wù)就是沒開。原理不復(fù)雜Spring AOP生成代理的時候JDK動態(tài)代理基于接口只代理public方法CGLIB雖然能代理非public方法但Spring官方明確說了Transactional只支持public方法。最騷的是如果你把Transactional放在public方法上、但里面調(diào)用了private方法private方法里的事務(wù)注解同樣無效——因為事務(wù)邊界已經(jīng)在public方法的代理上確定了內(nèi)層調(diào)用不會再開啟新事務(wù)除非傳播行為是REQUIRES_NEW。我見過不少項目把Transactional加到private方法上然后一臉疑惑地說為什么回滾了沒生效。排查方法很簡單看日志里有沒有TransactionInterceptor的getTransaction記錄沒有就是代理沒走。1.3 異常被吞回滾了個寂寞這是最常見也最無語的一種。Java的檢查型異常checked exception默認不會觸發(fā)Spring事務(wù)回滾但很多人不知道這一點隨手寫了個throws Exception然后事務(wù)就失效了。Transactional public void transfer(Account from, Account to, BigDecimal amount) throws Exception { accountMapper.decrease(from.getId(), amount); accountMapper.increase(to.getId(), amount); // 業(yè)務(wù)校驗不通過拋了個業(yè)務(wù)異常 throw new BizException(余額不足); }BizException如果是繼承Exception而不是RuntimeException上面這個事務(wù)不會回滾錢就憑空消失了。Spring的默認回滾策略是只回滾RuntimeException和Error。檢查型異常如IOException不會觸發(fā)回滾因為Spring認為你既然顯式聲明了這個異常說明你可以處理它事務(wù)繼續(xù)提交是合理的。解決方案兩個方向業(yè)務(wù)異常統(tǒng)一繼承RuntimeException——大多數(shù)項目的做法最簡單。在Transactional上顯式指定Transactional(rollbackFor Exception.class)——最穩(wěn)一勞永逸。我個人的習(xí)慣是兩者都做自定義業(yè)務(wù)異常繼承RuntimeException同時在Transactional上寫rollbackFor Exception.class。雖然看起來冗余但團隊里總有人會寫檢查型異常。1.4 多線程子線程異常主線程事務(wù)照樣提交Transactional的事務(wù)上下文存在ThreadLocal里子線程拿不到父線程的事務(wù)上下文。Transactional public void batchProcess(ListOrder orders) { orders.parallelStream().forEach(order - { // 這里拋異常父線程事務(wù)不會感知 processOne(order); }); }如果一定要在多線程里用事務(wù)只能每個線程自己開事務(wù)用TransactionTemplate包住子線程的任務(wù)代碼然后在線程池層面做異常聚合——子線程里有任何失敗主線程如何決定是否整體回滾需要自己實現(xiàn)協(xié)調(diào)邏輯。這個問題在批量導(dǎo)入、報表生成、定時任務(wù)場景里非常常見。我的建議是批量任務(wù)盡量不用Transactional包整段而是每條或每批用TransactionTemplate單獨開事務(wù)配合失敗記錄表做補償。這樣既能保證數(shù)據(jù)一致又不會因為一個線程失敗導(dǎo)致大批量回滾。1.5 數(shù)據(jù)庫引擎不支持事務(wù)這個坑現(xiàn)在少了但老項目中還能見到。MySQL的MyISAM引擎根本不支持事務(wù)你注解標得再多也沒用。確認方法很簡單SHOW TABLE STATUS WHERE Name your_table;看Engine字段InnoDB支持事務(wù)MyISAM不支持。另外如果表是MyISAMSpring事務(wù)管理器初始化時也不報錯執(zhí)行時DataSourceTransactionManager還是會調(diào)setAutoCommit(false)但引擎層面不認等于白忙。1.6 final類或final方法CGLIB也救不了Spring事務(wù)默認用AOP代理。如果目標類配置了JDK動態(tài)代理基于接口那沒問題如果走CGLIB基于類繼承生成子類那么final類無法被繼承final方法無法被重寫代理自然失效。Spring Boot 2.x之后默認proxyTargetClasstrue走CGLIBfinal問題就浮出水面了。很多人把service類寫成final為了防繼承結(jié)果事務(wù)全失效。排查方法啟動時看日志里是JdkDynamicAopProxy還是CglibAopProxy再看你的類和方法有沒有final修飾符。1.7 事務(wù)管理器沒配置或配置錯了Spring Boot的DataSourceAutoConfiguration會自動配置DataSourceTransactionManager但你如果引入了多數(shù)據(jù)源或者自定義了DataSource而沒有配套注冊PlatformTransactionManager那Transactional就會失效。另外EnableTransactionManagement注解在Spring Boot里默認開啟不需要你重復(fù)添加。但如果你用了Spring MVC非Boot項目忘了加EnableTransactionManagement事務(wù)也會靜默失效。排查清單很簡單Transactional方法執(zhí)行的線程棧里有沒有TransactionInterceptor有就是代理生效了沒有就是代理沒生效。2. Spring事務(wù)的底層運作機制從JDBC到動態(tài)代理很多人用Transactional用了好幾年但完全不知道它背后發(fā)生了什么。面試被問Spring事務(wù)是怎么實現(xiàn)的只會答AOP兩個字就再也說不出更多了。其實底層鏈路沒那么玄拆開看就三層JDBC的事務(wù)能力、Spring的事務(wù)抽象、AOP的代理包裝。2.1 第一層JDBC的事務(wù)基石萬事萬物都離不開JDBC。Spring事務(wù)再花哨落到底層就是這三行代碼Connection conn dataSource.getConnection(); conn.setAutoCommit(false); // 關(guān)閉自動提交 conn.commit(); // 提交 conn.rollback(); // 回滾setAutoCommit(false)的意思是之后的SQL不會立即生效必須等commit()才真正寫入數(shù)據(jù)庫MySQL的binlog和redolog層面是另一套機制。如果中途異常調(diào)用rollback()之前的所有操作全部撤銷。所以Spring事務(wù)的本質(zhì)就是幫你管理Connection在合適的時機調(diào)用commit或rollback。就這么簡單。2.2 第二層PlatformTransactionManager抽象Spring抽象了一個接口——PlatformTransactionManager核心方法就三個public interface PlatformTransactionManager { TransactionStatus getTransaction(TransactionDefinition definition); void commit(TransactionStatus status); void rollback(TransactionStatus status); }getTransaction獲取或創(chuàng)建事務(wù)。注意這里的措辭——如果你已經(jīng)在事務(wù)里根據(jù)傳播行為決定是復(fù)用當前事務(wù)還是掛起后新建。commit提交事務(wù)。但提交前會檢查TransactionStatus里的rollbackOnly標記如果之前有人標記了只回滾這里會拋UnexpectedRollbackException。rollback回滾事務(wù)。常用的實現(xiàn)是DataSourceTransactionManager針對Hibernate有HibernateTransactionManager針對JPA有JpaTransactionManager。DataSourceTransactionManager的doBegin方法做了幾件事從DataSource拿一個Connection。如果當前Connection是自動提交模式關(guān)閉它并記下來方便事務(wù)結(jié)束恢復(fù)。設(shè)置隔離級別如果TransactionDefinition指定了。設(shè)置只讀標志readOnlytrue會走Connection.setReadOnly對MySQL的InnoDB來說這能優(yōu)化一些查詢路徑。把這個Connection綁定到TransactionSynchronizationManager的ThreadLocal里。后面的DAO操作拿到的Connection就是從TransactionSynchronizationManager里取的。這就是同一個事務(wù)里所有SQL共用同一個數(shù)據(jù)庫連接的原理——ThreadLocal綁定。2.3 第三層AOP代理的切入點Spring事務(wù)的AOP基于TransactionInterceptor它實現(xiàn)了MethodInterceptor攔截所有被Transactional標記的方法。調(diào)用鏈是這樣的外部調(diào)用orderService.createOrder()實際調(diào)用的是代理對象的方法。TransactionInterceptor.invoke()被觸發(fā)先調(diào)用TransactionAspectSupport的createTransactionIfNecessary。根據(jù)Transactional上的配置傳播行為、隔離級別、超時等調(diào)用PlatformTransactionManager.getTransaction()。執(zhí)行業(yè)務(wù)方法。方法正常返回提交事務(wù)方法拋異常根據(jù)rollbackFor配置決定是否回滾。清理ThreadLocal中的連接恢復(fù)自動提交狀態(tài)。所以Transactional加在哪個方法上代理就攔哪個方法——事務(wù)邊界就是方法邊界。方法跑多久事務(wù)就開多久。2.4 只讀事務(wù)與UnexpectedRollbackException的真相熱詞里有一條UnexpectedRollbackException: transaction rolled back because it has been marked as rollback-only這是個非常經(jīng)典的問題。場景是這樣的方法A開啟事務(wù)調(diào)用方法BB標記了rollback-onlytrue比如B捕獲了異常但內(nèi)部回滾邏輯已運行。然后A繼續(xù)執(zhí)行正常返回時調(diào)用commit()此時Spring發(fā)現(xiàn)事務(wù)被標記為rollback-only直接拋UnexpectedRollbackException事務(wù)回滾。換句話說你代碼里沒拋異常但事務(wù)已經(jīng)注定要回滾了。這經(jīng)常出現(xiàn)在try-catch吃了異常但沒重新拋出的情況下。排查時看日志里有沒有Transaction rolled back because it has been marked as rollback-only的WARN告警跟著調(diào)用棧就能找到是哪個方法把事務(wù)標記了。3. 事務(wù)傳播行為與隔離級別什么時候用哪個別背口訣網(wǎng)上關(guān)于傳播行為的口訣一大堆什么REQUIRED默認用REQUIRES_NEW記日志NESTED做嵌套背下來容易用對難。我把這幾個傳播行為逐個講透配上真實場景你就能理解了。3.1 傳播行為詳解Spring定義了7種傳播行為大部分項目用到的不超過4種但理解每一種的原理仍然重要。傳播行為含義典型場景REQUIRED有事務(wù)就復(fù)用沒有就新建默認值99%的場景用它SUPPORTS有事務(wù)就加入沒有就無事務(wù)執(zhí)行查詢方法可選MANDATORY必須在事務(wù)中執(zhí)行否則拋異常強制事務(wù)的方法REQUIRES_NEW掛起當前事務(wù)永遠新建一個寫日志、異步通知NOT_SUPPORTED掛起當前事務(wù)以無事務(wù)方式執(zhí)行導(dǎo)出大數(shù)據(jù)量文件NEVER如果有事務(wù)就拋異常強制無事務(wù)的執(zhí)行NESTED嵌套事務(wù)基于保存點Savepoint大批量循環(huán)處理單條失敗不影響整體REQUIRED是默認值理解起來很簡單Spring檢查當前ThreadLocal里有沒有綁定事務(wù)有就加入沒有就新建一個。注意加入意味著共用一個事務(wù)、一個Connection、一套commit/rollback。內(nèi)層方法拋異?；貪L外層也一起回滾。REQUIRES_NEW的核心是掛起。邏輯是從TransactionSynchronizationManager里把當前事務(wù)的Connection解綁、掛起然后新建一個完全獨立的事務(wù)持有獨立的Connection。內(nèi)層事務(wù)提交/回滾不影響外層事務(wù)。外層事務(wù)回滾內(nèi)層已經(jīng)提交的數(shù)據(jù)不會跟著回滾。典型場景就是操作日志業(yè)務(wù)方法開啟事務(wù)日志記錄要獨立提交——不管業(yè)務(wù)成功還是失敗日志都要寫進去。如果你用REQUIRED業(yè)務(wù)回滾時日志也跟著回滾那排查問題的時候就看不到錯誤日志了。NESTED跟REQUIRES_NEW的區(qū)別要講清楚。REQUIRES_NEW是物理事務(wù)獨立的Connection、獨立的commit/rollbackNESTED是邏輯事務(wù)基于Savepoint保存點。內(nèi)層方法失敗回滾到保存點外層可以繼續(xù)執(zhí)行外層最終提交時一起提交所有保存點之前的操作。但注意NESTED需要底層數(shù)據(jù)庫支持保存點。MySQL的InnoDB支持但有些數(shù)據(jù)庫不支持且JpaTransactionManager對NESTED的支持有限。實際項目中能用REQUIRES_NEW解決的就別用NESTED少踩坑。3.2 隔離級別臟讀、不可重復(fù)讀、幻讀Spring事務(wù)隔離級別有五種對應(yīng)JDBC的隔離級別隔離級別臟讀不可重復(fù)讀幻讀說明DEFAULT---使用數(shù)據(jù)庫默認MySQL默認REPEATABLE_READREAD_UNCOMMITTED會會會讀未提交不推薦READ_COMMITTED不會會會Oracle默認REPEATABLE_READ不會不會會MySQL InnoDB下不會MySQL默認SERIALIZABLE不會不會不會串行化性能最差臟讀讀到別的事務(wù)未提交的數(shù)據(jù)。不可重復(fù)讀同一事務(wù)內(nèi)兩次讀取同一數(shù)據(jù)結(jié)果不一樣因為別的事務(wù)提交了更新。幻讀同一事務(wù)內(nèi)兩次查詢返回的記錄數(shù)不一樣因為別的事務(wù)插入了新記錄。MySQL的InnoDB在REPEATABLE_READ級別下通過MVCC多版本并發(fā)控制 Gap Lock間隙鎖實際上消除了幻讀問題。所以MySQL默認的REPEATABLE_READ比Oracle的READ_COMMITTED在某些場景下更嚴格。實際項目中我見過很多團隊把隔離級別統(tǒng)一設(shè)成READ_COMMITTED理由是MySQL的RR有間隙鎖并發(fā)插入容易死鎖。這個說法有一定道理但不是絕對的。如果你的系統(tǒng)沒有復(fù)雜的范圍查詢并發(fā)插入場景RR不會成為瓶頸如果你確實遇到死鎖頻繁再降級也不遲。3.3 事務(wù)超時與回滾策略Transactional(timeout 5)表示事務(wù)最多執(zhí)行5秒超時則強制回滾。底層實現(xiàn)是JDBC的Connection.setNetworkTimeout或者由Spring在每次SQL執(zhí)行前檢查時間不同實現(xiàn)有差異。但要注意timeout是從事務(wù)開始到最后一次SQL執(zhí)行的時間不是方法總耗時。如果你的方法在事務(wù)前做了一堆耗時操作比如遠程調(diào)用這部分不計入事務(wù)超時。所以不要指望timeout能保護整體方法執(zhí)行時間。關(guān)于回滾策略我再強調(diào)一次// 推薦寫法 Transactional(rollbackFor Exception.class) // 或者只回滾特定異常 Transactional(rollbackFor BizException.class, noRollbackFor IllegalStateException.class)noRollbackFor用的場景不多但有一種情況很實用某些非關(guān)鍵數(shù)據(jù)比如統(tǒng)計緩存的更新失敗不應(yīng)該讓主事務(wù)回滾可以列在noRollbackFor里。4. 編程式事務(wù)當Transactional真的不合適時Transactional是聲明式事務(wù)用起來方便但有三個致命弱點事務(wù)粒度太大整個方法一個事務(wù)如果方法里有網(wǎng)絡(luò)調(diào)用或批量循環(huán)事務(wù)會長時間占用數(shù)據(jù)庫連接。自調(diào)用失效前面已經(jīng)講過了。無法精確控制提交時機想先做幾步提交再繼續(xù)做Transactional實現(xiàn)不了。這時候就該上手編程式事務(wù)了。Spring提供了TransactionTemplate。4.1 TransactionTemplate的用法Service public class OrderService { private final TransactionTemplate transactionTemplate; public OrderService(PlatformTransactionManager transactionManager) { this.transactionTemplate new TransactionTemplate(transactionManager); // 可以設(shè)置默認配置 this.transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); this.transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED); } public void createOrder(OrderDTO dto) { transactionTemplate.executeWithoutResult(status - { stockMapper.deduct(dto.getSkuId(), dto.getQuantity()); orderMapper.insert(buildOrder(dto)); }); } }TransactionTemplate.execute回調(diào)里你可以在任何地方開啟事務(wù)塊粒度完全由自己控制。更重要的是它徹底繞開了自調(diào)用問題——因為你是直接調(diào)用事務(wù)管理器不走代理。還有一個場景強烈推薦用TransactionTemplate大批量循環(huán)插入。如果用Transactional包住整個for循環(huán)幾萬條數(shù)據(jù)一個事務(wù)提交時數(shù)據(jù)庫壓力巨大一旦失敗全部回滾代價太高。改成循環(huán)內(nèi)用TransactionTemplate每100條一個事務(wù)失敗了只回滾這一批配合日志記錄失敗批次整體效率和可靠性都高很多。4.2 手動控制TransactionStatus如果execute回調(diào)不適合你比如需要事務(wù)中間做分支判斷、需要中途提交可以用更底層的PlatformTransactionManagerAutowired private PlatformTransactionManager transactionManager; public void complexBiz() { DefaultTransactionDefinition def new DefaultTransactionDefinition(); def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); TransactionStatus status transactionManager.getTransaction(def); try { // 業(yè)務(wù)邏輯1 dao.update(...); // 到這里先提交一次 transactionManager.commit(status); // 開啟新事務(wù) TransactionStatus status2 transactionManager.getTransaction(def); try { // 業(yè)務(wù)邏輯2 dao.insert(...); transactionManager.commit(status2); } catch (Exception e) { transactionManager.rollback(status2); throw e; } } catch (Exception e) { transactionManager.rollback(status); throw e; } }這段代碼展示了如何手動控制多段事務(wù)但我強烈不建議在業(yè)務(wù)代碼里寫這種底層代碼——容易出錯而且代碼很難讀。99%的場景TransactionTemplate夠用了。4.3 編程式事務(wù)的注意點TransactionTemplate是線程安全的可以做成Bean注入不要每次new一個。executeWithoutResult和execute的區(qū)別后者可以返回業(yè)務(wù)結(jié)果前者只能執(zhí)行不能返回。需要返回值就用execute。事務(wù)回調(diào)里拋出的異常RuntimeException會觸發(fā)回滾檢查型異常默認不會。要回滾檢查型異常需要手動status.setRollbackOnly()或者包裝成RuntimeException。5. 多數(shù)據(jù)源與分布式事務(wù)跳出單庫思維的邊界單庫單事務(wù)的好日子總有到頭的時候。微服務(wù)一拆、分庫一搞Transactional就管不住跨庫的數(shù)據(jù)一致性了。我先講清楚Spring事務(wù)在多數(shù)據(jù)源下的表現(xiàn)再展開分布式事務(wù)。5.1 多數(shù)據(jù)源下的事務(wù)各管各的如果你配置了兩個DataSource比如一個主庫一個從庫Spring里注冊了對應(yīng)的兩個PlatformTransactionManager同一個Transactional方法里操作了兩個庫——那這兩個庫的事務(wù)是互相獨立的。主庫提交成功、從庫提交失敗你沒有任何辦法通過單機事務(wù)解決。Spring Boot里處理多數(shù)據(jù)源的常規(guī)姿勢是Transactional(transactionManager xxxTransactionManager)指定用哪個事務(wù)管理器。方法里操作另一個庫那份數(shù)據(jù)不在事務(wù)保護范圍內(nèi)。所以多數(shù)據(jù)源場景下的策略是一個事務(wù)只操作一種數(shù)據(jù)源。跨數(shù)據(jù)源的業(yè)務(wù)要么拆分方法要么引入分布式事務(wù)方案不要指望Transactional救你。5.2 分布式事務(wù)的主流方案對比分布式事務(wù)是個大話題我只挑主流方案講給個選型思路。XA協(xié)議兩階段提交2PCXA是最正統(tǒng)的分布式事務(wù)協(xié)議分兩步準備階段所有參與者執(zhí)行SQL但不提交各自保留Undo/Redo log和提交階段協(xié)調(diào)者發(fā)提交指令各參與者提交。問題在于準備階段會一直持有數(shù)據(jù)庫鎖高并發(fā)場景下鎖沖突嚴重性能非常差。Java里典型的實現(xiàn)是Atomikos、Bitronix。說實話互聯(lián)網(wǎng)高并發(fā)場景用XA的很少了更多出現(xiàn)在金融等強一致性要求的內(nèi)部系統(tǒng)。TCCTry-Confirm-CancelTCC把每個操作拆成三個階段Try預(yù)留資源、Confirm確認執(zhí)行、Cancel取消釋放。優(yōu)點是業(yè)務(wù)層面控制粒度性能比XA好很多缺點是侵入性極強每個業(yè)務(wù)都要寫三套邏輯。典型場景賬戶轉(zhuǎn)賬。Try階段凍結(jié)轉(zhuǎn)出金額Confirm階段扣款Cancel階段解凍。這個方案需要深入理解業(yè)務(wù)才能寫得對如果你只是想快速實現(xiàn)一個分布式事務(wù)TCC的學(xué)習(xí)成本挺高的。消息事務(wù) 最終一致性這是目前最常用、成本最低的方案。思路很簡單利用本地事務(wù)把業(yè)務(wù)操作和發(fā)消息綁定在同一次數(shù)據(jù)庫事務(wù)里通過消息中間件RocketMQ/RabbitMQ最終把數(shù)據(jù)變更同步給其他服務(wù)。舉個訂單和積分的例子開啟本地事務(wù)插入訂單表同時插入積分消息表。本地事務(wù)提交后后臺任務(wù)或MQ的事務(wù)消息機制把積分消息表里未發(fā)送的記錄發(fā)到MQ。積分服務(wù)從MQ消費消息給用戶加積分。如果積分服務(wù)失敗消息進入重試隊列直到成功。這種方案做不到強一致中間會有一段數(shù)據(jù)不一致的時間窗口但絕大多數(shù)業(yè)務(wù)都能接受。核心機制是本地消息表實現(xiàn)成本低、不用引入重量級中間件是目前國內(nèi)互聯(lián)網(wǎng)公司的首選方案。Seata的AT模式Seata是阿里開源的分布式事務(wù)框架AT模式的思路是代理你的SQL記錄Before Image和After Image數(shù)據(jù)快照在全局提交時自動執(zhí)行補償SQL。對業(yè)務(wù)代碼侵入性很小但性能有一定損耗每行數(shù)據(jù)要記錄前后快照。如果你的系統(tǒng)需要跨服務(wù)事務(wù)、又不想太動代碼Seata AT是可以考慮的。5.3 選擇建議場景推薦方案單體應(yīng)用單數(shù)據(jù)庫什么都不用本地事務(wù)夠用微服務(wù)對一致性要求不高本地消息表 MQ最終一致微服務(wù)強一致要求高Seata AT 或 TCC金融級強一致低并發(fā)XA/2PC非核心數(shù)據(jù)可以容忍短暫不一致MQ異步 對賬補償分布式事務(wù)沒有銀彈。選型的核心不是哪個方案高級而是你的業(yè)務(wù)能容忍多大程度的不一致。6. 事務(wù)排查工具箱從日志到監(jiān)控的一整套姿勢事務(wù)的問題一旦出現(xiàn)往往都是線上的、隱性的、難復(fù)現(xiàn)的。所以一定要有一套預(yù)防和排查的手段而不是等出了問題再手忙腳亂。6.1 日志配置把事務(wù)邊界打印出來Spring的事務(wù)日志默認是DEBUG級別不打開根本看不到。在application.yml里配置logging: level: org.springframework.transaction: DEBUG org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG org.springframework.jdbc.datasource.JdbcTransactionManager: DEBUG打開后你會看到類似這樣的日志Obtained JDBC transaction from DataSource [HikariDataSource (HikariPool-1)] Participating in existing transaction Initiating transaction commit Initiating transaction rollback這些日志的排列能幫你快速判斷事務(wù)有沒有開啟、是新建還是復(fù)用、提交還是回滾、有沒有因為rollback-only被強制回滾。6.2 ThreadLocal狀態(tài)的運行時監(jiān)控如果你懷疑某個方法執(zhí)行時事務(wù)狀態(tài)不對可以在代碼里手動檢測import org.springframework.transaction.support.TransactionSynchronizationManager; boolean isInTransaction TransactionSynchronizationManager.isActualTransactionActive(); System.out.println(當前是否在事務(wù)中: isInTransaction);isActualTransactionActive()返回true說明當前線程確實有數(shù)據(jù)庫事務(wù)處于活動狀態(tài)。如果外面標了Transactional但這里返回false說明代理沒生效——自調(diào)用、final方法、私有方法逐個排查。還可以查看當前事務(wù)名Object name TransactionSynchronizationManager.getCurrentTransactionName();這能幫你快速定位當前事務(wù)是哪個方法開啟的。6.3 監(jiān)控事務(wù)耗時與連接占用事務(wù)另一個容易忽略的問題是連接泄漏和長事務(wù)。一個事務(wù)如果執(zhí)行了幾十秒連接就占用了幾十秒連接池很快被打滿。建議做法在DataSource層加慢SQL日志HikariCP有connectionTimeout、validationTimeout配置同時開啟leakDetectionThreshold檢測連接泄漏。用TransactionSynchronizationManager.registerSynchronization注冊事務(wù)同步回調(diào)統(tǒng)計每個事務(wù)的耗時。Transactional public void bizMethod() { long start System.currentTimeMillis(); TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { Override public void afterCompletion(int status) { long cost System.currentTimeMillis() - start; if (cost 1000) { log.warn(事務(wù)耗時過長: {}ms, status{}, cost, status); } } }); }這個方法能精確定位哪個事務(wù)方法最耗時但它需要每一個業(yè)務(wù)方法都加一遍侵入性強。更好的方案是寫一個AOP切面統(tǒng)一攔截Transactional方法做耗時統(tǒng)計。6.4 事務(wù)失效排查的標準操作流程如果線上出現(xiàn)了疑似事務(wù)失效的問題我的排查順序是這樣的看日志打開事務(wù)DEBUG日志確認方法執(zhí)行時有沒有Obtained JDBC Transaction記錄。沒有就是代理沒生效走第2步有就繼續(xù)看提交/回滾記錄走第5步?？捶椒ê灻遣皇莗ublic類或方法有沒有final看調(diào)用方是不是同一個類內(nèi)部調(diào)用是不是沒有被Spring管理的對象比如new出來的看注解Transactional有沒有寫對rollbackFor有沒有配多數(shù)據(jù)源下transactionManager指對了沒有看異常異常有沒有被try-catch吞掉異常類型是不是RuntimeException看數(shù)據(jù)庫表引擎支不支持事務(wù)連接是不是走到了正確的DataSource這套流程走一遍90%的事務(wù)問題都能定位。7. 最后的實戰(zhàn)建議事務(wù)規(guī)范從我做起寫到這里我把這些年跟事務(wù)打交道沉淀下來的幾條規(guī)矩放在最后算是個人的實戰(zhàn)總結(jié)也是新項目啟動時的檢查清單。事務(wù)方法要短小精悍。事務(wù)范圍之內(nèi)不要做遠程調(diào)用、不要做復(fù)雜的文件IO、不要進行大批量循環(huán)。否則連接池遲早被打死。把非數(shù)據(jù)庫操作移到事務(wù)外或者拆成多個事務(wù)塊。事務(wù)邊界要盡可能晚開啟盡可能早提交。前置校驗、參數(shù)組裝這些放事務(wù)外真正需要數(shù)據(jù)庫原子性的操作才放進事務(wù)塊。很多人習(xí)慣方法一進來就開事務(wù)其實很多操作根本不需要事務(wù)保護?；貪L配置要顯式寫。Transactional(rollbackFor Exception.class)這行字雖然啰嗦但它能擋住95%的回滾失效問題。自定義的業(yè)務(wù)異常統(tǒng)一繼承RuntimeException省得每個方法都要考慮這個異常會不會回滾。批量處理用TransactionTemplate而不是Transactional。循環(huán)里的事務(wù)一定要用編程式事務(wù)精確控制粒度Transactional包整個循環(huán)就是把數(shù)據(jù)庫往死里逼。分布式事務(wù)不要貪多求全。能靠業(yè)務(wù)流程設(shè)計規(guī)避的就盡量規(guī)避比如通過本地消息表做最終一致性比引入一套重量級分布式事務(wù)框架劃算得多。選型之前先想清楚你的數(shù)據(jù)不一致容忍度。事務(wù)這個東西說到底是數(shù)據(jù)庫連接和錯誤處理時機的管理藝術(shù)。理解底層機制比背多少面試題都管用。希望這篇文章里踩過的坑、總結(jié)的思路能讓你少走幾條彎路。 Spring事務(wù)失效的7個坑與底層原理：從JDBC到分布式事務(wù)
1. 事務(wù)失效的七宗罪我踩過的坑你大概率也會踩先講個真實事故。幾年前我維護過一個電商訂單系統(tǒng)線上出了一個詭異的bug用戶支付成功后訂單狀態(tài)正常更新但庫存卻莫名其妙多扣了一次。代碼看起來完全沒問題——service方法上明明白白標著Transactional數(shù)據(jù)庫也確認是InnoDB。查了兩天才定位到根因同一個類里方法A調(diào)用方法BB的事務(wù)注解根本沒生效。這就是Spring事務(wù)最經(jīng)典的坑之一自調(diào)用繞過代理。Transactional依賴AOP代理生效而Spring的代理機制決定了一個類內(nèi)部的方法調(diào)用是不會經(jīng)過代理對象的。this.orderService.update()拿到的這個this根本不是Spring容器里那個被代理過的bean而是原始對象。原始對象上的注解Spring根本看不見。結(jié)果就是你以為開啟了事務(wù)實際上沒有。庫存扣減在無事務(wù)狀態(tài)下執(zhí)行訂單那邊一旦報錯回滾庫存早就提交了。1.1 自調(diào)用問題最隱蔽的事務(wù)殺手自調(diào)用這個坑的隱蔽之處在于它不會報錯不會警告日志里什么都看不出來只有數(shù)據(jù)對不上賬的時候才會暴露。Service public class OrderService { Transactional public void createOrder(OrderDTO dto) { // 扣庫存 stockService.deduct(dto.getSkuId(), dto.getQuantity()); // 插入訂單 orderMapper.insert(buildOrder(dto)); // 這里調(diào)用了自身方法事務(wù)注解失效 this.sendNotification(dto); } Transactional(propagation Propagation.REQUIRES_NEW) public void sendNotification(OrderDTO dto) { // 通知邏輯 } }上面這段代碼里sendNotification的REQUIRES_NEW完全無效。因為this.sendNotification()走的是原始對象不是代理。解決辦法有三個把需要事務(wù)的方法挪到另一個Service類——最推薦職責也最清晰。注入自身代理Autowired private OrderService self;然后調(diào)用self.sendNotification()。使用AopContext.currentProxy()需要開啟EnableAspectJAutoProxy(exposeProxy true)然后((OrderService) AopContext.currentProxy()).sendNotification()。方案2最實用但要注意循環(huán)依賴問題——Spring 4.3之后字段注入的循環(huán)依賴是允許的但構(gòu)造器注入就不行。方案3代碼看著別扭但確實有效。1.2 非public方法注解白寫了Transactional用在private或者protected方法上Spring容器啟動時根本不報錯但方法執(zhí)行時事務(wù)就是沒開。原理不復(fù)雜Spring AOP生成代理的時候JDK動態(tài)代理基于接口只代理public方法CGLIB雖然能代理非public方法但Spring官方明確說了Transactional只支持public方法。最騷的是如果你把Transactional放在public方法上、但里面調(diào)用了private方法private方法里的事務(wù)注解同樣無效——因為事務(wù)邊界已經(jīng)在public方法的代理上確定了內(nèi)層調(diào)用不會再開啟新事務(wù)除非傳播行為是REQUIRES_NEW。我見過不少項目把Transactional加到private方法上然后一臉疑惑地說為什么回滾了沒生效。排查方法很簡單看日志里有沒有TransactionInterceptor的getTransaction記錄沒有就是代理沒走。1.3 異常被吞回滾了個寂寞這是最常見也最無語的一種。Java的檢查型異常checked exception默認不會觸發(fā)Spring事務(wù)回滾但很多人不知道這一點隨手寫了個throws Exception然后事務(wù)就失效了。Transactional public void transfer(Account from, Account to, BigDecimal amount) throws Exception { accountMapper.decrease(from.getId(), amount); accountMapper.increase(to.getId(), amount); // 業(yè)務(wù)校驗不通過拋了個業(yè)務(wù)異常 throw new BizException(余額不足); }BizException如果是繼承Exception而不是RuntimeException上面這個事務(wù)不會回滾錢就憑空消失了。Spring的默認回滾策略是只回滾RuntimeException和Error。檢查型異常如IOException不會觸發(fā)回滾因為Spring認為你既然顯式聲明了這個異常說明你可以處理它事務(wù)繼續(xù)提交是合理的。解決方案兩個方向業(yè)務(wù)異常統(tǒng)一繼承RuntimeException——大多數(shù)項目的做法最簡單。在Transactional上顯式指定Transactional(rollbackFor Exception.class)——最穩(wěn)一勞永逸。我個人的習(xí)慣是兩者都做自定義業(yè)務(wù)異常繼承RuntimeException同時在Transactional上寫rollbackFor Exception.class。雖然看起來冗余但團隊里總有人會寫檢查型異常。1.4 多線程子線程異常主線程事務(wù)照樣提交Transactional的事務(wù)上下文存在ThreadLocal里子線程拿不到父線程的事務(wù)上下文。Transactional public void batchProcess(ListOrder orders) { orders.parallelStream().forEach(order - { // 這里拋異常父線程事務(wù)不會感知 processOne(order); }); }如果一定要在多線程里用事務(wù)只能每個線程自己開事務(wù)用TransactionTemplate包住子線程的任務(wù)代碼然后在線程池層面做異常聚合——子線程里有任何失敗主線程如何決定是否整體回滾需要自己實現(xiàn)協(xié)調(diào)邏輯。這個問題在批量導(dǎo)入、報表生成、定時任務(wù)場景里非常常見。我的建議是批量任務(wù)盡量不用Transactional包整段而是每條或每批用TransactionTemplate單獨開事務(wù)配合失敗記錄表做補償。這樣既能保證數(shù)據(jù)一致又不會因為一個線程失敗導(dǎo)致大批量回滾。1.5 數(shù)據(jù)庫引擎不支持事務(wù)這個坑現(xiàn)在少了但老項目中還能見到。MySQL的MyISAM引擎根本不支持事務(wù)你注解標得再多也沒用。確認方法很簡單SHOW TABLE STATUS WHERE Name your_table;看Engine字段InnoDB支持事務(wù)MyISAM不支持。另外如果表是MyISAMSpring事務(wù)管理器初始化時也不報錯執(zhí)行時DataSourceTransactionManager還是會調(diào)setAutoCommit(false)但引擎層面不認等于白忙。1.6 final類或final方法CGLIB也救不了Spring事務(wù)默認用AOP代理。如果目標類配置了JDK動態(tài)代理基于接口那沒問題如果走CGLIB基于類繼承生成子類那么final類無法被繼承final方法無法被重寫代理自然失效。Spring Boot 2.x之后默認proxyTargetClasstrue走CGLIBfinal問題就浮出水面了。很多人把service類寫成final為了防繼承結(jié)果事務(wù)全失效。排查方法啟動時看日志里是JdkDynamicAopProxy還是CglibAopProxy再看你的類和方法有沒有final修飾符。1.7 事務(wù)管理器沒配置或配置錯了Spring Boot的DataSourceAutoConfiguration會自動配置DataSourceTransactionManager但你如果引入了多數(shù)據(jù)源或者自定義了DataSource而沒有配套注冊PlatformTransactionManager那Transactional就會失效。另外EnableTransactionManagement注解在Spring Boot里默認開啟不需要你重復(fù)添加。但如果你用了Spring MVC非Boot項目忘了加EnableTransactionManagement事務(wù)也會靜默失效。排查清單很簡單Transactional方法執(zhí)行的線程棧里有沒有TransactionInterceptor有就是代理生效了沒有就是代理沒生效。2. Spring事務(wù)的底層運作機制從JDBC到動態(tài)代理很多人用Transactional用了好幾年但完全不知道它背后發(fā)生了什么。面試被問Spring事務(wù)是怎么實現(xiàn)的只會答AOP兩個字就再也說不出更多了。其實底層鏈路沒那么玄拆開看就三層JDBC的事務(wù)能力、Spring的事務(wù)抽象、AOP的代理包裝。2.1 第一層JDBC的事務(wù)基石萬事萬物都離不開JDBC。Spring事務(wù)再花哨落到底層就是這三行代碼Connection conn dataSource.getConnection(); conn.setAutoCommit(false); // 關(guān)閉自動提交 conn.commit(); // 提交 conn.rollback(); // 回滾setAutoCommit(false)的意思是之后的SQL不會立即生效必須等commit()才真正寫入數(shù)據(jù)庫MySQL的binlog和redolog層面是另一套機制。如果中途異常調(diào)用rollback()之前的所有操作全部撤銷。所以Spring事務(wù)的本質(zhì)就是幫你管理Connection在合適的時機調(diào)用commit或rollback。就這么簡單。2.2 第二層PlatformTransactionManager抽象Spring抽象了一個接口——PlatformTransactionManager核心方法就三個public interface PlatformTransactionManager { TransactionStatus getTransaction(TransactionDefinition definition); void commit(TransactionStatus status); void rollback(TransactionStatus status); }getTransaction獲取或創(chuàng)建事務(wù)。注意這里的措辭——如果你已經(jīng)在事務(wù)里根據(jù)傳播行為決定是復(fù)用當前事務(wù)還是掛起后新建。commit提交事務(wù)。但提交前會檢查TransactionStatus里的rollbackOnly標記如果之前有人標記了只回滾這里會拋UnexpectedRollbackException。rollback回滾事務(wù)。常用的實現(xiàn)是DataSourceTransactionManager針對Hibernate有HibernateTransactionManager針對JPA有JpaTransactionManager。DataSourceTransactionManager的doBegin方法做了幾件事從DataSource拿一個Connection。如果當前Connection是自動提交模式關(guān)閉它并記下來方便事務(wù)結(jié)束恢復(fù)。設(shè)置隔離級別如果TransactionDefinition指定了。設(shè)置只讀標志readOnlytrue會走Connection.setReadOnly對MySQL的InnoDB來說這能優(yōu)化一些查詢路徑。把這個Connection綁定到TransactionSynchronizationManager的ThreadLocal里。后面的DAO操作拿到的Connection就是從TransactionSynchronizationManager里取的。這就是同一個事務(wù)里所有SQL共用同一個數(shù)據(jù)庫連接的原理——ThreadLocal綁定。2.3 第三層AOP代理的切入點Spring事務(wù)的AOP基于TransactionInterceptor它實現(xiàn)了MethodInterceptor攔截所有被Transactional標記的方法。調(diào)用鏈是這樣的外部調(diào)用orderService.createOrder()實際調(diào)用的是代理對象的方法。TransactionInterceptor.invoke()被觸發(fā)先調(diào)用TransactionAspectSupport的createTransactionIfNecessary。根據(jù)Transactional上的配置傳播行為、隔離級別、超時等調(diào)用PlatformTransactionManager.getTransaction()。執(zhí)行業(yè)務(wù)方法。方法正常返回提交事務(wù)方法拋異常根據(jù)rollbackFor配置決定是否回滾。清理ThreadLocal中的連接恢復(fù)自動提交狀態(tài)。所以Transactional加在哪個方法上代理就攔哪個方法——事務(wù)邊界就是方法邊界。方法跑多久事務(wù)就開多久。2.4 只讀事務(wù)與UnexpectedRollbackException的真相熱詞里有一條UnexpectedRollbackException: transaction rolled back because it has been marked as rollback-only這是個非常經(jīng)典的問題。場景是這樣的方法A開啟事務(wù)調(diào)用方法BB標記了rollback-onlytrue比如B捕獲了異常但內(nèi)部回滾邏輯已運行。然后A繼續(xù)執(zhí)行正常返回時調(diào)用commit()此時Spring發(fā)現(xiàn)事務(wù)被標記為rollback-only直接拋UnexpectedRollbackException事務(wù)回滾。換句話說你代碼里沒拋異常但事務(wù)已經(jīng)注定要回滾了。這經(jīng)常出現(xiàn)在try-catch吃了異常但沒重新拋出的情況下。排查時看日志里有沒有Transaction rolled back because it has been marked as rollback-only的WARN告警跟著調(diào)用棧就能找到是哪個方法把事務(wù)標記了。3. 事務(wù)傳播行為與隔離級別什么時候用哪個別背口訣網(wǎng)上關(guān)于傳播行為的口訣一大堆什么REQUIRED默認用REQUIRES_NEW記日志NESTED做嵌套背下來容易用對難。我把這幾個傳播行為逐個講透配上真實場景你就能理解了。3.1 傳播行為詳解Spring定義了7種傳播行為大部分項目用到的不超過4種但理解每一種的原理仍然重要。傳播行為含義典型場景REQUIRED有事務(wù)就復(fù)用沒有就新建默認值99%的場景用它SUPPORTS有事務(wù)就加入沒有就無事務(wù)執(zhí)行查詢方法可選MANDATORY必須在事務(wù)中執(zhí)行否則拋異常強制事務(wù)的方法REQUIRES_NEW掛起當前事務(wù)永遠新建一個寫日志、異步通知NOT_SUPPORTED掛起當前事務(wù)以無事務(wù)方式執(zhí)行導(dǎo)出大數(shù)據(jù)量文件NEVER如果有事務(wù)就拋異常強制無事務(wù)的執(zhí)行NESTED嵌套事務(wù)基于保存點Savepoint大批量循環(huán)處理單條失敗不影響整體REQUIRED是默認值理解起來很簡單Spring檢查當前ThreadLocal里有沒有綁定事務(wù)有就加入沒有就新建一個。注意加入意味著共用一個事務(wù)、一個Connection、一套commit/rollback。內(nèi)層方法拋異?；貪L外層也一起回滾。REQUIRES_NEW的核心是掛起。邏輯是從TransactionSynchronizationManager里把當前事務(wù)的Connection解綁、掛起然后新建一個完全獨立的事務(wù)持有獨立的Connection。內(nèi)層事務(wù)提交/回滾不影響外層事務(wù)。外層事務(wù)回滾內(nèi)層已經(jīng)提交的數(shù)據(jù)不會跟著回滾。典型場景就是操作日志業(yè)務(wù)方法開啟事務(wù)日志記錄要獨立提交——不管業(yè)務(wù)成功還是失敗日志都要寫進去。如果你用REQUIRED業(yè)務(wù)回滾時日志也跟著回滾那排查問題的時候就看不到錯誤日志了。NESTED跟REQUIRES_NEW的區(qū)別要講清楚。REQUIRES_NEW是物理事務(wù)獨立的Connection、獨立的commit/rollbackNESTED是邏輯事務(wù)基于Savepoint保存點。內(nèi)層方法失敗回滾到保存點外層可以繼續(xù)執(zhí)行外層最終提交時一起提交所有保存點之前的操作。但注意NESTED需要底層數(shù)據(jù)庫支持保存點。MySQL的InnoDB支持但有些數(shù)據(jù)庫不支持且JpaTransactionManager對NESTED的支持有限。實際項目中能用REQUIRES_NEW解決的就別用NESTED少踩坑。3.2 隔離級別臟讀、不可重復(fù)讀、幻讀Spring事務(wù)隔離級別有五種對應(yīng)JDBC的隔離級別隔離級別臟讀不可重復(fù)讀幻讀說明DEFAULT---使用數(shù)據(jù)庫默認MySQL默認REPEATABLE_READREAD_UNCOMMITTED會會會讀未提交不推薦READ_COMMITTED不會會會Oracle默認REPEATABLE_READ不會不會會MySQL InnoDB下不會MySQL默認SERIALIZABLE不會不會不會串行化性能最差臟讀讀到別的事務(wù)未提交的數(shù)據(jù)。不可重復(fù)讀同一事務(wù)內(nèi)兩次讀取同一數(shù)據(jù)結(jié)果不一樣因為別的事務(wù)提交了更新。幻讀同一事務(wù)內(nèi)兩次查詢返回的記錄數(shù)不一樣因為別的事務(wù)插入了新記錄。MySQL的InnoDB在REPEATABLE_READ級別下通過MVCC多版本并發(fā)控制 Gap Lock間隙鎖實際上消除了幻讀問題。所以MySQL默認的REPEATABLE_READ比Oracle的READ_COMMITTED在某些場景下更嚴格。實際項目中我見過很多團隊把隔離級別統(tǒng)一設(shè)成READ_COMMITTED理由是MySQL的RR有間隙鎖并發(fā)插入容易死鎖。這個說法有一定道理但不是絕對的。如果你的系統(tǒng)沒有復(fù)雜的范圍查詢并發(fā)插入場景RR不會成為瓶頸如果你確實遇到死鎖頻繁再降級也不遲。3.3 事務(wù)超時與回滾策略Transactional(timeout 5)表示事務(wù)最多執(zhí)行5秒超時則強制回滾。底層實現(xiàn)是JDBC的Connection.setNetworkTimeout或者由Spring在每次SQL執(zhí)行前檢查時間不同實現(xiàn)有差異。但要注意timeout是從事務(wù)開始到最后一次SQL執(zhí)行的時間不是方法總耗時。如果你的方法在事務(wù)前做了一堆耗時操作比如遠程調(diào)用這部分不計入事務(wù)超時。所以不要指望timeout能保護整體方法執(zhí)行時間。關(guān)于回滾策略我再強調(diào)一次// 推薦寫法 Transactional(rollbackFor Exception.class) // 或者只回滾特定異常 Transactional(rollbackFor BizException.class, noRollbackFor IllegalStateException.class)noRollbackFor用的場景不多但有一種情況很實用某些非關(guān)鍵數(shù)據(jù)比如統(tǒng)計緩存的更新失敗不應(yīng)該讓主事務(wù)回滾可以列在noRollbackFor里。4. 編程式事務(wù)當Transactional真的不合適時Transactional是聲明式事務(wù)用起來方便但有三個致命弱點事務(wù)粒度太大整個方法一個事務(wù)如果方法里有網(wǎng)絡(luò)調(diào)用或批量循環(huán)事務(wù)會長時間占用數(shù)據(jù)庫連接。自調(diào)用失效前面已經(jīng)講過了。無法精確控制提交時機想先做幾步提交再繼續(xù)做Transactional實現(xiàn)不了。這時候就該上手編程式事務(wù)了。Spring提供了TransactionTemplate。4.1 TransactionTemplate的用法Service public class OrderService { private final TransactionTemplate transactionTemplate; public OrderService(PlatformTransactionManager transactionManager) { this.transactionTemplate new TransactionTemplate(transactionManager); // 可以設(shè)置默認配置 this.transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); this.transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED); } public void createOrder(OrderDTO dto) { transactionTemplate.executeWithoutResult(status - { stockMapper.deduct(dto.getSkuId(), dto.getQuantity()); orderMapper.insert(buildOrder(dto)); }); } }TransactionTemplate.execute回調(diào)里你可以在任何地方開啟事務(wù)塊粒度完全由自己控制。更重要的是它徹底繞開了自調(diào)用問題——因為你是直接調(diào)用事務(wù)管理器不走代理。還有一個場景強烈推薦用TransactionTemplate大批量循環(huán)插入。如果用Transactional包住整個for循環(huán)幾萬條數(shù)據(jù)一個事務(wù)提交時數(shù)據(jù)庫壓力巨大一旦失敗全部回滾代價太高。改成循環(huán)內(nèi)用TransactionTemplate每100條一個事務(wù)失敗了只回滾這一批配合日志記錄失敗批次整體效率和可靠性都高很多。4.2 手動控制TransactionStatus如果execute回調(diào)不適合你比如需要事務(wù)中間做分支判斷、需要中途提交可以用更底層的PlatformTransactionManagerAutowired private PlatformTransactionManager transactionManager; public void complexBiz() { DefaultTransactionDefinition def new DefaultTransactionDefinition(); def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); TransactionStatus status transactionManager.getTransaction(def); try { // 業(yè)務(wù)邏輯1 dao.update(...); // 到這里先提交一次 transactionManager.commit(status); // 開啟新事務(wù) TransactionStatus status2 transactionManager.getTransaction(def); try { // 業(yè)務(wù)邏輯2 dao.insert(...); transactionManager.commit(status2); } catch (Exception e) { transactionManager.rollback(status2); throw e; } } catch (Exception e) { transactionManager.rollback(status); throw e; } }這段代碼展示了如何手動控制多段事務(wù)但我強烈不建議在業(yè)務(wù)代碼里寫這種底層代碼——容易出錯而且代碼很難讀。99%的場景TransactionTemplate夠用了。4.3 編程式事務(wù)的注意點TransactionTemplate是線程安全的可以做成Bean注入不要每次new一個。executeWithoutResult和execute的區(qū)別后者可以返回業(yè)務(wù)結(jié)果前者只能執(zhí)行不能返回。需要返回值就用execute。事務(wù)回調(diào)里拋出的異常RuntimeException會觸發(fā)回滾檢查型異常默認不會。要回滾檢查型異常需要手動status.setRollbackOnly()或者包裝成RuntimeException。5. 多數(shù)據(jù)源與分布式事務(wù)跳出單庫思維的邊界單庫單事務(wù)的好日子總有到頭的時候。微服務(wù)一拆、分庫一搞Transactional就管不住跨庫的數(shù)據(jù)一致性了。我先講清楚Spring事務(wù)在多數(shù)據(jù)源下的表現(xiàn)再展開分布式事務(wù)。5.1 多數(shù)據(jù)源下的事務(wù)各管各的如果你配置了兩個DataSource比如一個主庫一個從庫Spring里注冊了對應(yīng)的兩個PlatformTransactionManager同一個Transactional方法里操作了兩個庫——那這兩個庫的事務(wù)是互相獨立的。主庫提交成功、從庫提交失敗你沒有任何辦法通過單機事務(wù)解決。Spring Boot里處理多數(shù)據(jù)源的常規(guī)姿勢是Transactional(transactionManager xxxTransactionManager)指定用哪個事務(wù)管理器。方法里操作另一個庫那份數(shù)據(jù)不在事務(wù)保護范圍內(nèi)。所以多數(shù)據(jù)源場景下的策略是一個事務(wù)只操作一種數(shù)據(jù)源。跨數(shù)據(jù)源的業(yè)務(wù)要么拆分方法要么引入分布式事務(wù)方案不要指望Transactional救你。5.2 分布式事務(wù)的主流方案對比分布式事務(wù)是個大話題我只挑主流方案講給個選型思路。XA協(xié)議兩階段提交2PCXA是最正統(tǒng)的分布式事務(wù)協(xié)議分兩步準備階段所有參與者執(zhí)行SQL但不提交各自保留Undo/Redo log和提交階段協(xié)調(diào)者發(fā)提交指令各參與者提交。問題在于準備階段會一直持有數(shù)據(jù)庫鎖高并發(fā)場景下鎖沖突嚴重性能非常差。Java里典型的實現(xiàn)是Atomikos、Bitronix。說實話互聯(lián)網(wǎng)高并發(fā)場景用XA的很少了更多出現(xiàn)在金融等強一致性要求的內(nèi)部系統(tǒng)。TCCTry-Confirm-CancelTCC把每個操作拆成三個階段Try預(yù)留資源、Confirm確認執(zhí)行、Cancel取消釋放。優(yōu)點是業(yè)務(wù)層面控制粒度性能比XA好很多缺點是侵入性極強每個業(yè)務(wù)都要寫三套邏輯。典型場景賬戶轉(zhuǎn)賬。Try階段凍結(jié)轉(zhuǎn)出金額Confirm階段扣款Cancel階段解凍。這個方案需要深入理解業(yè)務(wù)才能寫得對如果你只是想快速實現(xiàn)一個分布式事務(wù)TCC的學(xué)習(xí)成本挺高的。消息事務(wù) 最終一致性這是目前最常用、成本最低的方案。思路很簡單利用本地事務(wù)把業(yè)務(wù)操作和發(fā)消息綁定在同一次數(shù)據(jù)庫事務(wù)里通過消息中間件RocketMQ/RabbitMQ最終把數(shù)據(jù)變更同步給其他服務(wù)。舉個訂單和積分的例子開啟本地事務(wù)插入訂單表同時插入積分消息表。本地事務(wù)提交后后臺任務(wù)或MQ的事務(wù)消息機制把積分消息表里未發(fā)送的記錄發(fā)到MQ。積分服務(wù)從MQ消費消息給用戶加積分。如果積分服務(wù)失敗消息進入重試隊列直到成功。這種方案做不到強一致中間會有一段數(shù)據(jù)不一致的時間窗口但絕大多數(shù)業(yè)務(wù)都能接受。核心機制是本地消息表實現(xiàn)成本低、不用引入重量級中間件是目前國內(nèi)互聯(lián)網(wǎng)公司的首選方案。Seata的AT模式Seata是阿里開源的分布式事務(wù)框架AT模式的思路是代理你的SQL記錄Before Image和After Image數(shù)據(jù)快照在全局提交時自動執(zhí)行補償SQL。對業(yè)務(wù)代碼侵入性很小但性能有一定損耗每行數(shù)據(jù)要記錄前后快照。如果你的系統(tǒng)需要跨服務(wù)事務(wù)、又不想太動代碼Seata AT是可以考慮的。5.3 選擇建議場景推薦方案單體應(yīng)用單數(shù)據(jù)庫什么都不用本地事務(wù)夠用微服務(wù)對一致性要求不高本地消息表 MQ最終一致微服務(wù)強一致要求高Seata AT 或 TCC金融級強一致低并發(fā)XA/2PC非核心數(shù)據(jù)可以容忍短暫不一致MQ異步 對賬補償分布式事務(wù)沒有銀彈。選型的核心不是哪個方案高級而是你的業(yè)務(wù)能容忍多大程度的不一致。6. 事務(wù)排查工具箱從日志到監(jiān)控的一整套姿勢事務(wù)的問題一旦出現(xiàn)往往都是線上的、隱性的、難復(fù)現(xiàn)的。所以一定要有一套預(yù)防和排查的手段而不是等出了問題再手忙腳亂。6.1 日志配置把事務(wù)邊界打印出來Spring的事務(wù)日志默認是DEBUG級別不打開根本看不到。在application.yml里配置logging: level: org.springframework.transaction: DEBUG org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG org.springframework.jdbc.datasource.JdbcTransactionManager: DEBUG打開后你會看到類似這樣的日志Obtained JDBC transaction from DataSource [HikariDataSource (HikariPool-1)] Participating in existing transaction Initiating transaction commit Initiating transaction rollback這些日志的排列能幫你快速判斷事務(wù)有沒有開啟、是新建還是復(fù)用、提交還是回滾、有沒有因為rollback-only被強制回滾。6.2 ThreadLocal狀態(tài)的運行時監(jiān)控如果你懷疑某個方法執(zhí)行時事務(wù)狀態(tài)不對可以在代碼里手動檢測import org.springframework.transaction.support.TransactionSynchronizationManager; boolean isInTransaction TransactionSynchronizationManager.isActualTransactionActive(); System.out.println(當前是否在事務(wù)中: isInTransaction);isActualTransactionActive()返回true說明當前線程確實有數(shù)據(jù)庫事務(wù)處于活動狀態(tài)。如果外面標了Transactional但這里返回false說明代理沒生效——自調(diào)用、final方法、私有方法逐個排查。還可以查看當前事務(wù)名Object name TransactionSynchronizationManager.getCurrentTransactionName();這能幫你快速定位當前事務(wù)是哪個方法開啟的。6.3 監(jiān)控事務(wù)耗時與連接占用事務(wù)另一個容易忽略的問題是連接泄漏和長事務(wù)。一個事務(wù)如果執(zhí)行了幾十秒連接就占用了幾十秒連接池很快被打滿。建議做法在DataSource層加慢SQL日志HikariCP有connectionTimeout、validationTimeout配置同時開啟leakDetectionThreshold檢測連接泄漏。用TransactionSynchronizationManager.registerSynchronization注冊事務(wù)同步回調(diào)統(tǒng)計每個事務(wù)的耗時。Transactional public void bizMethod() { long start System.currentTimeMillis(); TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { Override public void afterCompletion(int status) { long cost System.currentTimeMillis() - start; if (cost 1000) { log.warn(事務(wù)耗時過長: {}ms, status{}, cost, status); } } }); }這個方法能精確定位哪個事務(wù)方法最耗時但它需要每一個業(yè)務(wù)方法都加一遍侵入性強。更好的方案是寫一個AOP切面統(tǒng)一攔截Transactional方法做耗時統(tǒng)計。6.4 事務(wù)失效排查的標準操作流程如果線上出現(xiàn)了疑似事務(wù)失效的問題我的排查順序是這樣的看日志打開事務(wù)DEBUG日志確認方法執(zhí)行時有沒有Obtained JDBC Transaction記錄。沒有就是代理沒生效走第2步有就繼續(xù)看提交/回滾記錄走第5步?？捶椒ê灻遣皇莗ublic類或方法有沒有final看調(diào)用方是不是同一個類內(nèi)部調(diào)用是不是沒有被Spring管理的對象比如new出來的看注解Transactional有沒有寫對rollbackFor有沒有配多數(shù)據(jù)源下transactionManager指對了沒有看異常異常有沒有被try-catch吞掉異常類型是不是RuntimeException看數(shù)據(jù)庫表引擎支不支持事務(wù)連接是不是走到了正確的DataSource這套流程走一遍90%的事務(wù)問題都能定位。7. 最后的實戰(zhàn)建議事務(wù)規(guī)范從我做起寫到這里我把這些年跟事務(wù)打交道沉淀下來的幾條規(guī)矩放在最后算是個人的實戰(zhàn)總結(jié)也是新項目啟動時的檢查清單。事務(wù)方法要短小精悍。事務(wù)范圍之內(nèi)不要做遠程調(diào)用、不要做復(fù)雜的文件IO、不要進行大批量循環(huán)。否則連接池遲早被打死。把非數(shù)據(jù)庫操作移到事務(wù)外或者拆成多個事務(wù)塊。事務(wù)邊界要盡可能晚開啟盡可能早提交。前置校驗、參數(shù)組裝這些放事務(wù)外真正需要數(shù)據(jù)庫原子性的操作才放進事務(wù)塊。很多人習(xí)慣方法一進來就開事務(wù)其實很多操作根本不需要事務(wù)保護?；貪L配置要顯式寫。Transactional(rollbackFor Exception.class)這行字雖然啰嗦但它能擋住95%的回滾失效問題。自定義的業(yè)務(wù)異常統(tǒng)一繼承RuntimeException省得每個方法都要考慮這個異常會不會回滾。批量處理用TransactionTemplate而不是Transactional。循環(huán)里的事務(wù)一定要用編程式事務(wù)精確控制粒度Transactional包整個循環(huán)就是把數(shù)據(jù)庫往死里逼。分布式事務(wù)不要貪多求全。能靠業(yè)務(wù)流程設(shè)計規(guī)避的就盡量規(guī)避比如通過本地消息表做最終一致性比引入一套重量級分布式事務(wù)框架劃算得多。選型之前先想清楚你的數(shù)據(jù)不一致容忍度。事務(wù)這個東西說到底是數(shù)據(jù)庫連接和錯誤處理時機的管理藝術(shù)。理解底層機制比背多少面試題都管用。希望這篇文章里踩過的坑、總結(jié)的思路能讓你少走幾條彎路。