作者：李丹 來(lái)源：微信公眾號(hào) HULK一線技術(shù)雜談

本文是來(lái)自邏輯思維DBA李丹在RadonDB體驗(yàn)會(huì)后的分享筆記。憑借在行業(yè)內(nèi)多年的數(shù)據(jù)庫(kù)開(kāi)發(fā)和運(yùn)維經(jīng)驗(yàn)，李丹在DBA運(yùn)維、擴(kuò)容以及高可用等方面，給出了針對(duì)分布式數(shù)據(jù)庫(kù)RadonDB的客觀評(píng)價(jià)。

上上周收到吳炳錫老師和青云QingCloud的邀請(qǐng)，參加了即將開(kāi)源的基于MySQL的一款分布式數(shù)據(jù)庫(kù)RadonDB的技術(shù)交流會(huì)。由于本人對(duì)于各大公有云廠商底層技術(shù)的實(shí)現(xiàn)比較感興趣，所以對(duì)此次技術(shù)交流會(huì)有一些心得并做了總結(jié)。接下來(lái)就給大家分享參與RadonDB的交流的一些心得。

背景介紹

在詳細(xì)介紹RadonDB體驗(yàn)心得之前，我們先來(lái)介紹一下當(dāng)下DBA在使用傳統(tǒng)MySQL主從或主從+proxy架構(gòu)模式下依然存在的一些棘手問(wèn)題。

1。 基于第三方插件(通常MHA)的快速切換與數(shù)據(jù)一致性保證;

2。 單實(shí)例海量數(shù)據(jù)分庫(kù)分表后的group、sort、limit及join查詢(xún);

3。 分庫(kù)分片后各實(shí)例數(shù)據(jù)不均及數(shù)據(jù)增長(zhǎng)后二次拆分問(wèn)題;

4。 分庫(kù)分片后跨實(shí)例操作的分布式事物保證問(wèn)題。

RadonDB架構(gòu)

總體上來(lái)說(shuō)RadonDB相對(duì)優(yōu)雅的解決了上述問(wèn)題，不過(guò)要清楚知道RadonDB如何處理上述問(wèn)題我們得首先了解一下它的整體架構(gòu)。

第一眼看上去除了多出了計(jì)算節(jié)點(diǎn)(Compute Nodes)，整個(gè)架構(gòu)和一般的分庫(kù)分表中間件+MySQL沒(méi)什么太大的區(qū)別。但實(shí)際上里面的很多設(shè)計(jì)細(xì)節(jié)很值得玩味，具體如下：

Ø SQL節(jié)點(diǎn)(SQL Node)

SQL節(jié)點(diǎn)(SQL Node)，負(fù)責(zé)一些如分布式執(zhí)行計(jì)劃和分布式事物協(xié)調(diào)的工作，因此一般的DML操作都具備了分布式事物保證，不過(guò)DDL沒(méi)有提供類(lèi)似的保障。

當(dāng)然DDL操作一般變更頻率不高，同時(shí)小概率失敗(可手動(dòng)重試)也并不影響業(yè)務(wù)，DBA在使用上進(jìn)行控制即可。需要提醒的是為了保障分布式事物Snapshot隔離級(jí)別，SQL節(jié)點(diǎn)只有一個(gè)對(duì)外提供寫(xiě)，其他節(jié)點(diǎn)只讀。

更重要的一點(diǎn)是每個(gè)SQL節(jié)點(diǎn)存儲(chǔ)了一份表(table)存儲(chǔ)分布的元數(shù)據(jù)，借助元數(shù)據(jù)信息可以很方便的進(jìn)行后端存儲(chǔ)節(jié)點(diǎn)的數(shù)據(jù)遷移操作(有點(diǎn)類(lèi)似mongo的balance功能)。SQL節(jié)點(diǎn)之間會(huì)相互進(jìn)行通信交換元數(shù)據(jù)的變化信息，通信協(xié)議類(lèi)似于redis cluster 采用的當(dāng)前流行的gossip協(xié)議。

Ø 存儲(chǔ)節(jié)點(diǎn)(Storage Nodes)

存儲(chǔ)節(jié)點(diǎn)(Storage Nodes)，實(shí)際上直接使用的是MySQL5.7(其實(shí)也兼容5.6+GTID)的默認(rèn)三個(gè)節(jié)點(diǎn)的N組(N>=1)主從集群結(jié)構(gòu)。不過(guò)這里引入了與mongo類(lèi)似的raft(分布式一致性協(xié)議)協(xié)議來(lái)進(jìn)行自動(dòng)高可用切換。RadonDB的raft協(xié)議實(shí)現(xiàn)主要是基于GTID日志，因此RadonDB要求必須開(kāi)啟GTID復(fù)制模式，同時(shí)為了提供金融場(chǎng)景下的數(shù)據(jù)強(qiáng)一致性保障，RadonDB要求采用強(qiáng)semi-sync+永不超時(shí)機(jī)制。在實(shí)際的使用中DBA自己可以依據(jù)不同的場(chǎng)景進(jìn)行不同的配置。

Ø 計(jì)算節(jié)點(diǎn)(Compute Nodes)

計(jì)算節(jié)點(diǎn)(Compute Nodes)，這個(gè)設(shè)計(jì)讓人眼前一亮，之前也設(shè)計(jì)過(guò)分布式proxy Atlas，當(dāng)時(shí)一直為高并發(fā)查詢(xún)與跨物理節(jié)點(diǎn)的復(fù)雜查詢(xún)并存時(shí)的性能問(wèn)題頭疼不已。實(shí)際上SQL節(jié)點(diǎn)會(huì)對(duì)請(qǐng)求SQL進(jìn)行解析，并決定哪些是復(fù)雜SQL，然后將對(duì)應(yīng)請(qǐng)求路由至計(jì)算節(jié)點(diǎn)。

