作者：李丹 來源：微信公眾號 HULK一線技術雜談
本文是來自邏輯思維DBA李丹在RadonDB體驗會后的分享筆記。憑借在行業(yè)內多年的數據庫開發(fā)和運維經驗，李丹在DBA運維、擴容以及高可用等方面，給出了針對分布式數據庫RadonDB的客觀評價。
上上周收到吳炳錫老師和青云QingCloud的邀請，參加了即將開源的基于MySQL的一款分布式數據庫RadonDB的技術交流會。由于本人對于各大公有云廠商底層技術的實現比較感興趣，所以對此次技術交流會有一些心得并做了總結。接下來就給大家分享參與RadonDB的交流的一些心得。
背景介紹
在詳細介紹RadonDB體驗心得之前，我們先來介紹一下當下DBA在使用傳統(tǒng)MySQL主從或主從+proxy架構模式下依然存在的一些棘手問題。
1。 基于第三方插件(通常MHA)的快速切換與數據一致性保證;
2。 單實例海量數據分庫分表后的group、sort、limit及join查詢;
3。 分庫分片后各實例數據不均及數據增長后二次拆分問題;
4。 分庫分片后跨實例操作的分布式事物保證問題。
RadonDB架構
總體上來說RadonDB相對優(yōu)雅的解決了上述問題，不過要清楚知道RadonDB如何處理上述問題我們得首先了解一下它的整體架構。
第一眼看上去除了多出了計算節(jié)點(Compute Nodes)，整個架構和一般的分庫分表中間件+MySQL沒什么太大的區(qū)別。但實際上里面的很多設計細節(jié)很值得玩味，具體如下：
Ø SQL節(jié)點(SQL Node)
SQL節(jié)點(SQL Node)，負責一些如分布式執(zhí)行計劃和分布式事物協(xié)調的工作，因此一般的DML操作都具備了分布式事物保證，不過DDL沒有提供類似的保障。
當然DDL操作一般變更頻率不高，同時小概率失敗(可手動重試)也并不影響業(yè)務，DBA在使用上進行控制即可。需要提醒的是為了保障分布式事物Snapshot隔離級別，SQL節(jié)點只有一個對外提供寫，其他節(jié)點只讀。
更重要的一點是每個SQL節(jié)點存儲了一份表(table)存儲分布的元數據，借助元數據信息可以很方便的進行后端存儲節(jié)點的數據遷移操作(有點類似mongo的balance功能)。SQL節(jié)點之間會相互進行通信交換元數據的變化信息，通信協(xié)議類似于redis cluster 采用的當前流行的gossip協(xié)議。
Ø 存儲節(jié)點(Storage Nodes)
存儲節(jié)點(Storage Nodes)，實際上直接使用的是MySQL5.7(其實也兼容5.6+GTID)的默認三個節(jié)點的N組(N>=1)主從集群結構。不過這里引入了與mongo類似的raft(分布式一致性協(xié)議)協(xié)議來進行自動高可用切換。RadonDB的raft協(xié)議實現主要是基于GTID日志，因此RadonDB要求必須開啟GTID復制模式，同時為了提供金融場景下的數據強一致性保障，RadonDB要求采用強semi-sync+永不超時機制。在實際的使用中DBA自己可以依據不同的場景進行不同的配置。
Ø 計算節(jié)點(Compute Nodes)
計算節(jié)點(Compute Nodes)，這個設計讓人眼前一亮，之前也設計過分布式proxy Atlas，當時一直為高并發(fā)查詢與跨物理節(jié)點的復雜查詢并存時的性能問題頭疼不已。實際上SQL節(jié)點會對請求SQL進行解析，并決定哪些是復雜SQL，然后將對應請求路由至計算節(jié)點。
需要注意的是計算節(jié)點存儲的是所有Storage Nodes集群的全量數據，并且內部通過基于binlog訂閱-消費模式來對數據進行增量更新。值得一提的是計算節(jié)點采用插件模式，也就意味著計算節(jié)點不一定非要是MySQL，也可以是其他類型的DB。當然計算節(jié)點因為存儲的是全量數據，雖然當前采用壓縮存儲不過也有較大的存儲空間代價。
數據均衡
介紹完RadonDB整體架構，個人對它的表存儲設計和數據均衡印象深刻。通常的關系型數據庫的拆分或者常見的開源proxy一般都是沒有解決不同分片數據均衡的問題，而RadonDB提供了一個新的解決思路，表存儲策略具體見下圖：
從上圖可以看到在RadonDB里創(chuàng)建一個以id作為分片key的表t1，表t1會默認被自動切分為32張小表，它們均勻的分散在多個存儲節(jié)點上。每個小表都有一個自己的哈希區(qū)間，用于標識自己所能存儲的HASH范圍。通過交流發(fā)現，實際上這種拆分方式借鑒的就是redis cluster slot的存儲分配策略。這樣切分的最大好處就是即使一張100GB+的邏輯表，實際上在集群節(jié)點的存儲會被切分成很小的多張表，這對于維護和數據遷移還是比較優(yōu)雅的。
接下來我們看一下RadonDB是如何進行擴容，或者說數據均衡的，具體遷移過程也可以用如下圖來說明：
綠色框里表示添加一個分片后數據的分布情況，實際上RadonDB會通過基于Go語言自研的shifter工具(源碼尚未開源，以工具方式提供使用)進行并發(fā)式全量+增量的同步，當然為了盡量減少遷移的數據量，RadonDB會優(yōu)先以小表進行遷移。不過這里有一個問題需要注意，在遷移最后路由切換那一刻，原表需要一個只讀狀態(tài)，這期間對于業(yè)務來說可能會有一個瞬間的小抖動。
總結
總體來說，RadonDB實際可以理解為是一個中間件，并結合了當前流行的分布式一致性協(xié)議(raft)和通信協(xié)議(gossip)以及MySQL實現的一套分布式解決方案。
它解決了DBA一直面臨的關系型數據庫分布式事物、分布式模式下數據均衡、高可用切換、數據一致性及分布式模型下復雜查詢性能等一系列問題。
不過在體驗過程中也發(fā)現一些可以改進的點及實際使用建議。具體如下：
1。 分片擴容數據遷移采用的是全量+增量的方式，是否可以類似mongo的那樣直接在分片之間進行數據同步而無需dump，這樣的實現可能會更優(yōu)雅些。
2。 一般可能會推薦RadonDB采用vip模式來實現對業(yè)務的透明訪問，不過對于一般中小型企業(yè)并沒有穩(wěn)定可靠的lvs服務并且vip管理也是一個問題，這里建議使用服務發(fā)現或配置管理方案如開源的consul或360開源的qconf。
3。 部分自建私有云平臺可能因為之前對MySQL 5.5或5.6的技術定制高度依賴升級到5.7或后續(xù)的8.0難度較高，RadonDB可能是一個很好的契機或許可以一試。
RadonDB現已開源，希望RadonDB能給大家在MySQL運維上帶來不一樣的體驗，敬請期待吧~
免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。
