接下來(lái)給大家詳細(xì)分享下TBase是怎么做的，重點(diǎn)分享架構(gòu)設(shè)計(jì)思路。

講分布式事務(wù)之前首先講下Sharding模式存在的問(wèn)題。這里舉個(gè)例子，我們現(xiàn)在有AB兩個(gè)帳戶(hù)，每個(gè)帳戶(hù)余額是10元，兩個(gè)帳戶(hù)總額是20元，我們對(duì)這兩個(gè)帳戶(hù)之間進(jìn)行轉(zhuǎn)帳，從B往A轉(zhuǎn)5元，并發(fā)量很大的時(shí)候，如果是一個(gè)一致性保持的比較好的系統(tǒng)，那么無(wú)論我們有多少的并發(fā)，兩個(gè)帳戶(hù)的總額應(yīng)該總是20元。

在sharding模式下，事務(wù)3和事務(wù)4存在嚴(yán)重的事務(wù)不一致問(wèn)題。那為什么很多業(yè)務(wù)系統(tǒng)中用了sharding的模式，卻沒(méi)有這類(lèi)問(wèn)題呢。主要的原因是大多數(shù)使用以上模式的業(yè)務(wù)都是互聯(lián)網(wǎng)公司的業(yè)務(wù)，互聯(lián)網(wǎng)公司的開(kāi)發(fā)團(tuán)隊(duì)有比較強(qiáng)的開(kāi)發(fā)能力，可以讓業(yè)務(wù)代碼處理上面遇到的問(wèn)題，把數(shù)據(jù)庫(kù)作為一個(gè)簡(jiǎn)單的數(shù)據(jù)容器來(lái)處理。但對(duì)于一些普通用戶(hù)或者普通場(chǎng)景的話，就不一定具備互聯(lián)網(wǎng)公司的資源和技術(shù)能力了。在TBase中，我們也是需要處理分布式事務(wù)的一致性問(wèn)題，為業(yè)務(wù)屏蔽掉事務(wù)的相關(guān)細(xì)節(jié)。這里我分享下TBase分布式事務(wù)系統(tǒng)的目標(biāo)。

首先在保證分布式事務(wù)完整性的基礎(chǔ)上能夠提供高性能、低延時(shí)、高吞吐的事務(wù)能力，并盡量使用低成本的硬件來(lái)達(dá)成我們的目標(biāo)。同時(shí)，也希望在保證這三者的基礎(chǔ)上，我們事務(wù)的處理能力能夠隨著集群的規(guī)模近似線性的增加，提供事務(wù)處理能力的擴(kuò)展性，提供包括死鎖檢測(cè)和事務(wù)故障恢復(fù)等事務(wù)保障能力。

在開(kāi)始介紹TBase事務(wù)模型之前，先來(lái)看一下現(xiàn)在大家常用的分布式事務(wù)模型。

一、分布式的快照隔離

可以簡(jiǎn)單理解是PostgreSQL使用的MVCC的分布式的實(shí)現(xiàn)，這里面主要分幾個(gè)部分。

在GTM上，要求維護(hù)一個(gè)開(kāi)放的事務(wù)列表，事務(wù)列表指的是當(dāng)前這個(gè)集群里面正在運(yùn)行的一些事務(wù)。舉個(gè)例子，如果說(shuō)我當(dāng)前啟動(dòng)一個(gè)新的事務(wù)，然后我就會(huì)把它加到這個(gè)列表里面來(lái)。如果這個(gè)事務(wù)結(jié)束了，這個(gè)事務(wù)列表就會(huì)把這個(gè)xid從事務(wù)列表拿掉。客戶(hù)端在跑一個(gè)SQL的時(shí)候，都會(huì)要求從GTM上拉取一個(gè)事務(wù)的快照，所謂的事務(wù)快照是將當(dāng)前這個(gè)事務(wù)列表里面的一個(gè)拷貝，發(fā)到我們的DN上做活躍事務(wù)的判斷。這里有以下3個(gè)問(wèn)題。

問(wèn)題1：這個(gè)活躍事務(wù)列表是一個(gè)O（N）的長(zhǎng)度，也就是說(shuō)它和當(dāng)前事務(wù)并發(fā)的個(gè)數(shù)是呈正比方式的，有多少個(gè)并發(fā)的事務(wù)在跑，這個(gè)事務(wù)的列表就有多長(zhǎng)。

問(wèn)題2：剛才也提到我們每個(gè)客戶(hù)端在訪問(wèn)SQL的時(shí)候需要從服務(wù)器去拉取一個(gè)快照到本地去，這樣的話也就是說(shuō)對(duì)GTM的網(wǎng)絡(luò)占用的比例是N的平方，也就是N的平方乘以M，M是SQL的個(gè)數(shù)。

