嵌套事務是指在事務執行過程中啟動另一個事務形成的層級調用結構，主要用于處理跨服務或復雜業務場景的事務一致性控制。其核心是通過事務傳播機制管理多個操作的原子性，具體原理和應用如下：

---

一、核心概念與工作原理

1. 層級結構

   • 嵌套事務由頂層事務（主事務）和子事務構成，子事務可進一步嵌套形成樹形結構。
   • 頂層事務提交時，所有子事務一并提交；頂層事務回滾則全部回滾。
   • 子事務可獨立回滾（如數據庫的SAVEPOINT機制），不影響其他操作。

2. 傳播機制（以Spring為例）

   • REQUIRED（默認）：子事務加入主事務，共用同一事務；任一失敗則全局回滾。
   • REQUIRES_NEW：掛起主事務，創建獨立子事務。子事務提交/回滾不影響主事務。
   • NESTED：基于SAVEPOINT創建子事務。子事務失敗僅回滾到保存點，主事務可繼續執行。

   示例：

   @Transactional(propagation = Propagation.REQUIRED)
   public void mainTx() {// 主事務操作subTx(); // 嵌套子事務
   }@Transactional(propagation = Propagation.NESTED)
   public void subTx() {// 子事務操作（可獨立回滾）
   }
   

---

二、典型應用場景

1. 部分回滾需求
   復雜業務中若局部操作失敗（如庫存不足），通過NESTED回滾子事務，主事務繼續處理其他步驟。
   例：電商下單時扣減庫存失敗，僅回滾庫存操作，不影響訂單記錄生成。

2. 跨服務調用
   主服務調用多個子服務時，REQUIRES_NEW確保子服務獨立提交（如日志記錄），避免主業務失敗牽連。

3. 性能隔離
   耗時操作（如報表生成）使用獨立事務，避免阻塞主事務資源。

---

三、技術實現差異

類型	數據庫支持	應用框架支持	事務獨立性
真嵌套事務	部分數據庫（如Oracle）	有限	子事務可獨立提交
邏輯嵌套事務	通用（通過SAVEPOINT模擬）	Spring（NESTED傳播行為）	僅支持部分回滾
獨立事務	所有數據庫	Spring（REQUIRES_NEW）	完全獨立

注：MySQL不支持真嵌套事務，通過SAVEPOINT實現類似效果。

---

四、常見問題與規避方案

1. 事務失效場景

   • 同類方法嵌套調用：Spring基于代理實現事務，同類內調用@Transactional方法時事務不生效。
     → 方案：通過AopContext.currentProxy()或拆分到不同類調用。
   • 異常被捕獲未拋出：子事務異常若被try-catch吞沒，事務不會回滾。
     → 方案：捕獲后顯式拋出RuntimeException或標記回滾（TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()）。

2. 嵌套事務回滾沖突

   • 子事務標記回滾后，主事務提交將引發UnexpectedRollbackException。
     → 方案：使用REQUIRES_NEW分離事務或調整業務邏輯。

---

五、最佳實踐建議

1. 優先選擇REQUIRED：簡單業務直接使用默認傳播行為，避免過度設計。
2. 跨服務慎用嵌套：微服務間通過Saga模式替代嵌套事務。
3. 明確事務邊界：在方法入口顯式聲明傳播行為，避免隱式依賴。

嵌套事務與鏈式事務區別：
鏈式事務（Chained Transaction）是多個獨立事務順序執行（前一事務提交后才啟動下一事務），無嵌套層級關系。

嵌套事務的核心價值在于精細控制事務邊界，需結合業務復雜度權衡實現成本。實際開發中應嚴格測試回滾邏輯，避免部分提交導致數據不一致。