Java 事務模型與策略深度解析：從本地到高速處理的完整指南

事務模型 vs 事務策略

模型定義事務如何被管理（誰管理、語法規則）；策略解決具體場景用什麼模型、屬性怎麼配、如何優化。混淆兩者是常見錯誤。

Java 平台支持的三大事務模型

四大核心事務策略

1. 客戶端編排事務策略

場景：客戶端發起多個服務調用完成一個業務單元（如下單：扣庫存、建訂單、扣款）。

特點：事務邊界在客戶端，需分佈式事務協調（2PC/補償/TCC）。

技術：Seata AT/XT 模式、Spring Cloud 分佈式事務、Saga 模式編排器。

2. API 層事務策略

場景：服務入口為粗粒度 API（Service Facade），內部多個 DAO/Repository 操作需在同一事務中。

特點：最常見，聲明式事務在 Service 方法上生效。

配置：@Transactional(rollbackFor = Exception.class)，傳播行為 REQUIRED（默認）。

3. 高併發事務策略

場景：高吞吐、低延遲系統，長事務導致鎖競爭、連接池耗盡。

核心原則：縮小事務範圍、縮短事務持有時間。

• 只在必要時開啟事務（避免在事務中調用 RPC/HTTP）。
• 讀操作標記 readOnly=true（優化器可跳過鎖、快照讀）。
• 拆分大事務：本地消息表、事件驅動、最終一致性替代強一致。
• 連接池隔離：核心業務獨立池，防止慢 SQL 擠佔。

4. 高速處理事務策略

場景：極致性能要求（如交易撮合、實時計費），需在保證原子性前提下最大化吞吐。

極端手段：

• 本地事務 + 批量提交（手動控制 commit 頻率）。
• 內存數據庫/緩存作為事務協調中心（Redis Lua 腳本原子操作）。
• 無鎖數據結構、Disruptor 環形隊列單線程串行化業務邏輯。
• 犧牲部分 ACID（如隔離級別降至 READ_COMMITTED 甚至 READ_UNCOMMITTED）。

Spring 與 EJB 3.0 實戰對比

// Spring 聲明式事務（最主流）
@Service
@Transactional(rollbackFor = Exception.class, timeout = 30)
public class OrderService {
    @Autowired OrderMapper orderMapper;
    @Autowired InventoryMapper inventoryMapper;

    public void createOrder(OrderDTO dto) {
        inventoryMapper.deductStock(dto.getSkuId(), dto.getQty()); // 扣庫存
        orderMapper.insert(dto.toOrder()); // 建訂單
        // 異常自動回滾
    }
}

// EJB 3.0 容器管理事務（CMT）
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class OrderBean implements OrderRemote {
    @PersistenceContext EntityManager em;
    @EJB InventoryBean inventoryBean;

    public void createOrder(OrderDTO dto) {
        inventoryBean.deductStock(dto.getSkuId(), dto.getQty());
        em.persist(dto.toOrder());
    }
}

傳播行為選擇指南

避坑指南

1. @Transactional 失效：私有方法、同類內部調用、非 public、異常被捕獲未拋出、非受檢異常需指定 rollbackFor。
2. 長事務殺手：事務中發 RPC、睡眠、大循環、大量數據處理。
3. 連接洩漏：未正確關閉連接、線程池未綁定事務上下文。
4. 分佈式事務濫用：能用最終一致性（消息隊列、本地消息表）解決的，別上 2PC/TCC。

總結

事務模型提供基礎設施，事務策略決定系統穩定性與性能上限。從 API 層策略起步，隨業務演進引入高併發/高速策略，分佈式場景謹慎選擇客戶端編排。深諳傳播行為、隔離級別、鎖機制，才能駕馭複雜事務場景。