對分布式數據庫感興趣的朋友都知道，谷歌的 F1 和 Spanner ***了 NewSQL 技術的發展，于是很多公司去做 NewSQL，導致好多人認為基于 MySQL 的分布式數據庫過時了。

其實不然，MySQL 并沒有過時，本篇文章的主角 —— RadonDB ，就是把 NewSQL 領域比較流行的分布式一致性算法和 MySQL 結合起來，形成了新一代的分布式數據庫 MyNewSQL，同樣做到了可擴展、高可用、強一致、易部署的特點。

那么，如何將 NewSQL 領域比較流行的技術和 MySQL 結合起來，打造一款新的分布式數據庫？

1、RadonDB 的架構

首先看一下 RadonDB 的架構，如上圖所示，上半部分是分布式的 SQL 層，下面是存儲層，如果我們對 F1 和 Spanner 進行抽象之后，會發現也都是這兩層。

其中 SQL 層主要負責對用戶 SQL 解析，然后生成分布式的執行計劃和執行器，再把這些執行器下發到具體的存儲節點去執行。

雖然架構看上去比較一致，但 RadonDB 比較特殊的一點是：下面的存儲層有多個存儲節點。圖中每個圓圈里面都是一個存儲節點，每個存儲節點有三副本，三副本之間就是一個 Raft 協議進行數據同步，每個副本都是一個 MySQL。而其他 NewSQL 就是一個 KV 或者其他的存儲。

2、RadonDB 架構層解析

下面詳細闡述一下架構里面的各個技術點。

SQL 節點

首先來看一下 SQL 節點。

用戶請求到達 SQL 節點后，我們根據數據的分布規則生成一個分布式的執行計劃，告訴用戶的 SQL 要分發到哪些存儲節點，然后根據分布式執行計劃生成一個分布式的執行器，就是具體到哪些存儲節點進行鏈接、執行、返回。

執行完之后 SQL 節點就會做二次運算，為什么叫二次運算？因為下面是 MySQL，SQL 節點把計算推到 MySQL 之后，SQL 節點再進行二次運算，包括 limit/groupby/aggregation/join。

所以說，SQL 節點是一個無中心化、無狀態的，擴容性強。

3、存儲層

存儲層由多個 Node 組成，每個 Node 就是一主兩從的 MySQL，但這個 MySQL 比較特殊，因為 MySQL 沒有一個高可用的方案，可能大家都是 MHA 或者自己寫一個主從切換腳本來運維。

但是 RadonDB 引入了 Raft 協議，它是無中心化的， 當主庫掛了后，通過 Raft 協議選擇新主，而數據同步則基于 MySQL GTID 機制。

基于 MySQL 的好處是不僅有存儲能力還有計算能力，如果一個副本只是一個 KV ，他的計算能力就比較有限，SQL 層把數據推到存儲層，然后再返回 SQL 節點再進行運算，這樣存儲層和 SQL 層交互就會比較多。

我們盡量把計算能力下推到存儲層讓 MySQL 完成，因為 MySQL 跟數據是在一塊的，不涉及網絡傳輸，只需要幾個 I/O 就將數據過濾掉了。

4、數據分布

剛才說了 SQL 層和存儲層，再看一下數據怎么分布？

建一個 T1 表，后面指定的分區方式是 HASH，在 RadonDB 里面默認整張表共 4096 slots， 每個小表默認是 128 slots， 其實就是一個大表分成 32 個小表，比如兩個存儲節點，這個 T1 表的 32 個小表，前 16 個小表在***個存儲節點上，后 16 個小表是在第二個節點上，是均分布的。

可能很多人認為基于 MySQL 擴容是個問題，但是如上所說，表分完之后，RadonDB 以小表為單位做數據遷移，所以擴容非常方便。如果是加了一個新的節點，RadonDB 就會把動態的一些小表遷移到新的節點上，因為我們是基于 MySQL 做的，首先會做一個全量，然后把位點記下來，等全量做完再追增量，這個遷移過程基本不影響業務了。

所以這樣每個小表就可以在多個存儲節點上動態的漂移。這些遷移規則也可以進行自定制，比如說先遷移較大的表或者熱度比較高的表，讓整體資源分配最快達到***化。

