作者：李丹 來源：微信公眾號 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ù)均衡印象深刻。通常的關系型數(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一直面臨的關系型數(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)容轉(zhuǎn)載自其他媒體，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實，對本文以及其中全部或者部分內(nèi)容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內(nèi)容。本站不承擔此類作品侵權(quán)行為的直接責任及連帶責任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請及時聯(lián)系我們，本站將會在24小時內(nèi)處理完畢。