一、分布式事務核心挑戰：分庫分表下的一致性困境
在分布式系統架構中，分庫分表通過將數據分散存儲提升了擴展性和性能，但卻打破了傳統單庫事務的邊界，使得分布式事務成為保障數據一致性的核心難題。其挑戰主要體現在以下三方面：
1.1 ACID特性的分布式撕裂
- 原子性（Atomicity）：跨多個分片的操作需保證全部成功或回滾，如電商下單需同時操作訂單庫、庫存庫和支付庫，任一環節失敗需回滾所有已執行操作。
- 一致性（Consistency）：分庫分表后，全局數據一致性需通過事務協調實現，例如用戶余額扣減與訂單狀態更新需保持一致。
- 隔離性（Isolation）：高并發場景下，跨分片事務需避免臟讀、幻讀，如庫存扣減時需防止其他事務看到中間狀態。
- 持久性（Durability）：事務提交后數據需持久化，分布式環境下需確保多節點日志落盤成功。
1.2 分庫分表的架構特殊性
- 數據分散性：事務操作可能涉及多個分片（如按用戶ID分庫的訂單表與按SKU分庫的庫存表），需協調跨節點事務。
- 分片鍵影響：若事務涉及不同分片鍵（如用戶ID和SKU ID），無法通過分片鍵路由到單一節點，強制跨庫操作。
- 熱點問題：高頻事務可能集中在少數分片（如熱銷商品的庫存分片），導致鎖競爭加劇。
1.3 CAP定理的現實抉擇
- 強一致性（CP）：犧牲可用性換取一致性，適用于金融交易等場景（如銀行轉賬）。
- 最終一致性（AP）：犧牲強一致性換取高可用性，適用于電商下單、社交動態等場景。
- 分庫分表場景下的權衡：多數業務選擇最終一致性，通過異步補償機制實現最終一致，同時保障性能。
二、分布式事務解決方案：從強一致到最終一致
2.1 兩階段提交（2PC）：強一致性的經典方案
2.1.1 核心流程
- 準備階段（PreCommit）
- 協調者（Coordinator）向所有參與者（如訂單庫、庫存庫）發送事務請求，參與者執行事務操作（如扣減庫存）但不提交，記錄undo/redo日志，并返回“準備成功”或“失敗”。
