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

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

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

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

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

一、分布式的快照隔離

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

在GTM上，要求維護一個開放的事務(wù)列表，事務(wù)列表指的是當(dāng)前這個集群里面正在運行的一些事務(wù)。舉個例子，如果說我當(dāng)前啟動一個新的事務(wù)，然后我就會把它加到這個列表里面來。如果這個事務(wù)結(jié)束了，這個事務(wù)列表就會把這個xid從事務(wù)列表拿掉�？蛻舳嗽谂芤粋�SQL的時候，都會要求從GTM上拉取一個事務(wù)的快照，所謂的事務(wù)快照是將當(dāng)前這個事務(wù)列表里面的一個拷貝，發(fā)到我們的DN上做活躍事務(wù)的判斷。這里有以下3個問題。

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

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

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

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

基于物理時間有兩種方式：

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

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

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

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

用一個TSO集群提供集群的邏輯時間戳作為版本號。這個事務(wù)模型相對來講就沒有之前提到的那幾個版本控制的問題。里面會把當(dāng)前事務(wù)里面進行的所有的修改記錄都記錄下來，在事務(wù)提交的時候一次提交，也就是說它是一個O（N）的動作，N指的是我們在這個事務(wù)里面修改了所有的記錄的集合。而且這個過程中集群會加鎖，阻塞后面的寫入。

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

核心部分是GTS集群，GTS集群和TSO的功能很像，也使用了邏輯時間戳的概念，這個時間戳的基線是我們自己定義的一個開始的點，單向遞增。

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

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

下面分享一下TBase在行存儲和列存儲這一塊的一個選擇。

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

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

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

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

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

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

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

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

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

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