一文看懂金融級(jí)分布式數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)

原創(chuàng)
作者：張小海 2020-01-03 09:00:00

運(yùn)維

數(shù)據(jù)庫(kù)運(yùn)維

分布式 銀行業(yè)從最初的手工記賬到會(huì)計(jì)電算化，到金融電子化，再到現(xiàn)在的金融科技，可以看到金融與科技的結(jié)合越來(lái)越緊密，人工智能、大數(shù)據(jù)、物聯(lián)網(wǎng)、區(qū)塊鏈等新興技術(shù)改變了金融的交易方式，為金融行業(yè)的創(chuàng)新前行提供了源源不斷的動(dòng)力。同時(shí)互聯(lián)網(wǎng)金融的興起是一把雙刃劍，帶來(lái)了機(jī)遇的同時(shí)也帶來(lái)了挑戰(zhàn)。

為阿魯科爾沁等地區(qū)用戶(hù)提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及阿魯科爾沁網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都做網(wǎng)站、成都網(wǎng)站建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、阿魯科爾沁網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專(zhuān)業(yè)、用心的態(tài)度為用戶(hù)提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶(hù)的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

【51CTO.com原創(chuàng)稿件】行業(yè)背景

銀行業(yè)從最初的手工記賬到會(huì)計(jì)電算化，到金融電子化，再到現(xiàn)在的金融科技，可以看到金融與科技的結(jié)合越來(lái)越緊密，人工智能、大數(shù)據(jù)、物聯(lián)網(wǎng)、區(qū)塊鏈等新興技術(shù)改變了金融的交易方式，為金融行業(yè)的創(chuàng)新前行提供了源源不斷的動(dòng)力。同時(shí)互聯(lián)網(wǎng)金融的興起是一把雙刃劍，帶來(lái)了機(jī)遇的同時(shí)也帶來(lái)了挑戰(zhàn)。

普惠金融使得金融的門(mén)檻降低，更多的普通大眾參與到金融活動(dòng)中，這讓金融信息系統(tǒng)承受了越來(lái)越大的壓力。于是我們可以看到大型商業(yè)銀行、保險(xiǎn)公司、證券公司、交易所等核心交易系統(tǒng)都在紛紛進(jìn)行分布式改造，其中數(shù)據(jù)庫(kù)作為有狀態(tài)的應(yīng)用，成為了信息系統(tǒng)中唯一的單點(diǎn)，承擔(dān)了所有來(lái)自上層應(yīng)用的壓力。隨著數(shù)據(jù)庫(kù)瓶頸的凸顯，進(jìn)行分布式改造迫在眉睫。

數(shù)據(jù)庫(kù)分布式改造的途徑

數(shù)據(jù)庫(kù)進(jìn)行分布式改造主要有三種途徑：分布式訪問(wèn)客戶(hù)端、分布式訪問(wèn)中間件、分布式數(shù)據(jù)庫(kù)。由于其分布式能力實(shí)現(xiàn)在不同的層次(應(yīng)用層、中間層、數(shù)據(jù)庫(kù)層)，對(duì)應(yīng)用程序有不同的侵入程度，其中分布式訪問(wèn)客戶(hù)端對(duì)應(yīng)用侵入性最大，改造難度最大，而分布式數(shù)據(jù)庫(kù)方案對(duì)應(yīng)用侵入性最小，但是架構(gòu)設(shè)計(jì)及研發(fā)難度最大。

分布式數(shù)據(jù)庫(kù)總體架構(gòu)