需要注意的是計(jì)算節(jié)點(diǎn)存儲(chǔ)的是所有Storage Nodes集群的全量數(shù)據(jù)，并且內(nèi)部通過(guò)基于binlog訂閱-消費(fèi)模式來(lái)對(duì)數(shù)據(jù)進(jìn)行增量更新。值得一提的是計(jì)算節(jié)點(diǎn)采用插件模式，也就意味著計(jì)算節(jié)點(diǎn)不一定非要是MySQL，也可以是其他類(lèi)型的DB。當(dāng)然計(jì)算節(jié)點(diǎn)因?yàn)榇鎯?chǔ)的是全量數(shù)據(jù)，雖然當(dāng)前采用壓縮存儲(chǔ)不過(guò)也有較大的存儲(chǔ)空間代價(jià)。

數(shù)據(jù)均衡

介紹完RadonDB整體架構(gòu)，個(gè)人對(duì)它的表存儲(chǔ)設(shè)計(jì)和數(shù)據(jù)均衡印象深刻。通常的關(guān)系型數(shù)據(jù)庫(kù)的拆分或者常見(jiàn)的開(kāi)源proxy一般都是沒(méi)有解決不同分片數(shù)據(jù)均衡的問(wèn)題，而RadonDB提供了一個(gè)新的解決思路，表存儲(chǔ)策略具體見(jiàn)下圖：

從上圖可以看到在RadonDB里創(chuàng)建一個(gè)以id作為分片key的表t1，表t1會(huì)默認(rèn)被自動(dòng)切分為32張小表，它們均勻的分散在多個(gè)存儲(chǔ)節(jié)點(diǎn)上。每個(gè)小表都有一個(gè)自己的哈希區(qū)間，用于標(biāo)識(shí)自己所能存儲(chǔ)的HASH范圍。通過(guò)交流發(fā)現(xiàn)，實(shí)際上這種拆分方式借鑒的就是redis cluster slot的存儲(chǔ)分配策略。這樣切分的最大好處就是即使一張100GB+的邏輯表，實(shí)際上在集群節(jié)點(diǎn)的存儲(chǔ)會(huì)被切分成很小的多張表，這對(duì)于維護(hù)和數(shù)據(jù)遷移還是比較優(yōu)雅的。

接下來(lái)我們看一下RadonDB是如何進(jìn)行擴(kuò)容，或者說(shuō)數(shù)據(jù)均衡的，具體遷移過(guò)程也可以用如下圖來(lái)說(shuō)明：

綠色框里表示添加一個(gè)分片后數(shù)據(jù)的分布情況，實(shí)際上RadonDB會(huì)通過(guò)基于Go語(yǔ)言自研的shifter工具(源碼尚未開(kāi)源，以工具方式提供使用)進(jìn)行并發(fā)式全量+增量的同步，當(dāng)然為了盡量減少遷移的數(shù)據(jù)量，RadonDB會(huì)優(yōu)先以小表進(jìn)行遷移。不過(guò)這里有一個(gè)問(wèn)題需要注意，在遷移最后路由切換那一刻，原表需要一個(gè)只讀狀態(tài)，這期間對(duì)于業(yè)務(wù)來(lái)說(shuō)可能會(huì)有一個(gè)瞬間的小抖動(dòng)。

總結(jié)

總體來(lái)說(shuō)，RadonDB實(shí)際可以理解為是一個(gè)中間件，并結(jié)合了當(dāng)前流行的分布式一致性協(xié)議(raft)和通信協(xié)議(gossip)以及MySQL實(shí)現(xiàn)的一套分布式解決方案。

它解決了DBA一直面臨的關(guān)系型數(shù)據(jù)庫(kù)分布式事物、分布式模式下數(shù)據(jù)均衡、高可用切換、數(shù)據(jù)一致性及分布式模型下復(fù)雜查詢(xún)性能等一系列問(wèn)題。

不過(guò)在體驗(yàn)過(guò)程中也發(fā)現(xiàn)一些可以改進(jìn)的點(diǎn)及實(shí)際使用建議。具體如下：

1。 分片擴(kuò)容數(shù)據(jù)遷移采用的是全量+增量的方式，是否可以類(lèi)似mongo的那樣直接在分片之間進(jìn)行數(shù)據(jù)同步而無(wú)需dump，這樣的實(shí)現(xiàn)可能會(huì)更優(yōu)雅些。

2。 一般可能會(huì)推薦RadonDB采用vip模式來(lái)實(shí)現(xiàn)對(duì)業(yè)務(wù)的透明訪問(wèn)，不過(guò)對(duì)于一般中小型企業(yè)并沒(méi)有穩(wěn)定可靠的lvs服務(wù)并且vip管理也是一個(gè)問(wèn)題，這里建議使用服務(wù)發(fā)現(xiàn)或配置管理方案如開(kāi)源的consul或360開(kāi)源的qconf。

3。 部分自建私有云平臺(tái)可能因?yàn)橹皩?duì)MySQL 5.5或5.6的技術(shù)定制高度依賴(lài)升級(jí)到5.7或后續(xù)的8.0難度較高，RadonDB可能是一個(gè)很好的契機(jī)或許可以一試。

RadonDB現(xiàn)已開(kāi)源，希望RadonDB能給大家在MySQL運(yùn)維上帶來(lái)不一樣的體驗(yàn)，敬請(qǐng)期待吧~

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。