開源了！RadonDB分散式資料庫核心技術與實現詳解

導語：本文根據張雁飛老師在2018年5月10日【第九屆中國資料庫技術大會(DTCC)】現場演講內容整理而成。

張雁飛 Array | QingCloud 資料庫高階技術專家，TokuDB核心貢獻者、維護者，TokuDB企業級熱備工具作者。曾就職於阿里雲資料庫核心團隊，目前為青雲QingCloud資料庫團隊負責人，主導新一代分散式資料庫產品——RadonDB的設計與研發。

摘要：隨著資料規模的逐步擴大，儲存和運維成本逐漸增加，企業對資料庫的要求也逐漸提高。有人認為以MySQL為代表的傳統資料庫已經過時，不能滿足資料爆炸時代企業的要求;以NoSQL為代表的新型資料庫仍有侷限性，不具備ACID特性，很難滿足企業對核心業務資料的嚴苛需求。此次分享的RadonDB是一款將分散式一致性協議Raft與MySQL相結合的新一代分散式關係型資料庫。RadonDB的最大特點是結合兩類資料庫的優點，讓DBA無縫地從傳統的、單機時代的MySQL過渡到雲原生的、無限擴充套件的分散式關係型資料庫。

　　分享大綱：

　　1、 可擴充套件

　　2、 高可用

　　3、 強一致

　　4、 易部署

　　5、 MyNewSQL

RadonDB架構圖

RadonDB定位是新一代分散式關聯式資料庫，在今天這個雲端計算快速發展的時代，我們更願意稱它是一個雲原生資料庫，雲原生資料庫的天然屬性是分散式、可擴充套件、高可用、強一致。下面的MyNewSQL，是因為我們把MySQL和NewSQL融合起來，來滿足以上的幾個特性。

這是RadonDB的架構圖，我們可以看到，主要分上下兩層，上層是一個分散式的SQL層，它由多個SQL節點組成，負責使用者請求和申請分散式的執行制定計劃。下層是儲存層，這個儲存層與其他NewSQL不一樣的地方是，我們用的MySQL，可以看每個虛線框裡都是三副本的MySQL。它們之間的高可用，我們使用了NewSQL裡面比較流行的Raft一致性演算法。這個後面會有詳細的介紹。右下角是一個計算節點，這個稍後也會介紹，這就是RadonDB整個的架構圖。

Distributed SQL

下面，看一下分散式的SQL層，SQL層的職責可以看下面這個圖。

當中一個請求到來之後，SQL層會把這個請求解析成分散式的執行計劃，然後，把這個SQL在後端的儲存層並行的執行。而且它還會進行二次運算，就是Orderby/limit/groupby/aggration/join….等等。它還是一個無中心化的設計，部署起來比較方便，容易擴充套件，這是整個SQL層的一個設計。

Storage Nodes

再看儲存層，儲存層是RadonDB裡一個比較新穎的設計，也是我們定位為在新一代分散式資料庫的一個原因。

儲存層，每個副本都是一個MySQL，因為MySQL不光有計算能力，還有儲存能力。如果單單是一個KV的話，計算能力就比較弱一些，這是我們目前儲存層使用MySQL的一個考量。整個儲存層，由多個儲存節點組成，每一個儲存節點都是由三副本的MySQL組成，副本是通過Raft協議進行選主，然後再結合MySQL的自身的一套機制完成高可用。

副本高可用

接下來，我們看一下副本高可用。副本高可用其實有幾個比較大的挑戰。

　　第一個挑戰，怎麼快速選主?

　　第二個挑戰，選出新的主後，資料怎麼快速地回放?

　　第三個挑戰，資料回放完，資料怎麼保證不丟失? RadonDB是怎麼解決的?

對於第一個挑戰，我們使用了Raft協議，大家要知道，Raft協議主要幹兩件事，第一個就是選主，第二個是資料同步。在RadonDB裡只使用Raft進行選主，當主掛掉之後，我們使用Raft選出新的主，然後資料同步。我們是基於MySQL原生的FGTID機制和並行複製這些特性進行快速回放。

保證資料不丟失，我們還是基於MySQL，並使用了MySQL的Semi-Sync機制，當使用者寫到主副本時，首先，它要到達一個從副本，從副本收到之後，再反饋給客戶端，這樣就時刻地保證了一個從副本與主副本的資料完全一致，從節點被選入新的主節點，保證了這個資料不丟失。