5、如何保障高可用？

一個存儲節點內三個副本怎么保證高可用的？我們將分布式一致性算法 Raft 和 MySQL 自身的 GTID 結合起來。

Raft 主要做兩件事，一個是選主，第二個是數據同步。MySQL 5.7 GTID，類似于 Raft 里面的一個 log index， 數據同步是通過 GTID，選主是通過 Raft，我們開發了一套 Raft 框架，實時監測 MySQL 狀態，如果主不正常了，就發起重新選主。

選完后新主與其他兩個從庫數據怎么同步呢？兩個從根據自己的 GTID 向主那去拉數據，進行數據同步。MySQL 5.7 可以并行復制，過程非常迅速，主從基本沒有延遲，在高壓情況下延遲也非常小。而且，通過比較強的 semi-sync 確保事務不丟失。

存儲節點里 Raft 和 GTID 是沒有中心化的，可以跨機房部署，非常靈活。

6、分布式事務

下面看一下分布式事務，為什么分布式數據庫需要分布式事務呢？

因為數據在存儲節點是分布式存儲的，比如說一個表在節點 1、節點 2、節點 3 都有存儲，然后執行了一個操作，在節點 1 成功了，在節點 2 失敗了，節點 3 成功了。這時如果沒有分布式事務，那這個表其實是壞的。

如果沒有分布式事務保證的話，數據隨時都處于不可用的狀態，只能用來存不重要的業務。

所以 RadonDB 就提供了分布式事務，比如說剛才這個情況，就是 2 失敗之后，這個 1 和 3 存儲節點自動回滾，這是分布式事務保障。

RadonDB 分布式事務也是基于 MySQL 實現的，在 MySQL 里面分兩階段提交。

首先它會做 xa start，然后執行 SQL，做 xa end，第四做 xa prepare，這是***階段，此時事務才會從副本復制過去；第二個階段是 xa commit。

所以 RadonDB 在 SQL 層進行了事務管理，把 MySQL 的五個步驟抽象成三個，***是 Begin，第二是執行，第三是提交，如果 Prepare 失敗，可以進行 Rollback。

提到分布式事務，大家可能會問，這個事務是什么隔離級別？

RadonDB 實現 Snapshot Isolation 也就是快照隔離級別，這是個什么概念呢？當部分分區沒有提交時，這個事務對其他事務不可見，這就是部分提交不可見。另外就是未提交不可見，也就是說做了 prepare，但沒有 Commit，那也是不可見的。

7、SI 隔離級別

大家可以看一下上圖右邊兩個 SQL 語句，兩個 Client 連上來，一個 Client 是掃表，第二個 SQL 語句就是不停更新這個表。

對于 SI 隔離級別我們用了 XeLabs/go-jepsen ，1 個更新線程，16 掃表線程，通過 100 多億次操作和監測沒有發現問題，并且可以隨機 KILL 存儲節點主副本，這些都證明 MySQL XA 已經很強大了。

RadonDB 還支持 HTAP 混合模式，在傳統的解決方案里，一般都是兩套系統，就是兩個端口。在需要事務和需要分析的時候，分別在兩個端口處理，中間通過ETL通道進行數據同步。

但是，在 RadonDB 里就一個端口，如果是 OLAP 的操作，我們會自動路由到計算節點，而且 OLTP 和 OLAP 這兩個計算的資源是隔離的，互不影響。

8、性能

***看一看 RadonDB 的性能。上圖是單機 MySQL 和四個存儲節點的 RadonDB 的對比。

我們用 sysbench 16 個表、512 個線程，隨機寫了 5000 萬條數據，測試得出來的結果，RadonDB 基本上可以做到 26589 TBS，單機是 9346 TBS，可以看到在 TBS 層面 RadonDB 性能將近是單機的三倍，延遲卻只有的三分之一。

這就是分布式數據庫的威力，性能和容量可以通過節點的增加而線性增長。

作者簡介

[[231783]]

張雁飛，青云QingCloud 數據庫高級技術專家。TokuDB 內核貢獻者、維護者，TokuDB 企業級熱備工具作者。