其實(shí)當(dāng)前市面上的分布式數(shù)據(jù)庫(kù)總體架構(gòu)都是類(lèi)似的，由必不可少的三個(gè)組件組成：接入節(jié)點(diǎn)、數(shù)據(jù)節(jié)點(diǎn)、全局事務(wù)管理器。總體架構(gòu)如下，接入節(jié)點(diǎn)負(fù)責(zé)sql解析，生成分布式執(zhí)行計(jì)劃，sql轉(zhuǎn)發(fā)，數(shù)據(jù)匯總等;數(shù)據(jù)節(jié)點(diǎn)負(fù)責(zé)數(shù)據(jù)存儲(chǔ)與運(yùn)算;全局事務(wù)管理器負(fù)責(zé)全局事務(wù)號(hào)的生成，保證事務(wù)的全局一致性。這個(gè)架構(gòu)或多或少都受到了Google Spanner F1論文的影響，這篇文章主要分析了這幾個(gè)組件在實(shí)現(xiàn)上有什么難點(diǎn)，該如何進(jìn)行架構(gòu)設(shè)計(jì)。

兩階段提交的問(wèn)題

我們知道兩階段提交是阻塞性協(xié)議，這也是它最大的問(wèn)題。下圖以pgxc架構(gòu)下的兩階段提交為例，主要分為幾個(gè)階段：

①：CN prepare ->②：所有DN prepare ->③：CN commit->④：所有DN commit

試想一下如果在cn commit階段發(fā)生cn/dn宕機(jī)會(huì)發(fā)生什么?

如果在cn下發(fā)完cn commit命令后宕機(jī)，這時(shí)dn收到commit命令后會(huì)進(jìn)行提交，但是返回commit ok時(shí)發(fā)生cn宕機(jī)，事務(wù)進(jìn)入阻塞狀態(tài)。如果cn下發(fā)commit之后某個(gè)dn發(fā)生宕機(jī)，則會(huì)造成某些dn commit成功，某些dn commit失敗，造成不一致，但是如果dn重新啟動(dòng)后會(huì)繼續(xù)去cn上拿事務(wù)提交信息，發(fā)現(xiàn)是commit狀態(tài)，則會(huì)繼續(xù)執(zhí)行commit操作，提交之前的事務(wù)。

在這個(gè)地方我們可以探討一個(gè)更極端的情況，如果此時(shí)cn也宕機(jī)了，那么失敗的dn重啟后去cn拿狀態(tài)發(fā)現(xiàn)拿不到，這時(shí)這個(gè)失敗dn上的事務(wù)就處于一個(gè)未決態(tài)，不知道是應(yīng)該提交還是回滾，這時(shí)候應(yīng)該有一個(gè)進(jìn)程能夠從其他dn上發(fā)現(xiàn)該狀態(tài)并報(bào)告給故障dn，通知它進(jìn)行提交。這個(gè)角色就是pgxc_clean進(jìn)程，其實(shí)之前幾種情況下的事務(wù)的回滾也是該進(jìn)程的工作。那我們?cè)偕钊胍幌?，如果該dn是事務(wù)的唯一參與者，那么此時(shí)pgxc_clean就無(wú)法從其他dn以及cn獲取狀態(tài)，這時(shí)該dn就是真正的未決態(tài)了。

為了解決兩階段提交的阻塞問(wèn)題，出現(xiàn)了三階段提交，三階段提交在commit之前引入了cancommit的過(guò)程，同時(shí)加入超時(shí)機(jī)制。因?yàn)槿绻麉f(xié)調(diào)者發(fā)生宕機(jī)，參與者無(wú)法得知協(xié)調(diào)者到底發(fā)出的是commit還是abort，三階段提交cancommit過(guò)程就是告知參與者我發(fā)送的是commit或者abort命令，這時(shí)如果協(xié)調(diào)者發(fā)生失敗，參與者等待超時(shí)時(shí)間后可以選出新的協(xié)調(diào)者，而該協(xié)調(diào)者是知道應(yīng)該發(fā)出什么命令。

雖然三階段提交解決了阻塞問(wèn)題，但是無(wú)法解決性能問(wèn)題，分布式系統(tǒng)中為了保證事務(wù)一致性需要跟每個(gè)參與者通信，一個(gè)事務(wù)的提交和參與需要分布式系統(tǒng)中每個(gè)節(jié)點(diǎn)的參與，必然帶來(lái)延時(shí)，不過(guò)在萬(wàn)兆、infiniband、roce高速網(wǎng)絡(luò)的支持下已經(jīng)不再是問(wèn)題了。

