開源分布式數據庫RadonDB的核心技術與實現是怎樣的

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

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進行存儲，表、數據結構都可以是異構的，性能上也有很大的提升。

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