2.3　GoldenDB數(shù)據(jù)庫(kù)的前世今生

數(shù)據(jù)庫(kù)是最難遷移的軟件技術(shù)之一，銀行業(yè)被稱為數(shù)據(jù)庫(kù)領(lǐng)域皇冠上的珍珠。2020年，中信銀行和中興通訊聯(lián)合打造的GoldenDB分布式數(shù)據(jù)庫(kù)在中信銀行總行核心系統(tǒng)的使用，證明了國(guó)產(chǎn)自研分布式數(shù)據(jù)庫(kù)摘取皇冠珍珠的能力，也為我國(guó)金融行業(yè)落實(shí)安全可控的國(guó)家戰(zhàn)略提供了參考和借鑒。但GoldenDB數(shù)據(jù)庫(kù)的前世今生，要從2014年開(kāi)始談起。

2014年，是一個(gè)值得記憶的年份。

2014年，開(kāi)源、開(kāi)放的軟件技術(shù)和硬件產(chǎn)品在互聯(lián)網(wǎng)企業(yè)快速發(fā)展的過(guò)程中得到了充分的驗(yàn)證，使用開(kāi)源、開(kāi)放的軟硬件產(chǎn)品來(lái)支撐銀行核心業(yè)務(wù)系統(tǒng)的條件已經(jīng)具備可行性。

2014年，中信銀行正式啟動(dòng)GoldenDB分布式數(shù)據(jù)庫(kù)的研發(fā)，當(dāng)時(shí)可謂大勢(shì)所趨，生逢其時(shí)。首先，安全可控的國(guó)家戰(zhàn)略要求銀行IT從傳統(tǒng)封閉式架構(gòu)向開(kāi)源、開(kāi)放、自主可控的架構(gòu)轉(zhuǎn)型；其次，高并發(fā)交易的出現(xiàn)要求銀行IT架構(gòu)支持縱向擴(kuò)展；最后，銀行經(jīng)營(yíng)環(huán)境的變化要求銀行IT基礎(chǔ)設(shè)施從昂貴的IOE設(shè)施向x86服務(wù)器、本地磁盤等低成本設(shè)施轉(zhuǎn)型。

2.3.1　GoldenDB數(shù)據(jù)庫(kù)的研發(fā)和運(yùn)用歷程

GoldenDB作為一款金融級(jí)分布式數(shù)據(jù)庫(kù)，要求支撐總行核心系統(tǒng)和信用卡核心系統(tǒng)等大型交易系統(tǒng)，實(shí)現(xiàn)中信銀行IT架構(gòu)從傳統(tǒng)架構(gòu)向分布式架構(gòu)的轉(zhuǎn)型。那么，金融級(jí)分布式數(shù)據(jù)庫(kù)應(yīng)滿足哪些數(shù)據(jù)庫(kù)技術(shù)要求？

第一，數(shù)據(jù)實(shí)時(shí)一致，具有完整的事務(wù)管理功能，交易一旦完成，交易內(nèi)所有操作的結(jié)果都要求反映在數(shù)據(jù)庫(kù)中。

第二，線性擴(kuò)展，性能不夠加機(jī)器、容量不夠加機(jī)器，加機(jī)器不能停業(yè)務(wù)。

第三，高可用，軟件宕機(jī)不丟數(shù)，硬件故障可恢復(fù)，包括單點(diǎn)故障容錯(cuò)、機(jī)房故障容錯(cuò)甚至是城市災(zāi)難恢復(fù)。

第四，數(shù)據(jù)安全可靠，安全、完備的用戶鑒權(quán)、權(quán)限控制、防SQL注入能力。

第五，開(kāi)發(fā)和運(yùn)維簡(jiǎn)單，像使用單機(jī)數(shù)據(jù)庫(kù)一樣，應(yīng)用程序無(wú)須額外考慮分布式事務(wù)補(bǔ)償、數(shù)據(jù)分庫(kù)分表處理，要求具備完善的開(kāi)發(fā)工具和監(jiān)控體系支撐。