當選入新的主節點之後，RadonDB的Log 並行複製還是基於MySQL的機制，並行複製，快速地回放，這就等於實現了把Raft選主和Log 並行複製結合。原生態Raft協議裡這兩個，Raft Log並行回放是比較困難的，但是，我們結合MySQL就很好地完成了。而且，這三個副本是一個無中心化的設計，只要我們可達，它的部署比較靈活。

擴容

RadonDB的底層是全部基於MySQL，所以在擴容的時候也比較方便，因為MySQL有一套工具和機制。

在RadonDB裡，每一個大表被分成了很多個小表，這樣，我們優先擴容小表，會選一些熱度高的小表進行漂移，漂移的機制是先全量，全量時，我們記住當時的一個位點，就是MySQL裡Binlog位點，全量之後，我們再追這個增量，也是基於(GTID)這種機制。這樣，前端業務基本上沒有影響的情況下，完成了小表在物理機之間的動態漂移，當然你也可以制定一些規則，比較靈活。

分散式事務

RadonDB支援分佈事務，還是基於MySQL原生XA機制來完成的。所以，大家可以看到RadonDB這上面能力跟MySQL很好地結合起來。

大家可以看到上圖，其實MySQL Xa機制總共有5個步驟，但是到RadonDB裡，我們進行了抽象，就是進行了封裝。我們實現了快照的隔離級別，實現了Snapshot Isolation事務隔離級別。

Binlog

另外，RadonDB支援Binlog，大家可能認為一個分散式資料庫，就是裡面需要放一些海量的資料，但資料一旦進入你的分佈資料庫，怎麼能出來?就比較麻煩，因此， RadonDB提供一個Binlog機制，就是讓資料能快速的同步處理。

OLTP + OLAP

比如說，我們有一個OLAP的叢集，可設定為RadonDB的Binlog，Binlog是實時地更新，這就完成了一個異構化的過程和資料流出，而且是實時的。

大家也看到，在剛才的架構圖裡，右下角有一個計算節點，其實，我們的計算節點就是通過這種機制跟RadonDB的資料進行同步。這樣，就把OLTP和OLAP結合了起來，當使用者一個比較複雜的查詢到達RadonDB之後，RadonDB會根據SQL的模式發到TP節點還是AP節點，前端的使用者是沒有感知的，這就做到了一些資源的隔離。當然了，這也有一個缺點，資料可能是兩份，但目前，我們是通過異構化、列式儲存來進行的，高壓縮做這種機制。

審計日誌

另外，RadonDB還提供了一些審計日誌這些功能，為了方便大家對業務進行一些審計，而且審計機制還可以定位一些慢查詢SQL，因為分散式的資料庫，節點比較多，所以定位一個SQL會比較複雜，有了審計日誌，大家可以定位一些慢的SQL。

備份和恢復

RadonDB提供了一整套備份和恢復的工具，可以讓使用者快速地把資料流進去，流出來，比原生的要快很多。

效能

這是我們做的一個新的對比，可以看到，RadonDB在四個節點跟單機的MySQL的一個對比，基本上，效能是單機的三倍，但延遲只是1/3，效能明顯提升，這就是分散式資料庫的威力。而且這個效能基本上是可以橫向擴充套件的。

RadonDB還提供了一些可呼叫的引數，讓外面的監控可以很好地呼叫，這是RadonDB比較靈活的一個地方，可以根據定製讓前端或者產品線呼叫。

監控

另外，RadonDB提供了一個全鏈路的監控，通過它，分散式就不再是個黑盒子。

　　mysql> show processlist;

　　第一條命是，MySQL常用的，表示使用者的連結到RadonDB的狀態。

　　mysql> show txnz;

　　第二個命令是，分散式事務在哪個階段執行，耗時多少，這個都可以很清楚地看到。

　　mysql> show queryz;

　　最後一個命令，具體哪些子句落到哪些節點，甚至耗時多少，比如說，某個節點有一些問題，都可以從這個上面反映出來，比較靈活。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11310314/viewspace-2154529/，如需轉載，請註明出處，否則將追究法律責任。