對于分布式數據庫而言，分布式事務控制是重點和難點，一直以來沒有成熟的方案可以突破CAP理論，幾乎每個分布式數據庫研發團隊都在分布式事務控制方案上結合了各自應用特點，進行了針對性的取舍，可以說是八仙過海各顯神通。以下是我對分布式事務控制的理解：

　　分布式事務控制的最終目標是實現一致性，方案大體分為實時一致性和最終一致性兩種。兩階段提交是比較典型的實時一致性方案，提供補償事務和基于消息隊列的異步處理方案是最終一致性方案。兩階段提交由于同步阻塞、存在臟讀可能性等問題，在某些銀行的應用場景下無法使用，如果將隔離級別修改為串行化則可以解決臟讀問題，但對性能影響較大。基于消息隊列的異步處理方案將事務拆分成多個本地子事務，子事務之間通過消息隊列銜接，實現串行執行，單個子事務占用資源的時間很短，并發度高。但這種最終一致性方案如果應用到銀行的應用中勢必影響用戶體驗，而且對應用侵略性較大，實施成本高。

　　在分析了以上事務處理方案的優缺點之后，根據銀行業務對實時一致性的要求，考慮到用戶體驗和實施成本的影響，我們提出了基于全局事務ID（Global transaction ID，以下簡稱GTID）的分布式事務解決方案。

　　基本原理

　　在基于GTID的分布式事務方案（以下簡稱本方案）中，我們把協調參與者和記錄全局事務狀態這兩個功能分開，用計算節點協調各事務參與者進行事務操作，全局事務管理器僅管理全局事務的狀態。為了確保事務狀態正常，全局事務管理采用了實時持久化和實時同步到備機等多重保障機制。本方案事務管理架構如圖1所示。

　　圖1 基于GTID的分布式事務管理方案

　　兩（三）階段提交的核心思想是通過前期的多次準備和協調工作，盡可能讓最后的提交操作能夠成功。而本方案認為大部分事務都可以一次提交成功，因此采用一階段提交+補償事務的方式，如果事務在提交階段有部分節點提交失敗，本方案將回滾已成功提交的事務，而不是讓失敗的節點不斷重試。與兩（三）階段提交相比，本方案在大部分情況下減少了與數據節點的交互次數，降低了鎖沖突概率，提升了事務處理效率。

　　建表時增加一個隱藏字段，用于記錄GTID。

　　每個事務開始時為其申請一個GTID，該GTID是全局唯一且單調遞增的，GTID申請成功后，我們稱該GTID為活躍（Active）狀態，對應該GTID的事務狀態為未提交狀態，若涉及到數據更新，則將GTID更新到本事務將要更新的數據中，事務成功提交后，將GTID釋放，此時我們稱GTID為非活躍（UnActive）狀態，對應的事務狀態為已提交狀態。

　　當事務提交失敗時，提交失敗節點會自動回滾，對于已成功提交的節點，需要將其回滾，數據恢復到更新前的狀態，全部節點回滾完成后，同樣需要將GTID釋放。