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

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

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

　　基本原理

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

　　圖1 基于GTID的分布式事務(wù)管理方案

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

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

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

　　當(dāng)事務(wù)提交失敗時，提交失敗節(jié)點會自動回滾，對于已成功提交的節(jié)點，需要將其回滾，數(shù)據(jù)恢復(fù)到更新前的狀態(tài)，全部節(jié)點回滾完成后，同樣需要將GTID釋放。