CAP與BASE的抉擇

我們知道分布式系統(tǒng)無(wú)法戰(zhàn)勝CAP。那么在設(shè)計(jì)分布式系統(tǒng)的時(shí)候該如何進(jìn)行取舍?首先P(分區(qū)容錯(cuò)性)是必須保證的，因?yàn)榉植际较到y(tǒng)必然是多個(gè)節(jié)點(diǎn)(分區(qū))通過(guò)網(wǎng)絡(luò)進(jìn)行互聯(lián)，而網(wǎng)絡(luò)是不可靠的，分布式系統(tǒng)是為了避免單點(diǎn)故障，如果因?yàn)榫W(wǎng)絡(luò)問(wèn)題或者某些節(jié)點(diǎn)失敗造成整體系統(tǒng)不可用，那么也不符合分布式系統(tǒng)的設(shè)計(jì)初衷。如果保證A(可用性)，那么當(dāng)網(wǎng)絡(luò)失敗時(shí)，網(wǎng)絡(luò)隔離的不同區(qū)域就要繼續(xù)提供服務(wù)，那么就會(huì)造成不同分區(qū)的數(shù)據(jù)不一致(腦裂);如果保證C(一致性)，那么網(wǎng)絡(luò)失敗時(shí)，就需要等待不同網(wǎng)絡(luò)分區(qū)的節(jié)點(diǎn)同步完數(shù)據(jù)，如果網(wǎng)絡(luò)一直失敗，那么系統(tǒng)就會(huì)因?yàn)闊o(wú)法同步而一直不可用。

2PC就是典型的犧牲可用性保證一致性的例子，而B(niǎo)ASE(basically available，soft state，eventual consistency)就是犧牲一致性保證可用性的例子，因?yàn)樽龅綄?shí)時(shí)的強(qiáng)一致要犧牲的代價(jià)太大了，它允許數(shù)據(jù)在某些時(shí)間窗口內(nèi)的不一致，通過(guò)記錄窗口內(nèi)的每一個(gè)臨時(shí)狀態(tài)日志做到在系統(tǒng)故障時(shí)，通過(guò)日志繼續(xù)完成未完成的工作或者取消已經(jīng)完成的工作回退到初始狀態(tài)，這種方式保證了最終一致性。BASE與傳統(tǒng)ACID理論其實(shí)是背離的，滿(mǎn)足BASE理論的事務(wù)也叫柔性事務(wù)，在遭遇失敗時(shí)需要有相應(yīng)的補(bǔ)償機(jī)制，與業(yè)務(wù)耦合性較高，其實(shí)我并不是很贊同BASE的做法，因?yàn)樗呀?jīng)背離了數(shù)據(jù)庫(kù)最基本的設(shè)計(jì)理念。

raft的優(yōu)勢(shì)

不管是上面的XA還是BASE都無(wú)法徹底解決一致性問(wèn)題，真正意義上的強(qiáng)一致一定是基于強(qiáng)一致協(xié)議的。paxos和raft是目前主流的兩種共識(shí)算法。Paxos誕生于學(xué)院派，是分布式環(huán)境下基于消息傳遞的共識(shí)算法，它設(shè)計(jì)之初是考慮一個(gè)通用的模型，并沒(méi)有過(guò)多的考慮實(shí)際的應(yīng)用，而且paxos考慮了多個(gè)節(jié)點(diǎn)同時(shí)寫(xiě)入的情況，這就使得paxos的狀態(tài)機(jī)異常復(fù)雜，所以難以理解，不同的人可能理解出不同的意思，這一點(diǎn)一直遭人詬病，比如MGR引入write set的概念來(lái)處理多點(diǎn)寫(xiě)入沖突的問(wèn)題，這在高并發(fā)熱點(diǎn)數(shù)據(jù)的場(chǎng)景下是不可接受的。因?yàn)閜axos的難以理解，斯坦福的兩名大學(xué)生設(shè)計(jì)了raft算法，相比來(lái)說(shuō)，raft是工業(yè)派，同一時(shí)刻leader只有一個(gè)，follower通過(guò)日志復(fù)制實(shí)現(xiàn)一致性，相比paxos來(lái)說(shuō)raft的狀態(tài)機(jī)更加簡(jiǎn)單易懂，實(shí)現(xiàn)起來(lái)也更加簡(jiǎn)單，因此在分布式環(huán)境上有著廣泛的應(yīng)用，例如TiDB、RadonDB、etcd、kubernetes等。

