開(kāi)源分布式數(shù)據(jù)庫(kù)RadonDB的核心技術(shù)與實(shí)現(xiàn)是怎樣的

開(kāi)源分布式數(shù)據(jù)庫(kù)RadonDB的核心技術(shù)與實(shí)現(xiàn)是怎樣的，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

RadonDB是一款將分布式一致性協(xié)議Raft與MySQL相結(jié)合的新一代分布式關(guān)系型數(shù)據(jù)庫(kù)，兼具NewSQL和MySQL兩類數(shù)據(jù)庫(kù)的優(yōu)點(diǎn)。下面將從架構(gòu)、執(zhí)行、高可用等角度，結(jié)合開(kāi)源代碼為大家深度解析RadonDB的核心技術(shù)與實(shí)現(xiàn)。

RadonDB是一個(gè)開(kāi)源的分布式數(shù)據(jù)庫(kù)。為什么叫RadonDB呢?RadonDB中的Radon出自元素周期表，是一種惰性氣體，名字叫做氡。因其化學(xué)性質(zhì)比較穩(wěn)定，所以我們就以此來(lái)命名了這款數(shù)據(jù)庫(kù)產(chǎn)品。

RadonDB包含兩個(gè)部分Radon和Xenon，并不是一個(gè)簡(jiǎn)單的數(shù)據(jù)庫(kù)中間件。其中，Radon類似于一個(gè)數(shù)據(jù)庫(kù)中間件，而Xenon是一個(gè)高可用的MySQL管理集群工具。

上圖是RadonDB的整個(gè)架構(gòu)圖，其中最上面一層是Radon，一個(gè)分布式的SQL層，負(fù)責(zé)SQL的解析和轉(zhuǎn)發(fā)。這一層就是大家說(shuō)的數(shù)據(jù)庫(kù)中間件，它會(huì)根據(jù)用戶請(qǐng)求將SQL語(yǔ)句生成分布式執(zhí)行計(jì)劃，并推到下面的存儲(chǔ)層。

下面這一層是Xenon，一個(gè)高可用的MySQL管理工具。在這一層的每個(gè)虛線框里都是一“主”兩“從”的MySQL，都通過(guò)Xenon進(jìn)行管理。Xenon其實(shí)是一個(gè)無(wú)中心化的管理工具，當(dāng)主節(jié)點(diǎn)掛了之后，會(huì)使用Raft協(xié)議進(jìn)行選主，選出新的“主”之后，再根據(jù)MySQL Binlog這些機(jī)制進(jìn)行數(shù)據(jù)同步，從而使新的主節(jié)點(diǎn)繼續(xù)對(duì)外服務(wù)。

下面咱們聊一聊RadonDB的一些技術(shù)細(xì)節(jié)。RadonDB的主要功能是對(duì)用戶SQL生成分布式計(jì)劃以及執(zhí)行器并行執(zhí)行，當(dāng)執(zhí)行器下發(fā)到存儲(chǔ)層以后，進(jìn)行ORDER BY、LIMIT、GROUP BY等二次運(yùn)算。

Radon支持集群模式，所以基本上是無(wú)狀態(tài)的。當(dāng)其中一個(gè)節(jié)點(diǎn)掛了之后，其他節(jié)點(diǎn)可以很快的遷移過(guò)去，保證Radon這一層的高可用。

如果從代碼層面來(lái)看Radon的具體工作流程，用戶SQL到達(dá)Radon之后， query.go文件會(huì)對(duì)SQL進(jìn)行語(yǔ)法樹(shù)的生成，生成之后根據(jù)SQL的類型進(jìn)行處理。

首先，根據(jù)語(yǔ)法樹(shù)生成分布式的執(zhí)行計(jì)劃。分布式的執(zhí)行計(jì)劃是根據(jù)路由表查找每個(gè)具體的數(shù)據(jù)分布在哪些后端，然后生成具體的子句。

分布式執(zhí)行計(jì)劃生成之后，就運(yùn)行Insert executor文件，并下發(fā)到相應(yīng)節(jié)點(diǎn)去執(zhí)行。

以上，就是RadonDB 中Radon這一層的基本工作機(jī)制。

