一款可能解放DBA的分佈式數據庫RadonDB的體驗之旅

女主宣言

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

背景介紹

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

基於第三方插件（通常MHA）的快速切換與數據一致性保證；

單實例海量數據分庫分表後的group、sort、limit及join查詢；

分庫分片後各實例數據不均及數據增長後二次拆分問題；

分庫分片後跨實例操作的分佈式事物保證問題。

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一直面臨的關係型數據庫分佈式事物、分佈式模式下數據均衡、高可用切換、數據一致性及分佈式模型下複雜查詢性能等一系列問題。

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

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

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

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