Raft協(xié)議將共識(shí)問(wèn)題分解為三個(gè)子問(wèn)題分別解決：leader選舉、日志復(fù)制、安全性。

Leader選舉：

服務(wù)器節(jié)點(diǎn)有三種狀態(tài)：領(lǐng)導(dǎo)者、跟隨者和候選者。正常情況下，系統(tǒng)中只有一個(gè)領(lǐng)導(dǎo)者，其他的節(jié)點(diǎn)全部都是跟隨者，領(lǐng)導(dǎo)者處理全部客戶(hù)端請(qǐng)求，跟隨者不會(huì)主動(dòng)發(fā)送任何請(qǐng)求，只是簡(jiǎn)單的響應(yīng)來(lái)自領(lǐng)導(dǎo)者或者候選者的請(qǐng)求。如果跟隨者接收不到消息(選舉超時(shí))，那么他就會(huì)變成候選者并發(fā)起一次選舉。獲得集群中大多數(shù)選票的候選者將成為領(lǐng)導(dǎo)者，領(lǐng)導(dǎo)者一直都會(huì)是領(lǐng)導(dǎo)者直到自己宕機(jī)了。

Raft 算法把時(shí)間分割成任意長(zhǎng)度的任期(term)，每一段任期從一次選舉開(kāi)始，一個(gè)或者多個(gè)候選者嘗試成為領(lǐng)導(dǎo)者。如果一個(gè)候選者贏得選舉，然后他就在這個(gè)的任期內(nèi)充當(dāng)領(lǐng)導(dǎo)者。要開(kāi)始一次選舉過(guò)程，跟隨者先要增加自己的當(dāng)前任期號(hào)并且轉(zhuǎn)換到候選者狀態(tài)，然后他會(huì)并行的向集群中的其他服務(wù)器節(jié)點(diǎn)發(fā)送請(qǐng)求投票的 RPCs 來(lái)給自己投票，候選者會(huì)繼續(xù)保持著當(dāng)前狀態(tài)直到以下三件事情之一發(fā)生：(a) 他贏得了這次的選舉，(b) 其他服務(wù)器成為領(lǐng)導(dǎo)者，(c) 沒(méi)有任何一個(gè)候選者贏得選舉。當(dāng)一個(gè)候選者獲得了集群大多數(shù)節(jié)點(diǎn)針對(duì)同一個(gè)任期號(hào)的選票，那么他就贏得了選舉并成為領(lǐng)導(dǎo)者。然后他會(huì)向其他的服務(wù)器發(fā)送心跳消息來(lái)建立自己的權(quán)威并且阻止新的領(lǐng)導(dǎo)人的產(chǎn)生。下圖為三種角色的轉(zhuǎn)換狀態(tài)機(jī)。

日志復(fù)制：

當(dāng)leader被選舉出來(lái)，他就作為服務(wù)器處理客戶(hù)端請(qǐng)求?？蛻?hù)端的每一個(gè)請(qǐng)求都被看成復(fù)制狀態(tài)機(jī)所需要執(zhí)行的指令。領(lǐng)導(dǎo)者把這條指令作為一條新的日志條目附加到日志中去，然后并行的發(fā)起附加條目 RPCs 給其他的服務(wù)器，讓他們復(fù)制這條日志條目。當(dāng)這條日志條目被安全的復(fù)制，領(lǐng)導(dǎo)者會(huì)應(yīng)用這條日志條目到它的狀態(tài)機(jī)中然后把執(zhí)行的結(jié)果返回給客戶(hù)端。如果跟隨者崩潰或者網(wǎng)絡(luò)丟包，領(lǐng)導(dǎo)者會(huì)不斷的重復(fù)嘗試附加日志條目 RPCs (盡管已經(jīng)回復(fù)了客戶(hù)端)直到所有的跟隨者都最終存儲(chǔ)了所有的日志條目。下圖為復(fù)制狀態(tài)機(jī)模型。