除了從技術(shù)層面滿足以上要求外，更重要的是以中信銀行實(shí)際業(yè)務(wù)（特別是核心系統(tǒng)）的使用場(chǎng)景為依據(jù)，自2014年以來(lái)，中信銀行和中興通訊開(kāi)始聯(lián)合研發(fā)GoldenDB分布式數(shù)據(jù)庫(kù)。

在研發(fā)的過(guò)程中，技術(shù)團(tuán)隊(duì)砥礪前行，產(chǎn)品的功能逐漸增強(qiáng)，性能逐漸穩(wěn)定，并陸續(xù)在中信銀行冠字號(hào)系統(tǒng)、門戶網(wǎng)站系統(tǒng)、金融同業(yè)合作平臺(tái)等系統(tǒng)得到成功運(yùn)用。特別是信用卡核心下移并于2019年10月26日上線投產(chǎn)，總行核心業(yè)務(wù)系統(tǒng)于2020年5月3日上線投產(chǎn)。核心系統(tǒng)上線后經(jīng)歷了網(wǎng)聯(lián)的雙11測(cè)試，數(shù)據(jù)庫(kù)系統(tǒng)表現(xiàn)平穩(wěn)，性能比原有架構(gòu)有顯著提升。具體的研發(fā)和使用歷程如下。

2013年，中信銀行在布局的數(shù)據(jù)銀行戰(zhàn)略規(guī)劃中，首次提出了由傳統(tǒng)架構(gòu)向云計(jì)算分布式架構(gòu)轉(zhuǎn)型的目標(biāo)。

2014年5月，正式啟動(dòng)了GoldenDB金融級(jí)分布式數(shù)據(jù)庫(kù)的研發(fā)項(xiàng)目，以開(kāi)發(fā)一個(gè)具有強(qiáng)一致性、線性擴(kuò)展和高可用性，可以更好地滿足業(yè)務(wù)發(fā)展需要的金融級(jí)分布式數(shù)據(jù)庫(kù)。

2015年7月，GoldenDB分布式數(shù)據(jù)庫(kù)1.0版本正式發(fā)布。

2015年9月，中信銀行冠字號(hào)系統(tǒng)上線。

2016年5月，中信銀行門戶網(wǎng)站系統(tǒng)上線。

2016年11月，中信銀行金融同業(yè)合作平臺(tái)上線。

2017年6月，中信銀行零售客戶統(tǒng)一積分系統(tǒng)上線。

2019年9月，中信銀行電子渠道（對(duì)私）業(yè)務(wù)處理平臺(tái)上線。

2019年10月，中信銀行信用卡核心系統(tǒng)上線。

2020年5月，中信銀行核心銀行系統(tǒng)上線。

2.3.2　GoldenDB數(shù)據(jù)庫(kù)邏輯架構(gòu)

GoldenDB分布式數(shù)據(jù)庫(kù)采用了層次化和組件化設(shè)計(jì)，實(shí)現(xiàn)了計(jì)算節(jié)點(diǎn)與數(shù)據(jù)存儲(chǔ)分離，交易數(shù)據(jù)流與批量數(shù)據(jù)流分離，如圖2-16所示。

如圖2-16所示，整個(gè)GoldenDB分布式數(shù)據(jù)庫(kù)共分為五個(gè)部分：數(shù)據(jù)庫(kù)客戶端、前置中間件、數(shù)據(jù)節(jié)點(diǎn)集群、后置中間件和管理控制臺(tái)。

1．?dāng)?shù)據(jù)庫(kù)客戶端

數(shù)據(jù)庫(kù)客戶端提供了標(biāo)準(zhǔn)JDBC驅(qū)動(dòng)實(shí)現(xiàn)，通過(guò)驅(qū)動(dòng)訪問(wèn)DBProxy，發(fā)起SQL請(qǐng)求。

2．前置中間件

包括DBProxy、全局事務(wù)管理器GTM和Manager管理組件。DBProxy是數(shù)據(jù)庫(kù)的訪問(wèn)入口，負(fù)責(zé)SQL解析、執(zhí)行計(jì)劃優(yōu)化、SQL執(zhí)行和SQL路由分發(fā)；GTM負(fù)責(zé)分布式事務(wù)管理；Manager管理組件負(fù)責(zé)集群管理、DBProxy管理和元數(shù)據(jù)管理。

