一款可能解放DBA的分布式數(shù)據(jù)庫RadonDB的體驗之旅

作者：李丹 來源：微信公眾號 HULK一線技術(shù)雜談

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

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

背景介紹

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

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

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

3。 分庫分片后各實例數(shù)據(jù)不均及數(shù)據(jù)增長后二次拆分問題;

4。 分庫分片后跨實例操作的分布式事物保證問題。

RadonDB架構(gòu)

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

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

Ø SQL節(jié)點(SQL Node)

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

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

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

Ø 存儲節(jié)點(Storage Nodes)

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

Ø 計算節(jié)點(Compute Nodes)

計算節(jié)點(Compute Nodes)，這個設計讓人眼前一亮，之前也設計過分布式proxy Atlas，當時一直為高并發(fā)查詢與跨物理節(jié)點的復雜查詢并存時的性能問題頭疼不已。實際上SQL節(jié)點會對請求SQL進行解析，并決定哪些是復雜SQL，然后將對應請求路由至計算節(jié)點。

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

3。 部分自建私有云平臺可能因為之前對MySQL 5.5或5.6的技術(shù)定制高度依賴升級到5.7或后續(xù)的8.0難度較高，RadonDB可能是一個很好的契機或許可以一試。

RadonDB現(xiàn)已開源，希望RadonDB能給大家在MySQL運維上帶來不一樣的體驗，敬請期待吧~

生成海報

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