安全性：

安全性指的是每臺(tái)復(fù)制狀態(tài)機(jī)都需要按照同樣的順序執(zhí)行相同的指令，以保證每臺(tái)服務(wù)器數(shù)據(jù)的一致性。假想一臺(tái)跟隨者在某段時(shí)間處于不可用狀態(tài)，后來(lái)可能被選為領(lǐng)導(dǎo)者，這時(shí)就會(huì)造成之前的日志被覆蓋。Raft算法通過(guò)在leader選舉時(shí)增加一些限制來(lái)避免這個(gè)問(wèn)題，這一限制保證所有領(lǐng)導(dǎo)者對(duì)于給定的任期號(hào)，都擁有了之前任期的所有被提交的日志條目。日志條目只會(huì)從領(lǐng)導(dǎo)者傳給跟隨者，不會(huì)出現(xiàn)因?yàn)樾骂I(lǐng)導(dǎo)者缺日志而需要跟隨者向領(lǐng)導(dǎo)者傳日志的情況，并且領(lǐng)導(dǎo)者從不會(huì)覆蓋本地日志中已經(jīng)存在的條目。Raft 算法使得在投票時(shí)投票者拒絕掉那些日志沒(méi)有自己新的投票請(qǐng)求，從而阻止該候選者贏得選票。

CN的設(shè)計(jì)

接入節(jié)點(diǎn)的設(shè)計(jì)可能看起來(lái)很簡(jiǎn)單，但是里面有些地方內(nèi)容還是有些玄機(jī)的。設(shè)計(jì)cn需要重點(diǎn)考量的地方主要是cn到底是做重還是做輕。這是把雙刃劍，主要有下面兩方面問(wèn)題。

1.如何做到sql語(yǔ)法兼容性?

接入節(jié)點(diǎn)主要負(fù)責(zé)sql的解析、執(zhí)行計(jì)劃的生成與下發(fā)，這些東西其實(shí)是sql解析器做的事情，我們可以直接將MySQL或者pg的解析器甚至server層拿過(guò)來(lái)做sql解析和執(zhí)行計(jì)劃生成，而且就天然的兼容了MySQL或者pg的語(yǔ)法。

2.如何處理元數(shù)據(jù)的問(wèn)題?

上面的方案看似很完美的事情，但是有個(gè)問(wèn)題：如果直接將MySQL或者pg的server層搬過(guò)來(lái)的話(huà)，元數(shù)據(jù)怎么辦?cn上到底放不放元數(shù)據(jù)?如果不放元數(shù)據(jù)，那么就需要一個(gè)統(tǒng)一的存放和管理元數(shù)據(jù)的地方，我在cn上建的表需要到某個(gè)固定地方更新元數(shù)據(jù)信息，查詢(xún)也是一樣。如果cn上存放元數(shù)據(jù)，那么元數(shù)據(jù)的更新就需要在各個(gè)cn之間進(jìn)行同步，如果發(fā)生某個(gè)cn宕機(jī)，則任何ddl操作都會(huì)hang住，這時(shí)就需要有一個(gè)機(jī)制：在cn超時(shí)無(wú)響應(yīng)后將cn剔除出集群。

DN的設(shè)計(jì)

數(shù)據(jù)節(jié)點(diǎn)的設(shè)計(jì)主要考慮下面幾個(gè)方面問(wèn)題。

1.數(shù)據(jù)節(jié)點(diǎn)如何做高可用?