3．?dāng)?shù)據(jù)節(jié)點(diǎn)集群

集群由數(shù)據(jù)節(jié)點(diǎn)和負(fù)責(zé)數(shù)據(jù)節(jié)點(diǎn)管理的DBAgent構(gòu)成，每個(gè)數(shù)據(jù)節(jié)點(diǎn)采用基于MySQL進(jìn)行開(kāi)發(fā)的存儲(chǔ)引擎，每個(gè)DBAgent負(fù)責(zé)數(shù)據(jù)節(jié)點(diǎn)的管理，例如，數(shù)據(jù)節(jié)點(diǎn)故障切換等。

4．后置中間件

負(fù)責(zé)批量數(shù)據(jù)的導(dǎo)入導(dǎo)出、數(shù)據(jù)重分布，實(shí)現(xiàn)交易數(shù)據(jù)流與批量數(shù)據(jù)流分離。

5．管理控制臺(tái)

提供分布式數(shù)據(jù)庫(kù)安裝部署、配置管理、任務(wù)管理、告警管理和性能監(jiān)控等功能。

2.3.3　GoldenDB數(shù)據(jù)庫(kù)部署架構(gòu)

商業(yè)銀行重要系統(tǒng)通常采用兩地三中心部署，包括生產(chǎn)中心、同城災(zāi)備中心和異地災(zāi)備中心。其中，生產(chǎn)中心和同城災(zāi)備中心位于一個(gè)城市，異地災(zāi)備中心位于另外一個(gè)城市。GoldenDB數(shù)據(jù)庫(kù)支持跨中心部署，所有硬件和軟件都采用冗余部署，可以避免單點(diǎn)故障。

如圖2-17所示，來(lái)自外圍系統(tǒng)的服務(wù)請(qǐng)求按照負(fù)載均衡策略被分發(fā)給生產(chǎn)中心和同城災(zāi)備中心部署的應(yīng)用；應(yīng)用包括聯(lián)機(jī)交易應(yīng)用和批處理應(yīng)用集群，采用同城雙活部署，滿足異地災(zāi)備5級(jí)標(biāo)準(zhǔn)。

聯(lián)機(jī)交易應(yīng)用和批處理應(yīng)用集群訪問(wèn)DBProxy集群，DBProxy無(wú)狀態(tài)，容易水平擴(kuò)展；DBProxy集群訪問(wèn)數(shù)據(jù)庫(kù)集群，數(shù)據(jù)庫(kù)集群包括多個(gè)分片，每個(gè)分片包括一個(gè)主庫(kù)和若干個(gè)跨中心從庫(kù)，主庫(kù)和同城從庫(kù)之間采用快同步（見(jiàn)2.3.4節(jié)對(duì)快同步的解釋）復(fù)制，主庫(kù)和異地從庫(kù)之間采用異步復(fù)制。

在分布式環(huán)境下，數(shù)據(jù)庫(kù)集群中的數(shù)據(jù)通過(guò)分片規(guī)則，被打散并存放在多個(gè)數(shù)據(jù)節(jié)點(diǎn)上，不但要保證單一數(shù)據(jù)節(jié)點(diǎn)數(shù)據(jù)一致性，而且要保證所有數(shù)據(jù)節(jié)點(diǎn)數(shù)據(jù)的一致性。GoldenDB為此設(shè)計(jì)出集群（Cluster）、安全組（Group）、工作組（Team）、響應(yīng)數(shù)（Response Number）和高低水位（HLWM）的概念。