問(wèn)題3：剛才也提到了，事務(wù)列表是全局資源，不管是事務(wù)的啟動(dòng)還是提交，甚至獲取快照都需要對(duì)這個(gè)列表進(jìn)行加速。這樣的話，基本上來(lái)講我們是在系統(tǒng)里面增加了一個(gè)全局的大鎖，這個(gè)大鎖就會(huì)成為這個(gè)系統(tǒng)的一個(gè)擴(kuò)展的瓶頸。

二、基于物理時(shí)間的并發(fā)控制

基于物理時(shí)間有兩種方式：

第一種方式是Google spanner中采用的方式，這個(gè)分布式系統(tǒng)要求提供一個(gè)全球分布式的一個(gè)分布式數(shù)據(jù)庫(kù)，達(dá)到百萬(wàn)級(jí)的數(shù)據(jù)庫(kù)節(jié)點(diǎn)。基于全局時(shí)間快照的進(jìn)行并發(fā)控制，它的全局時(shí)間快照使用的是GPS和原子鐘一起生成。全局時(shí)間版本，這個(gè)東西有一個(gè)6毫秒左右的誤差。也就是說(shuō)它的一個(gè)事務(wù)在運(yùn)行的時(shí)候，最低延時(shí)就是6毫秒。第二個(gè)問(wèn)題是成本比較高，需要專(zhuān)用硬件，每個(gè)IDC都需要有自己的原子鐘和GPS設(shè)備。

第二種方式是CockRoachDB，其實(shí)是Google Spanner的變種。主要的區(qū)別是它使用的是本地的時(shí)間來(lái)進(jìn)行控制，嚴(yán)格意義上講應(yīng)該是混合時(shí)鐘。相比之下成本會(huì)比較低廉，并且沒(méi)有中心節(jié)點(diǎn)。但是NTP精度會(huì)影響事務(wù)的時(shí)延。

三、基于邏輯時(shí)間的并發(fā)控制

現(xiàn)在大家討論的比較多的是基于邏輯時(shí)間的并發(fā)控制。

用一個(gè)TSO集群提供集群的邏輯時(shí)間戳作為版本號(hào)。這個(gè)事務(wù)模型相對(duì)來(lái)講就沒(méi)有之前提到的那幾個(gè)版本控制的問(wèn)題。里面會(huì)把當(dāng)前事務(wù)里面進(jìn)行的所有的修改記錄都記錄下來(lái)，在事務(wù)提交的時(shí)候一次提交，也就是說(shuō)它是一個(gè)O（N）的動(dòng)作，N指的是我們?cè)谶@個(gè)事務(wù)里面修改了所有的記錄的集合。而且這個(gè)過(guò)程中集群會(huì)加鎖，阻塞后面的寫(xiě)入。

這里重點(diǎn)介紹TBase這一塊，TBase的并發(fā)控制，全局事務(wù)的一個(gè)控制其實(shí)是結(jié)合了最早提到的分布式快照隔離一起做的一個(gè)隔離模型。

核心部分是GTS集群，GTS集群和TSO的功能很像，也使用了邏輯時(shí)間戳的概念，這個(gè)時(shí)間戳的基線是我們自己定義的一個(gè)開(kāi)始的點(diǎn)，單向遞增。

我們自己內(nèi)部定義了MVCC機(jī)制原理，對(duì)于當(dāng)前事務(wù)，記錄的gts＿min已經(jīng)提交，而且事務(wù)的gts小于記錄的gts＿max，我們才能看到這條記錄。

GTS是從0開(kāi)始的一個(gè)單向遞增的邏輯時(shí)鐘源，通過(guò)硬件提供足夠的穩(wěn)定性保證，保證不發(fā)生偏斜。同時(shí)，GTS本身通過(guò)流復(fù)制的方式來(lái)保證自己的可靠性。性能方面，一般普通24 core的服務(wù)器可以達(dá)到1200萬(wàn)的QPS，幾乎可以滿足所有業(yè)務(wù)場(chǎng)景的需要。

下面分享一下TBase在行存儲(chǔ)和列存儲(chǔ)這一塊的一個(gè)選擇。

行存儲(chǔ)的話，顧名思義，是按行存儲(chǔ)。也就是說(shuō)在磁盤(pán)存儲(chǔ)的時(shí)候，我們像上面的表一樣，我們存儲(chǔ)的時(shí)候是先存儲(chǔ)完第一行，然后存儲(chǔ)第二行，再存儲(chǔ)第三行，再第四行，這樣緊密存儲(chǔ)。這個(gè)好處在于：每次IO的時(shí)候，可以把一行記錄的所有的列都能夠讀到這里面去，適合OLTP場(chǎng)景。

另外一個(gè)是按列存儲(chǔ)，我們把同一列的數(shù)據(jù)連續(xù)存儲(chǔ)在一起。比如：蜘蛛俠、超人、火箭浣熊、閃電俠這一列在磁盤(pán)上面，第二列是另外一個(gè)文件，這種存儲(chǔ)的好處在于：每次IO的時(shí)候，只會(huì)讀取同一列的數(shù)據(jù)，可以大大的提升聚合操作處理的效率，比較適合OLAP的場(chǎng)景。

