共計 4653 個字符，預計需要花費 12 分鐘才能閱讀完成。

開源分布式數據庫 RadonDB 的核心技術與實現是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面丸趣 TV 小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

RadonDB 是一款將分布式一致性協議 Raft 與 MySQL 相結合的新一代分布式關系型數據庫，兼具 NewSQL 和 MySQL 兩類數據庫的優點。下面將從架構、執行、高可用等角度，結合開源代碼為大家深度解析 RadonDB 的核心技術與實現。

RadonDB 是一個開源的分布式數據庫。為什么叫 RadonDB 呢?RadonDB 中的 Radon 出自元素周期表，是一種惰性氣體，名字叫做氡。因其化學性質比較穩定，所以我們就以此來命名了這款數據庫產品。

RadonDB 包含兩個部分 Radon 和 Xenon，并不是一個簡單的數據庫中間件。其中，Radon 類似于一個數據庫中間件，而 Xenon 是一個高可用的 MySQL 管理集群工具。

上圖是 RadonDB 的整個架構圖，其中最上面一層是 Radon，一個分布式的 SQL 層，負責 SQL 的解析和轉發。這一層就是大家說的數據庫中間件，它會根據用戶請求將 SQL 語句生成分布式執行計劃，并推到下面的存儲層。

下面這一層是 Xenon，一個高可用的 MySQL 管理工具。在這一層的每個虛線框里都是一“主”兩“從”的 MySQL，都通過 Xenon 進行管理。Xenon 其實是一個無中心化的管理工具，當主節點掛了之后，會使用 Raft 協議進行選主，選出新的“主”之后，再根據 MySQL Binlog 這些機制進行數據同步，從而使新的主節點繼續對外服務。

下面咱們聊一聊 RadonDB 的一些技術細節。RadonDB 的主要功能是對用戶 SQL 生成分布式計劃以及執行器并行執行，當執行器下發到存儲層以后，進行 ORDER BY、LIMIT、GROUP BY 等二次運算。

Radon 支持集群模式，所以基本上是無狀態的。當其中一個節點掛了之后，其他節點可以很快的遷移過去，保證 Radon 這一層的高可用。

如果從代碼層面來看 Radon 的具體工作流程，用戶 SQL 到達 Radon 之后，query.go 文件會對 SQL 進行語法樹的生成，生成之后根據 SQL 的類型進行處理。

首先，根據語法樹生成分布式的執行計劃。分布式的執行計劃是根據路由表查找每個具體的數據分布在哪些后端，然后生成具體的子句。

分布式執行計劃生成之后，就運行 Insert executor 文件，并下發到相應節點去執行。

以上，就是 RadonDB 中 Radon 這一層的基本工作機制。

Radon 這一層還有一個比較重要的功能——分布式事務。Radon 分布式事務是基于 MySQL 原生事務——XA 事務來進行的。MySQL 的 XA 事務在執行時可分為五個階段：第一個階段是 XA START，第二個階段是 SQL 執行，第三個階段是 XA END，第四個階段是 XA PREPARE，這個階段其實數據已經通過 Binlog 傳到了備庫，即使主庫掛了，重建之后事務仍然處于 XA PREPARE 狀態，我們可以認為數據不會丟失。最后一個階段是 XA COMMIT。

RadonDB 對這五個階段進行了分工，共分成 begin、execute、commit 三個階段。

RadonDB 實現了 SI 隔離級別的分布式事務。Radon 里有一個 Commit Lock，如果不加這個鎖是實現不了這種隔離級別的。那么什么是 SI 隔離級別呢?SI 是 SNAPSHOT ISOLATION 的縮寫，它的作用是未提交的不可見，例如有三個分區，當它們都沒有 XA commit 時，其它事務讀的時候是看不到未提交事務的數據。另一個作用是部分提交不可見，還是有三個分區，第一個分區 XA commit 了，其他兩個分區正準備 commit，這時候如果有其他的客戶端讀數據也是不可見的。