在分布式數(shù)據(jù)庫(kù)系統(tǒng)中，最大的邏輯單位被稱為集群，一個(gè)分布式數(shù)據(jù)庫(kù)系統(tǒng)可以同時(shí)存在多個(gè)集群。每個(gè)集群由多個(gè)安全組構(gòu)成，每個(gè)安全組又被稱為分片。每個(gè)安全組由最多三個(gè)工作組構(gòu)成，每個(gè)工作組由實(shí)際的數(shù)據(jù)節(jié)點(diǎn)組成。為保證每個(gè)安全組數(shù)據(jù)一致性，安全組內(nèi)使用快同步或者異步復(fù)制組建主備復(fù)制關(guān)系，一個(gè)安全組內(nèi)只允許存在一個(gè)主節(jié)點(diǎn)，其余數(shù)據(jù)節(jié)點(diǎn)均為從節(jié)點(diǎn)。通常，主節(jié)點(diǎn)所在工作組被稱為本地工作組，負(fù)責(zé)對(duì)外提供服務(wù)。其余從節(jié)點(diǎn)所在的工作組被稱為同城工作組或異地工作組，負(fù)責(zé)同步主節(jié)點(diǎn)數(shù)據(jù)、主備切換。

如圖2-17所示，一個(gè)大的數(shù)據(jù)庫(kù)集群跨越生產(chǎn)中心、同城災(zāi)備中心和異地災(zāi)備中心，共有40個(gè)安全組（即40個(gè)分片），在每個(gè)安全組內(nèi)共計(jì)有3個(gè)工作組，即每個(gè)中心各有一個(gè)。每個(gè)分片內(nèi)部只有一個(gè)主節(jié)點(diǎn)，生產(chǎn)中心有一個(gè)從節(jié)點(diǎn)，同城災(zāi)備中心有其余兩個(gè)從節(jié)點(diǎn)，異地災(zāi)備中心有其余兩個(gè)從節(jié)點(diǎn)，即“一主五從”結(jié)構(gòu)。

主從節(jié)點(diǎn)數(shù)據(jù)同步時(shí)，從節(jié)點(diǎn)未完成數(shù)據(jù)同步之前，主節(jié)點(diǎn)事務(wù)無(wú)法完成提交操作，這就可以強(qiáng)迫從節(jié)點(diǎn)與主節(jié)點(diǎn)數(shù)據(jù)保持一致。但從節(jié)點(diǎn)數(shù)量越多主機(jī)事務(wù)提交就越慢，因此，可以通過(guò)高低水位與響應(yīng)數(shù)的設(shè)置來(lái)進(jìn)行控制，既能保證從節(jié)點(diǎn)數(shù)據(jù)一致性，又能避免提交過(guò)慢的問(wèn)題。

響應(yīng)數(shù)功能作用于工作組內(nèi)，即使工作組中存在多個(gè)數(shù)據(jù)節(jié)點(diǎn)，通過(guò)設(shè)置響應(yīng)數(shù)，可以控制工作組內(nèi)滿足數(shù)據(jù)一致性要求的數(shù)據(jù)節(jié)點(diǎn)數(shù)量，從而避免由于從節(jié)點(diǎn)過(guò)多，導(dǎo)致主節(jié)點(diǎn)事務(wù)提交變慢的問(wèn)題。例如，工作組內(nèi)有兩個(gè)從節(jié)點(diǎn)，如果響應(yīng)數(shù)設(shè)置為2，表示兩個(gè)從庫(kù)都要和主庫(kù)保持一致性；如果響應(yīng)數(shù)設(shè)置為1，表示只要其中一個(gè)從庫(kù)和主庫(kù)保持一致性即可。

高低水位分為高水位與低水位兩個(gè)指標(biāo)，其功能作用于工作組上。按照本地、同城兩個(gè)工作組說(shuō)明，高水位要求兩個(gè)工作組同時(shí)滿足數(shù)據(jù)一致性要求，否則會(huì)觸發(fā)告警。低水位要求兩個(gè)工作組起碼一個(gè)滿足數(shù)據(jù)一致性要求，否則整個(gè)安全組數(shù)據(jù)只讀。

在上述部署架構(gòu)的保證下，GoldenDB能夠在高吞吐效率的情況下，達(dá)到同城災(zāi)備RPO=0、RTO<5 min；異地災(zāi)備RPO<2 min，RTO<10 min，并且支持異地孤島演練。

2.3.4　GoldenDB數(shù)據(jù)庫(kù)關(guān)鍵創(chuàng)新技術(shù)