在分布式場(chǎng)景下，我們不得不考慮另外一個(gè)問(wèn)題，除了選擇的行列之外，還要考慮我的數(shù)據(jù)在集群里面如何存儲(chǔ)，也就是怎么把數(shù)據(jù)分片存在我們的分布式集群里面去，TBase里面叫選擇表的分布類(lèi)型。

第一種是復(fù)制表，有的地方叫快表，在集群里面的指定節(jié)點(diǎn)上，每個(gè)節(jié)點(diǎn)都會(huì)有數(shù)據(jù)的完整副本，這樣的表特別適合一些變化比較小的小表，對(duì)于一些關(guān)聯(lián)插件的加速是比較有用的。

第二種是大家比較常見(jiàn)的是HASH分布，就是把數(shù)據(jù)打散到不同的存儲(chǔ)節(jié)點(diǎn)上去，明顯的問(wèn)題是HASH傾斜。

第三種也是比較常見(jiàn)的方式RANGE分布，即按照數(shù)據(jù)的范圍來(lái)進(jìn)行分布。其實(shí)在分布式場(chǎng)景中，除了這種我們可以指定具體的算法進(jìn)行分布的方式之外的，還有就是在數(shù)據(jù)倉(cāng)庫(kù)里面比較常用的隨機(jī)分布，不用任何算法來(lái)進(jìn)行分散，把數(shù)據(jù)全部打散到整個(gè)集群中去。TBase的分布方式主要有復(fù)制表和HASH分布兩種。

關(guān)于分布式查詢(xún)的執(zhí)行方式，在MPP這種架構(gòu)下每個(gè)DN的數(shù)據(jù)都是不完整的。為了完成一個(gè)完整的分布式查詢(xún)，有一些策略需要選擇。如果是一些單點(diǎn)的查詢(xún)就無(wú)所謂，比較難搞的是分布式的JOIN。

這里面的策略主要有兩種，一種是所謂的PUSH QUERY，通過(guò)把它的查詢(xún)下推到DN節(jié)點(diǎn)上去， SQL在DN上執(zhí)行，把數(shù)據(jù)返回給CN。另外一種方式就是PULL DATA，也就是通過(guò)把DN節(jié)點(diǎn)上的數(shù)據(jù)拉取到CN上通過(guò)CN來(lái)完成所有的計(jì)算。數(shù)據(jù)量較大的時(shí)候， PUSH QUERY效率會(huì)高很多，PULL DATA在一些數(shù)據(jù)量比較小的時(shí)候，效率會(huì)比較好。TBase里面兩種方式都會(huì)有，我們也會(huì)選擇PUSH QUERY或者PULL DATA，至于選擇哪種是根據(jù)我們的優(yōu)化器來(lái)選擇。

分布式執(zhí)行在 SQL shipping還是PLAN shipping之前該如何選擇？

SQL shipping是指我們?cè)赑USH QUERY的時(shí)候是PUSH SQL，DN完成SQL解析和優(yōu)化執(zhí)行。這種場(chǎng)模式不適合復(fù)雜SQL的執(zhí)行，但架構(gòu)相對(duì)比較簡(jiǎn)單，易開(kāi)發(fā)易維護(hù)。所謂的PLAN shipping是在CN節(jié)點(diǎn)上生成整個(gè)執(zhí)行計(jì)劃，CN節(jié)點(diǎn)再根據(jù)我們的統(tǒng)計(jì)信息和數(shù)據(jù)分布來(lái)生成計(jì)劃的分片，再把這個(gè)下推到各個(gè)DN節(jié)點(diǎn)上去，這個(gè)時(shí)候DN節(jié)點(diǎn)就不會(huì)進(jìn)行二次解析，拿到執(zhí)行計(jì)劃并返回結(jié)果。這種方式優(yōu)點(diǎn)其實(shí)比較明顯的，它對(duì)SQL的優(yōu)化能力是比較強(qiáng)的，能夠在一些特別復(fù)雜條件的時(shí)候，效率會(huì)比較好。不過(guò)缺點(diǎn)比較明顯，對(duì)于一些數(shù)據(jù)量不大的場(chǎng)景，執(zhí)行計(jì)劃的解析和下發(fā)花了很多的時(shí)間，導(dǎo)致簡(jiǎn)單查詢(xún)的時(shí)候，小數(shù)據(jù)量查詢(xún)效率不高。在TBase中，我們會(huì)根據(jù)我們業(yè)務(wù)的特點(diǎn)和數(shù)據(jù)的特點(diǎn)來(lái)選擇兩種中的任何一個(gè)，也就是說(shuō)TBase兩個(gè)都是支持的。