為了檢測 XA 的隔離級別，我們研發了一個開源工具，它的思路比較簡單，就是一個更新線程不停地去更新，16 個掃表線程不停地掃表。如果分布式事務滿足不了 SI 隔離級別，那么 16 個掃表線程就有可能看到更新線程的部分數據。

我們進行了 100 多億次操作和檢測的測試，并且過程是隨機的。我們會把存儲層的主節點宕掉來做“主從”切換。在大量的測試中，目前還沒有發現讀取到部分數據的情況。

下面介紹一下 RadonDB 的另一個組件——Xenon，一個高可用的 MySQL 管理工具。假設一個節點有一“主”兩“從”，三個 MySQL，那么它們之間的高可用怎么來實現呢?

Xenon 的工作機制是和 MySQL 配合，通過 MySQL 鏈接不停地去 ping MySQL，并拿到 MySQL 的信息。一個 MySQL 對應一個 Xenon，并部署在一個 container 里，一“主”兩“從”分布在不同的 container 里面。當 Master 不可服務時，其他的 Xenon 會檢測不到 Master 發來的心跳，這時由 Xenon 發起的心跳會發起選主操作，進而其他的從節點會被選為新的主節點。

接下來，我們講一下 Xenon 如何發起選主操作、如何選擇新的主節點以及選完之后如何保證數據不丟失?

對于一“主”多“從”的 MySQL 集群想要做到高可用有幾個挑戰：第一是如何選“主”; 第二是選“主”之后，數據怎么跟原先的 Master 進行同步，保證數據不丟失; 第三是如何盡快選“主”，當原來的“主”掛了之后，新的主節點如何盡快應用數據，并對外提供服務。

我們把 MySQL 的 GTID 和 Raft 的選主結合了起來。Xenon 主要實現了 Raft 選主功能，結合 MySQL GTID 實現高可用。了解 Raft 算法的朋友可能都知道，Raft 主要做兩件事，第一件就是選“主”。第二個就是 log 同步。Xenon 選“主”使用了 Raft 選主協議，選“主”之后會結合 MySQL GTID 進行數據同步。

如果是一“主”兩“從”的節點，那么這兩個從節點哪個被選為新的主? 這里結合了 MySQL 的 GTID 和 semi-sync。當我們把 semi-sync 的 vote_timeout 設置為無限長，基本上就可以認為是“主”。寫完之后，至少有一個“從”會收到，然后返回給“主”，“主”再返回給 cluster，這樣保證至少有一個“從”和“主”的數據是完全同步的。當“主”掛了之后，和主節點數據完全同步的從節點會被選為新的主節點，之后根據 MySQL 的并行復制，快速回放，并對外進行提供服務。

介紹完 Radon 和 Xenon，我們看一下，數據在 RadonDB 里面是怎么分布的?RadonDB 的底層存儲基于 MySQL，也就是說由 Xenon 管理的一主兩從是一個節點，整個存儲層是由多個這樣的節點組成的。

用戶創建一個表的時候需要指定一個分區鍵，RadonDB 會根據分區鍵把整個大表分成 32 個小表。分配規則是這樣的，整個表有 4096 個槽位，其中每個小表是 128 個槽位，共有 32 個小表。

RadonDB 的最小單位就是小表，命名為 T1_0000 到 T1_0031，每個小表都是占 128 個槽位，例如第一個小表是從 0 到 127。這樣當用戶在做 Insert 時，就可以依據此判斷數據會落在哪個小表里。

RadonDB 如何做擴容呢?RadonDB 最小單位是一個小表，但 4096 和 128 這兩個數字是可以配置的。在擴容上，RadonDB 可以讓小表在不同的機器間動態漂移。因為是 MySQL 表，所以把小表從一個 MySQL 實例上飄到另外一個 MySQL 實例比較簡單。首先是做一個全量遷移，記下當時遷移的位點，然后再對增量進行追加。這種以小表為遷移的方式不但不影響讀寫操作，而且操作方便，既可以擴容，還可以縮容。