在GoldenDB數(shù)據(jù)庫(kù)研發(fā)中，每一項(xiàng)技術(shù)的開(kāi)發(fā)都慎之又慎。開(kāi)發(fā)團(tuán)隊(duì)從國(guó)內(nèi)外分布式數(shù)據(jù)庫(kù)技術(shù)調(diào)研開(kāi)始，優(yōu)先開(kāi)發(fā)既能代表發(fā)展潮流又能解決實(shí)際問(wèn)題的技術(shù)，接下來(lái)進(jìn)行原型開(kāi)發(fā)，并對(duì)原型進(jìn)行大量的功能和性能的測(cè)試驗(yàn)證，完成所有驗(yàn)證后才會(huì)在GoldenDB數(shù)據(jù)庫(kù)中進(jìn)行產(chǎn)品化實(shí)現(xiàn)。

在GoldenDB數(shù)據(jù)庫(kù)中，做了很多有利于應(yīng)用的微創(chuàng)新，例如，在MySQL原生隔離級(jí)的基礎(chǔ)上，又進(jìn)行了擴(kuò)展，增加了非一致性讀（UR）、一致性讀（CR）與非一致性寫（SW）、一致性寫（CW）四種分布式隔離級(jí)，具體詳見(jiàn)2.3.5節(jié)中對(duì)分布式隔離級(jí)的講解；增加了來(lái)自DBProxy的SQL查詢語(yǔ)句的執(zhí)行計(jì)劃查看功能，即擴(kuò)展了Explain命令；支持多級(jí)分片，對(duì)一個(gè)表按照不同規(guī)則分片，降低應(yīng)用遷移難度；為應(yīng)用提供全局唯一的序列值，用于全局唯一的流水號(hào)、日志號(hào)等。

除了上述微創(chuàng)新外，還有三大最關(guān)鍵的創(chuàng)新技術(shù)。這些技術(shù)包括實(shí)時(shí)一致的分布式事務(wù)控制、主從快同步復(fù)制支持、在線數(shù)據(jù)重分布等，下面具體論述。

1．實(shí)時(shí)一致的分布式事務(wù)控制

事務(wù)一致性指的是事務(wù)的執(zhí)行不能破壞數(shù)據(jù)庫(kù)數(shù)據(jù)的完整性和一致性，一個(gè)事務(wù)在執(zhí)行之前和執(zhí)行之后，數(shù)據(jù)庫(kù)都必須處于一致性狀態(tài)。

為保證分布式事務(wù)一致性，業(yè)界主要有兩種方案：兩階段提交（2PC）方案與最終一致性（Eventual Consistency）方案。由于兩階段提交存在同步阻塞、一致性讀隔離級(jí)別下臟讀問(wèn)題，無(wú)法滿足隔離性，已證明在某些場(chǎng)景下無(wú)法使用；最終一致性方案又分為提供補(bǔ)償事務(wù)方案和基于消息隊(duì)列異步處理方案兩種，但都只能保證最終一致性，不能保證實(shí)時(shí)一致性。下面具體講述兩種方案。

提供補(bǔ)償事務(wù)方案要求業(yè)務(wù)為每一筆失敗事務(wù)添加補(bǔ)償操作，使得業(yè)務(wù)代碼量增大，加之補(bǔ)償事務(wù)本身也需要額外異常處理，導(dǎo)致處理邏輯變得復(fù)雜。并且，事務(wù)處理步驟變多，失敗后全部回滾的成本也會(huì)增高。

基于消息隊(duì)列異步處理方案要求將事務(wù)拆成多個(gè)本地子事務(wù)，子事務(wù)之間通過(guò)消息隊(duì)列銜接，保證子事務(wù)串行執(zhí)行。單個(gè)子事務(wù)占用資源時(shí)間短，可提供高并發(fā)讀。但為保證事務(wù)最終一致性，應(yīng)用需做大量異常處理工作以確保事務(wù)原子性。

按照銀行業(yè)務(wù)對(duì)實(shí)時(shí)一致性的要求，充分分析各種事務(wù)一致性方案的優(yōu)缺點(diǎn)后，GoldenDB數(shù)據(jù)庫(kù)采用了基于全局事務(wù)ID（Global Transaction ID，GTID）的分布式事務(wù)一致性方案，在保證系統(tǒng)性能的同時(shí)實(shí)現(xiàn)數(shù)據(jù)讀寫操作的實(shí)時(shí)一致性，詳見(jiàn)2.3.5節(jié)具體介紹。這也是GoldenDB數(shù)據(jù)庫(kù)最為關(guān)鍵的技術(shù)創(chuàng)新。