Radon這一層還有一個(gè)比較重要的功能——分布式事務(wù)。Radon分布式事務(wù)是基于MySQL原生事務(wù)——XA事務(wù)來(lái)進(jìn)行的。MySQL的XA事務(wù)在執(zhí)行時(shí)可分為五個(gè)階段：第一個(gè)階段是XA START，第二個(gè)階段是SQL執(zhí)行，第三個(gè)階段是XA END，第四個(gè)階段是XA PREPARE，這個(gè)階段其實(shí)數(shù)據(jù)已經(jīng)通過(guò)Binlog傳到了備庫(kù)，即使主庫(kù)掛了，重建之后事務(wù)仍然處于XA PREPARE狀態(tài)，我們可以認(rèn)為數(shù)據(jù)不會(huì)丟失。最后一個(gè)階段是XA COMMIT。

RadonDB對(duì)這五個(gè)階段進(jìn)行了分工，共分成begin、execute、commit三個(gè)階段。

RadonDB實(shí)現(xiàn)了SI隔離級(jí)別的分布式事務(wù)。Radon里有一個(gè)Commit Lock，如果不加這個(gè)鎖是實(shí)現(xiàn)不了這種隔離級(jí)別的。那么什么是SI隔離級(jí)別呢?SI是SNAPSHOT ISOLATION的縮寫，它的作用是未提交的不可見(jiàn)，例如有三個(gè)分區(qū)，當(dāng)它們都沒(méi)有XA commit時(shí)，其它事務(wù)讀的時(shí)候是看不到未提交事務(wù)的數(shù)據(jù)。另一個(gè)作用是部分提交不可見(jiàn)，還是有三個(gè)分區(qū)，第一個(gè)分區(qū)XA commit了，其他兩個(gè)分區(qū)正準(zhǔn)備commit，這時(shí)候如果有其他的客戶端讀數(shù)據(jù)也是不可見(jiàn)的。

為了檢測(cè)XA的隔離級(jí)別，我們研發(fā)了一個(gè)開(kāi)源工具，它的思路比較簡(jiǎn)單，就是一個(gè)更新線程不停地去更新，16個(gè)掃表線程不停地掃表。如果分布式事務(wù)滿足不了SI隔離級(jí)別，那么16個(gè)掃表線程就有可能看到更新線程的部分?jǐn)?shù)據(jù)。

我們進(jìn)行了100多億次操作和檢測(cè)的測(cè)試，并且過(guò)程是隨機(jī)的。我們會(huì)把存儲(chǔ)層的主節(jié)點(diǎn)宕掉來(lái)做“主從”切換。在大量的測(cè)試中，目前還沒(méi)有發(fā)現(xiàn)讀取到部分?jǐn)?shù)據(jù)的情況。

下面介紹一下RadonDB的另一個(gè)組件——Xenon，一個(gè)高可用的MySQL管理工具。假設(shè)一個(gè)節(jié)點(diǎn)有一“主”兩“從”，三個(gè)MySQL，那么它們之間的高可用怎么來(lái)實(shí)現(xiàn)呢?

Xenon的工作機(jī)制是和MySQL配合，通過(guò)MySQL鏈接不停地去ping MySQL，并拿到MySQL的信息。一個(gè)MySQL對(duì)應(yīng)一個(gè)Xenon，并部署在一個(gè)container里，一“主”兩“從”分布在不同的container里面。當(dāng)Master不可服務(wù)時(shí)，其他的Xenon會(huì)檢測(cè)不到Master發(fā)來(lái)的心跳，這時(shí)由Xenon發(fā)起的心跳會(huì)發(fā)起選主操作，進(jìn)而其他的從節(jié)點(diǎn)會(huì)被選為新的主節(jié)點(diǎn)。

接下來(lái)，我們講一下Xenon如何發(fā)起選主操作、如何選擇新的主節(jié)點(diǎn)以及選完之后如何保證數(shù)據(jù)不丟失?

對(duì)于一“主”多“從”的MySQL集群想要做到高可用有幾個(gè)挑戰(zhàn)：第一是如何選“主”;第二是選“主”之后，數(shù)據(jù)怎么跟原先的Master進(jìn)行同步，保證數(shù)據(jù)不丟失;第三是如何盡快選“主”，當(dāng)原來(lái)的“主”掛了之后，新的主節(jié)點(diǎn)如何盡快應(yīng)用數(shù)據(jù)，并對(duì)外提供服務(wù)。

我們把MySQL的GTID和Raft的選主結(jié)合了起來(lái)。Xenon主要實(shí)現(xiàn)了Raft選主功能，結(jié)合MySQL GTID實(shí)現(xiàn)高可用。了解Raft算法的朋友可能都知道，Raft主要做兩件事，第一件就是選“主”。第二個(gè)就是log同步。Xenon選“主”使用了Raft選主協(xié)議，選“主”之后會(huì)結(jié)合MySQL GTID進(jìn)行數(shù)據(jù)同步。