數(shù)據(jù)庫(kù)的數(shù)據(jù)當(dāng)然是最寶貴的，任何數(shù)據(jù)庫(kù)都要有數(shù)據(jù)冗余方案，數(shù)據(jù)節(jié)點(diǎn)一定要有高可用，在保證rpo=0的基礎(chǔ)上盡量縮短rto。細(xì)想一下，其實(shí)每個(gè)dn都是一個(gè)數(shù)據(jù)庫(kù)實(shí)例，這里以MySQL或者pg為例，MySQL和pg本身是有高可用方案的，不管是基于主從半同步還是流復(fù)制，都可以在dn層面作為數(shù)據(jù)的冗余和切換方案。當(dāng)然還有些數(shù)據(jù)庫(kù)在dn層面引入了paxos、raft、quorum等的強(qiáng)一致方案，這也是在分布式數(shù)據(jù)庫(kù)中很常見(jiàn)的設(shè)計(jì)。

2.如何做到在線(xiàn)擴(kuò)容?

在線(xiàn)擴(kuò)容是分布式數(shù)據(jù)庫(kù)的一項(xiàng)巨大優(yōu)點(diǎn)，而擴(kuò)容數(shù)據(jù)節(jié)點(diǎn)必然涉及到數(shù)據(jù)向新節(jié)點(diǎn)的遷移，目前市面上的分布式數(shù)據(jù)庫(kù)基本上都做到了自動(dòng)的數(shù)據(jù)重分布。但是做到數(shù)據(jù)庫(kù)自動(dòng)重分布還不夠，如何做到只遷移少部分?jǐn)?shù)據(jù)以降低服務(wù)器IO壓力成為關(guān)鍵問(wèn)題。

傳統(tǒng)的散列方式是根據(jù)分區(qū)鍵哈希值對(duì)分區(qū)數(shù)量進(jìn)行取模操作，得到的結(jié)果就是數(shù)據(jù)應(yīng)該落入的分區(qū)，但是這種分布方法在增加刪除節(jié)點(diǎn)時(shí)會(huì)造成大量的數(shù)據(jù)重分布，而一致性哈希的核心思想是每個(gè)分區(qū)不再是對(duì)應(yīng)一個(gè)數(shù)字，而是對(duì)應(yīng)一個(gè)范圍，對(duì)計(jì)算的散列值進(jìn)行范圍的匹配，大體思路是將數(shù)據(jù)節(jié)點(diǎn)和鍵的hash值都映射到0~2^32的圓環(huán)上，然后從映射值的位置開(kāi)始順時(shí)針查找，將數(shù)據(jù)保存到找到的第一個(gè)節(jié)點(diǎn)上。如果超過(guò)2^32仍然找不到服務(wù)節(jié)點(diǎn)，就會(huì)保存到第一個(gè)節(jié)點(diǎn)上。一致性哈希最大程度解決了數(shù)據(jù)重分布問(wèn)題，但是可能會(huì)造成節(jié)點(diǎn)數(shù)據(jù)分布不均勻的問(wèn)題，當(dāng)然針對(duì)這個(gè)問(wèn)題還有一些改進(jìn)，比如增加虛擬節(jié)點(diǎn)。

GTM的設(shè)計(jì)

GTM顧名思義是一個(gè)全局概念，分布式數(shù)據(jù)庫(kù)本來(lái)就是為了可擴(kuò)展、提升性能、降低全局風(fēng)險(xiǎn)，然而GTM這個(gè)東西打破了這一切。

1.為什么需要GTM?

簡(jiǎn)單一句話(huà)總結(jié)就是：GTM是為了保證全局讀一致性，而兩階段提交是為了保證寫(xiě)一致性。這里我們可能有個(gè)誤區(qū)，如果沒(méi)有GTM那么會(huì)不會(huì)造成數(shù)據(jù)不一致?會(huì)，但是只是某個(gè)時(shí)間點(diǎn)讀的不一致，這個(gè)不一致也是暫時(shí)的，但是不會(huì)造成數(shù)據(jù)寫(xiě)的不一致，寫(xiě)的一致性通過(guò)兩階段提交來(lái)保證。