2．GoldenDB快同步復(fù)制

MySQL原生的異步復(fù)制存在缺陷：無(wú)法保證主備數(shù)據(jù)的一致性，主機(jī)不需要等備機(jī)的響應(yīng)，所以在主備切換的時(shí)候無(wú)法保證備機(jī)的數(shù)據(jù)和主機(jī)完全一致。

MySQL在異步復(fù)制的基礎(chǔ)上提供了一個(gè)半同步插件，要求必須收到一個(gè)備機(jī)的應(yīng)答響應(yīng)才讓事務(wù)在主機(jī)上提交，當(dāng)備機(jī)應(yīng)答超時(shí)的情況下，半同步會(huì)自動(dòng)退化成異步模式。該方案在主機(jī)本身無(wú)故障的情況下，能保證不丟失事務(wù)，一旦退化成異步復(fù)制就回到上面的問(wèn)題上去了。同時(shí)，半同步復(fù)制采用的是阻塞方式調(diào)用，存在以下兩個(gè)方面的不足。

（1）在跨網(wǎng)絡(luò)的環(huán)境下，由于網(wǎng)絡(luò)延遲較大，導(dǎo)致性能非常低。

（2）線程內(nèi)部調(diào)用都是同步調(diào)用，在等待備機(jī)響應(yīng)期間線程只能等待，性能較低。

在保障主備數(shù)據(jù)一致性的基礎(chǔ)上為了提升跨網(wǎng)絡(luò)的性能，提出了快同步方案：主要針對(duì)半同步進(jìn)行優(yōu)化處理，增加了線程池處理邏輯，重點(diǎn)優(yōu)化了半同步等待備機(jī)響應(yīng)處理流程和事務(wù)提交機(jī)制，新增了組管理機(jī)制和高低水位閾值機(jī)制。

快同步方案的主要優(yōu)化點(diǎn)如下。

（1）半同步復(fù)制使用的是一個(gè)連接一個(gè)線程模型，快同步使用的是連接池模型。

（2）半同步復(fù)制在等待備機(jī)響應(yīng)時(shí)使用線程同步等待，快同步優(yōu)化成線程不等待，收到響應(yīng)后由線程池中的commit線程提交。

（3）半同步復(fù)制僅可以配置等待多個(gè)備機(jī)，無(wú)法按需分組，快同步可將備機(jī)按需分組進(jìn)行管理。

半同步復(fù)制超時(shí)后退化為異步處理，快同步超時(shí)不會(huì)退化為異步，而是通過(guò)高低水位設(shè)置產(chǎn)生錯(cuò)誤碼告警。

3．在線數(shù)據(jù)重分布

如圖2-18所示，當(dāng)執(zhí)行在線重分布操作時(shí)，對(duì)當(dāng)前節(jié)點(diǎn)存量數(shù)據(jù)遷移和增量數(shù)據(jù)追平都無(wú)須停服務(wù)，僅在最后鎖表切換時(shí)短暫暫停服務(wù)，可控制在1 min以內(nèi)。具體步驟如下。

（1）按擴(kuò)容后的分發(fā)策略創(chuàng)建新表。

（2）導(dǎo)出存量數(shù)據(jù)并導(dǎo)入到新表。

（3）將數(shù)據(jù)遷移期間產(chǎn)生的增量數(shù)據(jù)更新到新表。

（4）鎖當(dāng)前表并追平增量數(shù)據(jù)。

（5）切換表名，啟用新分發(fā)策略。

（6）刪除舊表。

2.3.5　GoldenDB數(shù)據(jù)庫(kù)事務(wù)的ACID特性