如果是一“主”兩“從”的節(jié)點(diǎn)，那么這兩個(gè)從節(jié)點(diǎn)哪個(gè)被選為新的主?這里結(jié)合了MySQL的GTID和semi-sync。當(dāng)我們把semi-sync的vote_timeout設(shè)置為無(wú)限長(zhǎng)，基本上就可以認(rèn)為是“主”。寫完之后，至少有一個(gè)“從”會(huì)收到，然后返回給“主”，“主”再返回給cluster，這樣保證至少有一個(gè)“從”和“主”的數(shù)據(jù)是完全同步的。當(dāng)“主”掛了之后，和主節(jié)點(diǎn)數(shù)據(jù)完全同步的從節(jié)點(diǎn)會(huì)被選為新的主節(jié)點(diǎn)，之后根據(jù)MySQL的并行復(fù)制，快速回放，并對(duì)外進(jìn)行提供服務(wù)。

介紹完Radon和Xenon，我們看一下，數(shù)據(jù)在RadonDB里面是怎么分布的?RadonDB的底層存儲(chǔ)基于MySQL，也就是說(shuō)由Xenon管理的一主兩從是一個(gè)節(jié)點(diǎn)，整個(gè)存儲(chǔ)層是由多個(gè)這樣的節(jié)點(diǎn)組成的。

用戶創(chuàng)建一個(gè)表的時(shí)候需要指定一個(gè)分區(qū)鍵，RadonDB會(huì)根據(jù)分區(qū)鍵把整個(gè)大表分成32個(gè)小表。分配規(guī)則是這樣的，整個(gè)表有4096個(gè)槽位，其中每個(gè)小表是128個(gè)槽位，共有32個(gè)小表。

RadonDB的最小單位就是小表，命名為T1_0000到T1_0031，每個(gè)小表都是占128個(gè)槽位，例如第一個(gè)小表是從0到127。這樣當(dāng)用戶在做Insert時(shí)，就可以依據(jù)此判斷數(shù)據(jù)會(huì)落在哪個(gè)小表里。

RadonDB如何做擴(kuò)容呢?RadonDB最小單位是一個(gè)小表，但4096和128這兩個(gè)數(shù)字是可以配置的。在擴(kuò)容上，RadonDB可以讓小表在不同的機(jī)器間動(dòng)態(tài)漂移。因?yàn)槭荕ySQL表，所以把小表從一個(gè)MySQL實(shí)例上飄到另外一個(gè)MySQL實(shí)例比較簡(jiǎn)單。首先是做一個(gè)全量遷移，記下當(dāng)時(shí)遷移的位點(diǎn)，然后再對(duì)增量進(jìn)行追加。這種以小表為遷移的方式不但不影響讀寫操作，而且操作方便，既可以擴(kuò)容，還可以縮容。

RadonDB還支持Binlog，為什么?因?yàn)镽adonDB是一個(gè)分布式數(shù)據(jù)庫(kù)，如果有別的數(shù)據(jù)庫(kù)或數(shù)據(jù)想訂閱RadonDB數(shù)據(jù)，那么就可以訂閱RadonDB Binlog。連上RadonDB之后，執(zhí)行SHOW BINLOG EVENTS，指定從哪個(gè)GTID開(kāi)始，同時(shí)還可以指定訂閱多少條。這樣就可以把RadonDB數(shù)據(jù)實(shí)時(shí)的導(dǎo)入到異構(gòu)的數(shù)據(jù)庫(kù)里。

如果RadonDB收到了比較復(fù)雜的AP操作，例如JOIN，它的機(jī)制又是怎么樣的呢?RadonDB還有一個(gè)計(jì)算節(jié)點(diǎn)，當(dāng)用戶SQL上來(lái)之后，RadonDB如果發(fā)現(xiàn)里面有比較復(fù)雜的JOIN等AP操作，會(huì)自動(dòng)的把這個(gè)請(qǐng)求路由到計(jì)算節(jié)點(diǎn)上。

計(jì)算節(jié)點(diǎn)是插件式的，它可以是其他比較強(qiáng)大的AP分析型數(shù)據(jù)庫(kù)，計(jì)算節(jié)點(diǎn)把結(jié)果計(jì)算完之后，RadonDB會(huì)自動(dòng)的反饋給客戶端，在這種情況下，客戶端是無(wú)法感知到這些操作的。