我們知道postgresql通過(guò)快照(snapshot)來(lái)實(shí)現(xiàn)MVCC與事務(wù)可見(jiàn)性判斷。對(duì)于read commit隔離級(jí)別，要求每個(gè)事務(wù)中的查詢(xún)僅能看到在該事務(wù)啟動(dòng)前已經(jīng)提交的更改，以及當(dāng)前事務(wù)中該查詢(xún)之前所做的更改，這都要通過(guò)快照來(lái)實(shí)現(xiàn)?？煺盏臄?shù)據(jù)結(jié)構(gòu)中會(huì)包含事務(wù)的xmin(插入tuple的事務(wù)號(hào))、xmax(更新或者刪除事務(wù)的事務(wù)號(hào))、正在運(yùn)行的事務(wù)列表等相關(guān)信息。pg的每條元組(tuple)頭信息中也會(huì)記錄事務(wù)的xmin和xmax信息。Pg取得snapshot后會(huì)進(jìn)行事務(wù)可見(jiàn)性判斷，對(duì)于所有id小于xmin的tuple對(duì)當(dāng)前快照可見(jiàn)，同時(shí)id大于xmax的tuple對(duì)當(dāng)前事務(wù)可見(jiàn)。當(dāng)前擴(kuò)展到分布式集群后，每臺(tái)機(jī)器上都存在pg的實(shí)例，為了保證全局的讀一致性，需要一個(gè)全局的組件來(lái)負(fù)責(zé)snapshot的分配，使得快照信息在各個(gè)節(jié)點(diǎn)之間共享，這就是GTM的工作。

2.GTM高可用的問(wèn)題?

GTM作為分配全局快照和事務(wù)id的唯一組件，只能有一個(gè)，當(dāng)然GTM可以做主備高可用，但是同一時(shí)刻只能有一個(gè)GTM在工作，gxid信息在主備之間進(jìn)行同步，這樣就造成一個(gè)問(wèn)題，雖然其他節(jié)點(diǎn)都分布式了，但是GTM始終是一個(gè)單點(diǎn)，單點(diǎn)故障時(shí)就會(huì)涉及到切換，切換過(guò)程是影響全局的，而且為了保證切換后gxid信息不丟失，GTM之間必須做到gxid的同步。

針對(duì)高可用這塊問(wèn)題，可以將GTM的事務(wù)號(hào)存儲(chǔ)信息剝離，將事務(wù)號(hào)信息存在第三方存儲(chǔ)中，例如etcd就是個(gè)很好的選擇，etcd是個(gè)強(qiáng)一致高可用的分布式存儲(chǔ)集群，etcd比較輕量，適合用來(lái)存儲(chǔ)事務(wù)號(hào)信息，同時(shí)它自身保證了高可用與強(qiáng)一致，這時(shí)GTM就不需要在主備之間同步gxid，如果發(fā)生主備切換，新主GTM只需要再去從etcd中取得最新事務(wù)號(hào)，寫(xiě)事務(wù)號(hào)也同理，主GTM會(huì)向主etcd節(jié)點(diǎn)寫(xiě)入事務(wù)號(hào)信息，通過(guò)etcd自身的raft復(fù)制協(xié)議保證一致性。這樣的設(shè)計(jì)使得GTM的壓力減輕很多。

3.GTM性能的問(wèn)題?

GTM是大部分分布式數(shù)據(jù)庫(kù)的性能瓶頸，它使得一套集群的整體性能甚至不如一臺(tái)單機(jī)。也很好理解，任何一個(gè)事務(wù)開(kāi)啟都要先通過(guò)cn到GTM取事務(wù)號(hào)和快照信息，然后結(jié)果解析后下發(fā)到dn執(zhí)行，然后cn進(jìn)行匯總再返回給應(yīng)用，路徑很明顯變長(zhǎng)了，那么效率肯定變低，目前優(yōu)勢(shì)在于可以利用多臺(tái)機(jī)器的組合能力進(jìn)行計(jì)算，計(jì)算資源得到了擴(kuò)展。