在數(shù)據(jù)庫(kù)系統(tǒng)中，一個(gè)數(shù)據(jù)庫(kù)事務(wù)是指由一系列數(shù)據(jù)庫(kù)操作組成的一個(gè)完整的邏輯過(guò)程。例如，銀行轉(zhuǎn)賬，從原賬戶扣除金額，以及向目標(biāo)賬戶添加金額，這構(gòu)成一個(gè)完整的邏輯過(guò)程，不可拆分。這個(gè)過(guò)程被稱為一個(gè)事務(wù)，具有ACID特性，事務(wù)的ACID特性在ISO/IEC標(biāo)準(zhǔn)中有詳細(xì)說(shuō)明。

事務(wù)的ACID特性，是指數(shù)據(jù)庫(kù)管理系統(tǒng)在寫入或更新數(shù)據(jù)的過(guò)程中，為保證事務(wù)是正確可靠的，所必須具備的四個(gè)特性：原子性（Atomicity，又稱不可分割性）、一致性（Consistency）、隔離性（Isolation，又稱獨(dú)立性）和持久性（Durability）。

GoldenDB數(shù)據(jù)庫(kù)從事務(wù)研發(fā)設(shè)計(jì)上，根據(jù)規(guī)范要求全部實(shí)現(xiàn)了ACID屬性，下面展開(kāi)講述。

1．事務(wù)原子性

事務(wù)原子性指的是一個(gè)事務(wù)要么全部提交成功，要么全部失敗回滾，不能只執(zhí)行其中的一部分操作。單機(jī)環(huán)境通過(guò)回滾滿足全部失敗的要求，但在分布式環(huán)境下，事務(wù)牽扯多個(gè)數(shù)據(jù)節(jié)點(diǎn)，全部失敗的要求被擴(kuò)大化。對(duì)于部分提交成功、部分失敗的情況，GoldenDB設(shè)計(jì)實(shí)現(xiàn)了已提交事務(wù)回滾功能，來(lái)滿足此要求。

設(shè)計(jì)原理是在數(shù)據(jù)節(jié)點(diǎn)上部署一個(gè)用于回滾的模塊。當(dāng)出現(xiàn)部分提交成功、部分失敗的情況時(shí)，回滾命令會(huì)發(fā)送到提交成功的節(jié)點(diǎn)，回滾模塊根據(jù)命令來(lái)完成回滾操作，如圖2-19所示。

2．事務(wù)一致性

按照銀行業(yè)務(wù)對(duì)實(shí)時(shí)一致性的要求，充分分析各種事務(wù)一致性方案的優(yōu)缺點(diǎn)后，GoldenDB采用了基于全局事務(wù)ID（Global Transaction ID，GTID）的分布式事務(wù)一致性方案。該方案把協(xié)調(diào)者（Coordinator）和全局事務(wù)管理（Global Transaction Manager，GTM）兩個(gè)功能分開(kāi)。GTM僅管理全局事務(wù)狀態(tài)，由計(jì)算節(jié)點(diǎn)（DBProxy）充當(dāng)協(xié)調(diào)者。并且，GTM支持本地持久化與備機(jī)同步，確保全局事務(wù)狀態(tài)信息不丟失，如圖2-20所示。

GTID方案的核心思想，是在全局事務(wù)提交過(guò)程中，發(fā)生部分節(jié)點(diǎn)提交失敗時(shí)，回滾已提交節(jié)點(diǎn)數(shù)據(jù)，而不進(jìn)行提交失敗重試，保證數(shù)據(jù)最終一致性，同時(shí)解決同步阻塞問(wèn)題。

GTID是由GTM創(chuàng)建的一個(gè)具有全局唯一屬性的值。為保存該值，創(chuàng)建數(shù)據(jù)表時(shí)GoldenDB會(huì)自動(dòng)添加一列。因此，GTID屬于關(guān)鍵字，不允許顯式創(chuàng)建名為GTID的字段。