這樣做的好處是事務(wù)型和計(jì)算型是資源隔離的，但缺點(diǎn)是存儲(chǔ)需要兩份。如何克服缺點(diǎn)呢?其實(shí)目前我們也沒(méi)有很好的辦法，只是通過(guò)壓縮暫時(shí)的解決了這個(gè)問(wèn)題。

RadonDB還實(shí)現(xiàn)了審計(jì)日志功能，當(dāng)用戶的請(qǐng)求到達(dá)RadonDB之后，RadonDB把用戶請(qǐng)求記錄到本地磁盤上。我們可以通過(guò)上圖中的多個(gè)維度進(jìn)行審計(jì)，同時(shí)還可以查詢慢操作。當(dāng)日志請(qǐng)求量比較大時(shí)，RadonDB會(huì)定期進(jìn)行清理。同時(shí)RadonDB還支持多種審計(jì)模式，例如只讀審計(jì)、只寫審計(jì)、讀寫審計(jì)等等。

大家可能會(huì)比較擔(dān)心分布式數(shù)據(jù)庫(kù)灌進(jìn)了大量數(shù)據(jù)就很難導(dǎo)出來(lái)了。針對(duì)這種情況，RadonDB提供了導(dǎo)入和導(dǎo)出的工具，這些工具是并行式的，導(dǎo)入/導(dǎo)出的速度比MySQL原生的Mydumper還快。

RadonDB提供了全鏈路的監(jiān)控，如果分布式數(shù)據(jù)庫(kù)是一個(gè)黑盒，那么出了問(wèn)題就很不容易排查。RadonDB從前往后做了三層監(jiān)控，第一層就是show processlist，這層是監(jiān)控用戶到RadonDB的連接，跟MySQL是一樣的。其中RadonDB實(shí)現(xiàn)了一個(gè)序列表，這一層的作用就是可以看到cluster到RadonDB執(zhí)行的SQL語(yǔ)句。第二層是監(jiān)控RadonDB內(nèi)部峰值事務(wù)執(zhí)行到哪個(gè)階段，大家可以通過(guò)show txnz命令進(jìn)行監(jiān)控;最后一層就是show queryz，這個(gè)命令可以看到具體的子句在哪些后端執(zhí)行。

通過(guò)這三層監(jiān)控就可以很快的定位到具體問(wèn)題，比如一個(gè)慢MySQL，它到底是慢在哪些地方。

上圖是性能對(duì)比表，上面的RadonDB是四個(gè)存儲(chǔ)節(jié)點(diǎn)，下面是單機(jī)MySQL。大家可以看到，RadonDB的性能基本上是單機(jī)的三倍，而延遲基本上是1/3。為什么會(huì)出現(xiàn)這種情況呢?這就是分布式的威力。假設(shè)我們有一個(gè)1TB的表，如果使用單機(jī)數(shù)據(jù)庫(kù)，那么Btree會(huì)比較高，而且每次請(qǐng)求的IO深度路徑也會(huì)比較長(zhǎng)。而RadonDB會(huì)把1TB的數(shù)據(jù)分成四個(gè)節(jié)點(diǎn)，假設(shè)平均每個(gè)節(jié)點(diǎn)是250G，每個(gè)節(jié)點(diǎn)還有細(xì)分每個(gè)小表。當(dāng)用戶請(qǐng)求時(shí)，我們只需請(qǐng)求小表，而且RadonDB對(duì)所有的請(qǐng)求都是并行執(zhí)行的，時(shí)間完全取決于最慢的小表。所以在這種設(shè)計(jì)中，RadonDB的性能基本上會(huì)是單機(jī)的三倍，而延遲是1/3。

最后說(shuō)一下RadonDB的展望，大家都了解類似于Google Spanner這種NewSQL會(huì)是一個(gè)大趨勢(shì)，而且很多公司也都在完全自主研發(fā)NewSQL。有人都認(rèn)為傳統(tǒng)的基于MySQL分庫(kù)分表的方式已經(jīng)過(guò)時(shí)了，而我們提出了一個(gè)新的概念——MyNewSQL，就是MySQL和NewSQL相結(jié)合。

其實(shí)RadonDB就是一個(gè)MyNewSQL，它把NewSQL領(lǐng)域里常用的算法都拿到了MySQL里，從而實(shí)現(xiàn)了MyNewSQL。RadonDB 最后實(shí)現(xiàn)的功能和NewSQL基本無(wú)異，但它是基于MySQL進(jìn)行存儲(chǔ)，表、數(shù)據(jù)結(jié)構(gòu)都可以是異構(gòu)的，性能上也有很大的提升。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。