怎么解析RadonDB分布式數(shù)據(jù)庫(kù)核心技術(shù)與實(shí)現(xiàn)

怎么解析RadonDB分布式數(shù)據(jù)庫(kù)核心技術(shù)與實(shí)現(xiàn)，相信很多沒有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

摘要：隨著數(shù)據(jù)規(guī)模的逐步擴(kuò)大，存儲(chǔ)和運(yùn)維成本逐漸增加，企業(yè)對(duì)數(shù)據(jù)庫(kù)的要求也逐漸提高。有人認(rèn)為以MySQL為代表的傳統(tǒng)數(shù)據(jù)庫(kù)已經(jīng)過(guò)時(shí)，不能滿足數(shù)據(jù)爆炸時(shí)代企業(yè)的要求;以NoSQL為代表的新型數(shù)據(jù)庫(kù)仍有局限性，不具備ACID特性，很難滿足企業(yè)對(duì)核心業(yè)務(wù)數(shù)據(jù)的嚴(yán)苛需求。此次分享的RadonDB是一款將分布式一致性協(xié)議Raft與MySQL相結(jié)合的新一代分布式關(guān)系型數(shù)據(jù)庫(kù)。RadonDB的最大特點(diǎn)是結(jié)合兩類數(shù)據(jù)庫(kù)的優(yōu)點(diǎn)，讓DBA無(wú)縫地從傳統(tǒng)的、單機(jī)時(shí)代的MySQL過(guò)渡到云原生的、無(wú)限擴(kuò)展的分布式關(guān)系型數(shù)據(jù)庫(kù)。

RadonDB架構(gòu)圖

RadonDB定位是新一代分布式關(guān)系數(shù)據(jù)庫(kù)，在今天這個(gè)云計(jì)算快速發(fā)展的時(shí)代，我們更愿意稱它是一個(gè)云原生數(shù)據(jù)庫(kù)，云原生數(shù)據(jù)庫(kù)的天然屬性是分布式、可擴(kuò)展、高可用、強(qiáng)一致。下面的MyNewSQL，是因?yàn)槲覀儼袽ySQL和NewSQL融合起來(lái)，來(lái)滿足以上的幾個(gè)特性。

當(dāng)中一個(gè)請(qǐng)求到來(lái)之后，SQL層會(huì)把這個(gè)請(qǐng)求解析成分布式的執(zhí)行計(jì)劃，然后，把這個(gè)SQL在后端的存儲(chǔ)層并行的執(zhí)行。而且它還會(huì)進(jìn)行二次運(yùn)算，就是Orderby/limit/groupby/aggration/join….等等。它還是一個(gè)無(wú)中心化的設(shè)計(jì)，部署起來(lái)比較方便，容易擴(kuò)展，這是整個(gè)SQL層的一個(gè)設(shè)計(jì)。

Storage Nodes

再看存儲(chǔ)層，存儲(chǔ)層是RadonDB里一個(gè)比較新穎的設(shè)計(jì)，也是我們定位為在新一代分布式數(shù)據(jù)庫(kù)的一個(gè)原因。

　　第一個(gè)挑戰(zhàn)，怎么快速選主?

　　第二個(gè)挑戰(zhàn)，選出新的主后，數(shù)據(jù)怎么快速地回放?

　　第三個(gè)挑戰(zhàn)，數(shù)據(jù)回放完，數(shù)據(jù)怎么保證不丟失? RadonDB是怎么解決的?

對(duì)于第一個(gè)挑戰(zhàn)，我們使用了Raft協(xié)議，大家要知道，Raft協(xié)議主要干兩件事，第一個(gè)就是選主，第二個(gè)是數(shù)據(jù)同步。在RadonDB里只使用Raft進(jìn)行選主，當(dāng)主掛掉之后，我們使用Raft選出新的主，然后數(shù)據(jù)同步。我們是基于MySQL原生的FGTID機(jī)制和并行復(fù)制這些特性進(jìn)行快速回放。

保證數(shù)據(jù)不丟失，我們還是基于MySQL，并使用了MySQL的Semi-Sync機(jī)制，當(dāng)用戶寫到主副本時(shí)，首先，它要到達(dá)一個(gè)從副本，從副本收到之后，再反饋給客戶端，這樣就時(shí)刻地保證了一個(gè)從副本與主副本的數(shù)據(jù)完全一致，從節(jié)點(diǎn)被選入新的主節(jié)點(diǎn)，保證了這個(gè)數(shù)據(jù)不丟失。

