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

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

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

　　基本原理

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

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

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

　　建表時(shí)增加一個(gè)隱藏字段，用于記錄GTID。

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

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