針對(duì)GTM的瓶頸問(wèn)題當(dāng)然也有解決方案，比如華為GaussDB就提出GTM-Free和GTM-Lite，gtm-free是在那種強(qiáng)一致讀要求不高的場(chǎng)景下關(guān)閉GTM的功能，所有事物都不走GTM，這種情況下性能基本能夠得到線(xiàn)性提升，該功能已經(jīng)實(shí)現(xiàn);gtm-lite是將事務(wù)分類(lèi)，全局事務(wù)就走GTM，本地事務(wù)就直接下發(fā)，因?yàn)榇蠖鄶?shù)情況下都是本地事務(wù)，所有性能提升也很明顯，該功能還在研發(fā)階段。

分布式數(shù)據(jù)庫(kù)如何實(shí)現(xiàn)PITR

數(shù)據(jù)庫(kù)的PITR一般都是通過(guò)一個(gè)基礎(chǔ)備份加上持續(xù)不間斷的wal歸檔來(lái)做到的，這個(gè)基礎(chǔ)備份可以是在線(xiàn)的，因?yàn)樗⒉恍枰獢?shù)據(jù)庫(kù)當(dāng)時(shí)處于一致性狀態(tài)，一致性可以通過(guò)replay redo來(lái)實(shí)現(xiàn)，所以基礎(chǔ)備份可以是文件系統(tǒng)tar命令而不需要文件系統(tǒng)級(jí)別的快照。

PITR是通過(guò)基礎(chǔ)備份加上redo日志能夠恢復(fù)到任意時(shí)間點(diǎn)，這個(gè)任意時(shí)間點(diǎn)不同數(shù)據(jù)庫(kù)有不同定義，可能是某個(gè)lsn，可能是某個(gè)snapshot，可能是某個(gè)timestamp。Postgresql數(shù)據(jù)庫(kù)中能夠基于redo恢復(fù)到任意的timestamp。

分布式數(shù)據(jù)庫(kù)的PITR理論上和單機(jī)區(qū)別不大，每個(gè)節(jié)點(diǎn)備份自己的基礎(chǔ)數(shù)據(jù)，這個(gè)數(shù)據(jù)不需要一致性，但是要考慮到分布式事務(wù)的問(wèn)題，在做基礎(chǔ)備份的時(shí)候必須保證之前的分布式事務(wù)(如果存在)已經(jīng)全部完成，因?yàn)榉植际绞聞?wù)是走兩階段提交協(xié)議，2PC在提交階段不同的機(jī)器commit肯定有時(shí)間差，如果在這個(gè)時(shí)間差做了備份，會(huì)發(fā)現(xiàn)最后一臺(tái)機(jī)器有這個(gè)事務(wù)的redo，另一臺(tái)沒(méi)有，這樣恢復(fù)的話(huà)就會(huì)造成數(shù)據(jù)不一致。這個(gè)問(wèn)題可以通過(guò)pg中一個(gè)barries的概念實(shí)現(xiàn)，在分布式事務(wù)結(jié)束后打一個(gè)barrier，獲得一致性點(diǎn)，然后再進(jìn)行基礎(chǔ)備份。對(duì)于redo的前滾來(lái)說(shuō)，只需要將所有節(jié)點(diǎn)的redo前滾到一個(gè)一致性位點(diǎn)即可。

作者介紹：

張小海，就職于某大型商業(yè)銀行，目前主要負(fù)責(zé)數(shù)據(jù)庫(kù)管理及新技術(shù)研究，PostgreSQL技術(shù)推廣者，個(gè)人公眾號(hào)：數(shù)據(jù)庫(kù)架構(gòu)之美。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】

分享名稱(chēng)：一文看懂金融級(jí)分布式數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)
文章URL：http://m.5511xx.com/article/coicidd.html