GTM通過(guò)狀態(tài)機(jī)維護(hù)每個(gè)GTID的變化。GTM為每個(gè)新事務(wù)創(chuàng)建一個(gè)GTID，此時(shí)狀態(tài)為CREATED。在事務(wù)執(zhí)行過(guò)程中，GTID伴隨數(shù)據(jù)一起寫入數(shù)據(jù)節(jié)點(diǎn)，此時(shí)狀態(tài)為ACTIVE。事務(wù)發(fā)起提交，若提交成功，狀態(tài)變?yōu)镽ELEASING；若提交失敗，狀態(tài)保持ACTIVE不變。提交成功后，事務(wù)正常結(jié)束，狀態(tài)變?yōu)镽ELEASED。提交失敗后，觸發(fā)已提交事務(wù)回滾機(jī)制。若回滾成功，狀態(tài)變?yōu)镽ELEASING，若回滾失敗，狀態(tài)保持ACTIVE不變。回滾完成后，狀態(tài)變?yōu)镽ELEASED。對(duì)于回滾失敗且狀態(tài)為ACTIVE的GTID，則需要手動(dòng)處理。狀態(tài)切換如圖2-21所示。

3．事務(wù)的隔離性

事務(wù)的隔離性指的是數(shù)據(jù)庫(kù)必須保證一個(gè)事務(wù)在執(zhí)行中不受其他并發(fā)事務(wù)影響。即一個(gè)事務(wù)對(duì)其他事務(wù)是隔離的，并發(fā)執(zhí)行時(shí)各事務(wù)間不能互相干擾。單機(jī)環(huán)境通過(guò)設(shè)置隔離級(jí)別，控制事務(wù)之間的影響程度。同樣地，針對(duì)分布式事務(wù)，GoldenDB提供了四種讀寫隔離級(jí)別，分別為：非一致性讀（UR）、一致性讀（CR）與非一致性寫（SW）、一致性寫（CW）。下面主要介紹分布式環(huán)境下，讀寫操作之間的影響與寫寫操作之間的影響。

分布式下的讀寫操作，在UR隔離級(jí)別下，讀事務(wù)不會(huì)判斷寫事務(wù)產(chǎn)生的中間結(jié)果，直接返回滿足條件的記錄，存在臟讀問(wèn)題。CR隔離級(jí)別下，讀事務(wù)會(huì)判斷數(shù)據(jù)的狀態(tài)。即寫事務(wù)在提交過(guò)程中，數(shù)據(jù)處于ACTIVE狀態(tài)，讀事務(wù)不直接返回記錄，而是按照配置進(jìn)行重試操作，直到寫事務(wù)提交成功或失敗。因此，不會(huì)出現(xiàn)臟讀問(wèn)題。

分布式下的寫寫操作，在SW隔離級(jí)別下，寫事務(wù)不再受到全局事務(wù)控制，寫事務(wù)之間影響與單機(jī)環(huán)境類似。區(qū)別在于，已提交事務(wù)回滾無(wú)法保證數(shù)據(jù)一致性。即待回滾數(shù)據(jù)會(huì)被其他寫事務(wù)修改，回滾后會(huì)丟失數(shù)據(jù)，存在非一致性寫問(wèn)題。CW隔離級(jí)別下，寫事務(wù)受到全局事務(wù)控制，其他寫事務(wù)會(huì)判斷數(shù)據(jù)活躍狀態(tài)。若數(shù)據(jù)活躍，則該事務(wù)無(wú)法進(jìn)行寫操作。因此，可以保證數(shù)據(jù)一致性。

4．事務(wù)持久性

事務(wù)持久性指的是事務(wù)提交后，對(duì)數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會(huì)丟失。與單機(jī)事務(wù)一樣，分布式事務(wù)也需要保證事務(wù)持久性。不同的是，分布式事務(wù)不但需要持久化業(yè)務(wù)數(shù)據(jù)，而且還需要持久化全局事務(wù)狀態(tài)。數(shù)據(jù)持久化由數(shù)據(jù)節(jié)點(diǎn)保證，全局事務(wù)狀態(tài)持久化由GTM保證。

GTM采用實(shí)時(shí)增量與定時(shí)全量方式對(duì)全局事務(wù)狀態(tài)進(jìn)行持久化。對(duì)于短事務(wù)，由于GTID被不斷地創(chuàng)建與釋放，GTM會(huì)實(shí)時(shí)地使用增量方式進(jìn)行持久化；對(duì)于長(zhǎng)事務(wù)，GTM需要長(zhǎng)時(shí)間保存GTID，因此，每隔一定時(shí)間使用全量方式進(jìn)行持久化。