RadonDB 還支持 Binlog，為什么? 因為 RadonDB 是一個分布式數據庫，如果有別的數據庫或數據想訂閱 RadonDB 數據，那么就可以訂閱 RadonDB Binlog。連上 RadonDB 之后，執行 SHOW BINLOG EVENTS，指定從哪個 GTID 開始，同時還可以指定訂閱多少條。這樣就可以把 RadonDB 數據實時的導入到異構的數據庫里。

如果 RadonDB 收到了比較復雜的 AP 操作，例如 JOIN，它的機制又是怎么樣的呢?RadonDB 還有一個計算節點，當用戶 SQL 上來之后，RadonDB 如果發現里面有比較復雜的 JOIN 等 AP 操作，會自動的把這個請求路由到計算節點上。

計算節點是插件式的，它可以是其他比較強大的 AP 分析型數據庫，計算節點把結果計算完之后，RadonDB 會自動的反饋給客戶端，在這種情況下，客戶端是無法感知到這些操作的。

這樣做的好處是事務型和計算型是資源隔離的，但缺點是存儲需要兩份。如何克服缺點呢? 其實目前我們也沒有很好的辦法，只是通過壓縮暫時的解決了這個問題。

RadonDB 還實現了審計日志功能，當用戶的請求到達 RadonDB 之后，RadonDB 把用戶請求記錄到本地磁盤上。我們可以通過上圖中的多個維度進行審計，同時還可以查詢慢操作。當日志請求量比較大時，RadonDB 會定期進行清理。同時 RadonDB 還支持多種審計模式，例如只讀審計、只寫審計、讀寫審計等等。

大家可能會比較擔心分布式數據庫灌進了大量數據就很難導出來了。針對這種情況，RadonDB 提供了導入和導出的工具，這些工具是并行式的，導入 / 導出的速度比 MySQL 原生的 Mydumper 還快。

RadonDB 提供了全鏈路的監控，如果分布式數據庫是一個黑盒，那么出了問題就很不容易排查。RadonDB 從前往后做了三層監控，第一層就是 show processlist，這層是監控用戶到 RadonDB 的連接，跟 MySQL 是一樣的。其中 RadonDB 實現了一個序列表，這一層的作用就是可以看到 cluster 到 RadonDB 執行的 SQL 語句。第二層是監控 RadonDB 內部峰值事務執行到哪個階段，大家可以通過 show txnz 命令進行監控; 最后一層就是 show queryz，這個命令可以看到具體的子句在哪些后端執行。

通過這三層監控就可以很快的定位到具體問題，比如一個慢 MySQL，它到底是慢在哪些地方。

上圖是性能對比表，上面的 RadonDB 是四個存儲節點，下面是單機 MySQL。大家可以看到，RadonDB 的性能基本上是單機的三倍，而延遲基本上是 1 /3。為什么會出現這種情況呢? 這就是分布式的威力。假設我們有一個 1TB 的表，如果使用單機數據庫，那么 Btree 會比較高，而且每次請求的 IO 深度路徑也會比較長。而 RadonDB 會把 1TB 的數據分成四個節點，假設平均每個節點是 250G，每個節點還有細分每個小表。當用戶請求時，我們只需請求小表，而且 RadonDB 對所有的請求都是并行執行的，時間完全取決于最慢的小表。所以在這種設計中，RadonDB 的性能基本上會是單機的三倍，而延遲是 1 /3。

最后說一下 RadonDB 的展望，大家都了解類似于 Google Spanner 這種 NewSQL 會是一個大趨勢，而且很多公司也都在完全自主研發 NewSQL。有人都認為傳統的基于 MySQL 分庫分表的方式已經過時了，而我們提出了一個新的概念——MyNewSQL，就是 MySQL 和 NewSQL 相結合。

其實 RadonDB 就是一個 MyNewSQL，它把 NewSQL 領域里常用的算法都拿到了 MySQL 里，從而實現了 MyNewSQL。RadonDB 最后實現的功能和 NewSQL 基本無異，但它是基于 MySQL 進行存儲，表、數據結構都可以是異構的，性能上也有很大的提升。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注丸趣 TV 行業資訊頻道，感謝您對丸趣 TV 的支持。