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

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

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

　　背景介紹

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

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

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

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

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

　　RadonDB架構

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

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

　　Ø SQL節點(SQL Node)

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

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

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

　　Ø 存儲節點(Storage Nodes)

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

　　Ø 計算節點(Compute Nodes)

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

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

　　數據均衡

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

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

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

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

　　總結

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

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

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

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

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

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

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

特別提醒：本網內容轉載自其他媒體，目的在于傳遞更多信息，并不代表本網贊同其觀點。其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯系我們，本站將會在24小時內處理完畢。