當(dāng)選入新的主節(jié)點(diǎn)之后，RadonDB的Log 并行復(fù)制還是基于MySQL的機(jī)制，并行復(fù)制，快速地回放，這就等于實(shí)現(xiàn)了把Raft選主和Log 并行復(fù)制結(jié)合。原生態(tài)Raft協(xié)議里這兩個(gè)，Raft Log并行回放是比較困難的，但是，我們結(jié)合MySQL就很好地完成了。而且，這三個(gè)副本是一個(gè)無(wú)中心化的設(shè)計(jì)，只要我們可達(dá)，它的部署比較靈活。

擴(kuò)容

RadonDB的底層是全部基于MySQL，所以在擴(kuò)容的時(shí)候也比較方便，因?yàn)镸ySQL有一套工具和機(jī)制。

大家可以看到上圖，其實(shí)MySQL Xa機(jī)制總共有5個(gè)步驟，但是到RadonDB里，我們進(jìn)行了抽象，就是進(jìn)行了封裝。我們實(shí)現(xiàn)了快照的隔離級(jí)別，實(shí)現(xiàn)了Snapshot Isolation事務(wù)隔離級(jí)別。

Binlog

另外，RadonDB支持Binlog，大家可能認(rèn)為一個(gè)分布式數(shù)據(jù)庫(kù)，就是里面需要放一些海量的數(shù)據(jù)，但數(shù)據(jù)一旦進(jìn)入你的分布數(shù)據(jù)庫(kù)，怎么能出來(lái)?就比較麻煩，因此， RadonDB提供一個(gè)Binlog機(jī)制，就是讓數(shù)據(jù)能快速的同步處理。

OLTP + OLAP

比如說(shuō)，我們有一個(gè)OLAP的集群，可設(shè)置為RadonDB的Binlog，Binlog是實(shí)時(shí)地更新，這就完成了一個(gè)異構(gòu)化的過(guò)程和數(shù)據(jù)流出，而且是實(shí)時(shí)的。

大家也看到，在剛才的架構(gòu)圖里，右下角有一個(gè)計(jì)算節(jié)點(diǎn)，其實(shí)，我們的計(jì)算節(jié)點(diǎn)就是通過(guò)這種機(jī)制跟RadonDB的數(shù)據(jù)進(jìn)行同步。這樣，就把OLTP和OLAP結(jié)合了起來(lái)，當(dāng)用戶一個(gè)比較復(fù)雜的查詢到達(dá)RadonDB之后，RadonDB會(huì)根據(jù)SQL的模式發(fā)到TP節(jié)點(diǎn)還是AP節(jié)點(diǎn)，前端的用戶是沒有感知的，這就做到了一些資源的隔離。當(dāng)然了，這也有一個(gè)缺點(diǎn)，數(shù)據(jù)可能是兩份，但目前，我們是通過(guò)異構(gòu)化、列式存儲(chǔ)來(lái)進(jìn)行的，高壓縮做這種機(jī)制。

審計(jì)日志

另外，RadonDB還提供了一些審計(jì)日志這些功能，為了方便大家對(duì)業(yè)務(wù)進(jìn)行一些審計(jì)，而且審計(jì)機(jī)制還可以定位一些慢查詢SQL，因?yàn)榉植际降臄?shù)據(jù)庫(kù)，節(jié)點(diǎn)比較多，所以定位一個(gè)SQL會(huì)比較復(fù)雜，有了審計(jì)日志，大家可以定位一些慢的SQL。

備份和恢復(fù)

RadonDB提供了一整套備份和恢復(fù)的工具，可以讓用戶快速地把數(shù)據(jù)流進(jìn)去，流出來(lái)，比原生的要快很多。

性能

　　mysql> show processlist;

　　第一條命是，MySQL常用的，表示用戶的鏈接到RadonDB的狀態(tài)。

　　mysql> show txnz;

　　第二個(gè)命令是，分布式事務(wù)在哪個(gè)階段執(zhí)行，耗時(shí)多少，這個(gè)都可以很清楚地看到。

　　mysql> show queryz;

　　最后一個(gè)命令，具體哪些子句落到哪些節(jié)點(diǎn)，甚至耗時(shí)多少，比如說(shuō)，某個(gè)節(jié)點(diǎn)有一些問(wèn)題，都可以從這個(gè)上面反映出來(lái)，比較靈活。

看完上述內(nèi)容，你們掌握怎么解析RadonDB分布式數(shù)據(jù)庫(kù)核心技術(shù)與實(shí)現(xiàn)的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！