朱曜鑫：阿里巴巴第四代資料庫架構最佳實踐

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

朱曜鑫 阿里巴巴 資深資料庫工程師

8年阿里資料庫團隊工作經歷，踐行阿里巴巴兩次資料庫體系升級；阿里巴巴2017年度資料庫技術總負責人，成功組織實施了17年大促支援工作，落地阿里資料庫團隊新一代技術體系思考。

摘要： 阿里資料庫架構體系的演進路線和思考過程；我們為什麼選擇X-DB，新體系結構在實踐中如何為業務賦能；X-DB 的技術優勢和典型業務場景介紹；新技術體系演進過程中的經驗介紹。

分享大綱：

雙十一業務場景

阿里第四代資料庫概述

X-DB生態的組成

X-DB 高可用的核心：XPAXOS

X-DB高效能的保證：XEngine

使用者態檔案系統

未來已來

正文

雙十一業務場景

雙十一是一場人為創造的技術熱點，對於阿里來說意義至關重大。無論是一年的銷售額還是交易建立高峰都是以指數級別的趨勢在增長，這對於阿里的技術來說是一個很大的壓力，當然也是因為這樣的壓力，不斷的推動阿里技術體系創新發展。

在雙十一接近零點的時候，消費者最關心的是自己的購物車，等待時機進行購買。對於阿里來說，最關心的是這一條交易建立曲線，因為對於技術人員來說，它的走勢就決定了雙十一的成敗。

那麼什麼才是一次完美的雙十一呢？2017年的雙十一就是一次完美雙十一。2017年雙十一的交易建立曲線，從零點那一刻開始幾乎直線上升到32.5萬每秒，並且在這個區間上平穩執行，當購物結束時便開始緩慢下降。如果雙十一時刻曲線並沒有直線上升，或者中途突然下降，那麼就證明我們的交易系統出現問題。

2018年的雙十一又將建立一個什麼樣的高峰？我們怎樣保證跟去年一樣完美？對於阿里來說，又將是一場新的挑戰。

阿里資料庫體系的演進

經過九年雙十一的磨練，阿里資料庫體系不斷演練。2005年—2010年，是阿里集中式Qracle時代，但是經過發展，該系統逐漸不能滿足業務需求。所以阿里進入到第二個時代——分散式儲存，我們轉向了開源技術，使用MySQL，並且透過分庫分表的方式讓資料庫可以做到水平擴充套件。但是後來發現這也不是一個一勞永逸的方式，我們的業務在持續增長，機器數量不斷增多。比如，突然間宣佈杭州電力供應不上，在用電高峰期，為了保證居民用電，必須限制阿里機房用電，這便遇到了城市資源限制問題。因此我們不得不進入第三個時代——異地多活。我們在全國多個城市建立交易單元，每個交易單元都可以獨立對外提供服務，而且為了做到容災，單元之間進行資料同步。透過這樣的方式，一個城市的資源不在成為限制業務發展的瓶頸，同時我們也擁有了MySQL分支——AliSQL。在此基礎上我們做了很多改進，效能得到很大提升。另外，我們還可以針對特定的業務場景進行快速開發。

第三代資料庫架構支撐了阿里好幾年的雙十一。今天，業務給我們重新提出了要求，業內的一些技術發展方向也給我們帶來了很多思想上的碰撞，我們開始思考這樣幾個問題：首先，阿里的國際化業務最近都在高速增長，我們需要在全球各個地方進行部署，但是面對全球複雜的網路環境，我們怎樣能保證資料傳輸的效能以及資料的一致性？其次，經過這些年阿里在開源技術上的積累，我們對資料庫底層的把控能力也逐步增強，我們是否可以透過自研的方式把最新的軟硬體技術進行結合，實現資料庫資源利用率最大化？最後，我們如何實現更精確的成本控制，透過採購少量機器，扛過雙十一零點的壓力高峰？

為了解決這些問題我們進入了第四個時代——X-DB生態，並且X-DB在2017年的雙十一當中透過了考驗。

   回顧整個歷程，其實就是阿里的資料庫體系從閉源走向開源再走向自研的過程。那我們第四代的資料庫到底是一個什麼樣的資料庫呢？

阿里第四代資料庫（X-DB）概述

X-DB名字由來：X代表數學領域的未知，象徵潛力無限一切皆有可能！

我們認為資料庫從一代進入到下一代必須有一個數量級的提升，所以我們給X-DB定了兩大目標：寫入效能提升一個數量級達到百萬TPS；成本下降一個數量級做到原來的十分之一。

第一，X-DB要全面相容MYSQL，以便讓更多的業務和應用接受X-DB。第二，實現高可用，X-DB要有內部機制可以實現資料庫異常當機後的快速切換，而不需要依賴第三方的HA軟體。同時它要克服複雜的網路環境做到全球化部署，並且保證資料一致性。第三，實現高效能，即效能提升一個數量級。第四，實現高擴充套件，包括容量上的擴充套件和效能上的擴充套件。X-DB可以從單機部署擴充套件到叢集部署，透過這種靈活的伸縮性可以快速的調整資料庫架構，從而做到對成本的精確控制。

X-DB生態的組成

X-DB高可用的核心——X-PAXOS

X-PAXOS從名字可以看出，它使用了PAXOS協議。PAXOS協議可以說是目前所有分散式一致性協議的終結者，從它問世以來，業內一直都在對它進行研究，也產生了大量的文章和專案，但是真正能做到工業級別，而且是獨立PAXOS基礎的卻非常少。在這樣的背景下我們重新打造了一個工業級別的高吞吐的PAXOS基礎庫。作為一個基礎庫，X-PAXOS除了服務於X-DB以外，還可以賦能給所有的分散式系統。

X-PAXOS架構

為了實現一個單例項多執行緒的PAXOS，我們在服務層上加了通用的Worker。透過這些Worker，除了必要的協議序列點以外，絕大部分任務都可以併發執行。同時，對於部分協議序列我們採取了無鎖設計，儘可能的提高整個PAXOS的吞吐能力。

另外，日誌是保證PAXOS協議做到一致性的工程實現，日誌的寫入效能很大程度會影響到整個協議的寫入效能，所以我們重新開發了一個獨立的可插拔的日誌模組，它可以透過介面把自身的日誌跟PAXOS的日誌進行結合。

X-PAXOS部署形態

 X-PAXOS在Multi-PAXOS基礎上做了大量的改進，上圖是一個Multi-Region部署架構。

我們可以這樣去理解，region是城市，AZ是機房，這就成為了一個3D部署架構。首先，在滿足PAXOS協議的情況下，我們可以對這些副本數進行動態調節。其次，我們可以針對不同的業務需求動態的調整我們的同步策略。

另外，我們重新定義了角色， Loger就是我們對其中的一個狀態機進行了裁剪，它只接收日誌不儲存資料，但是它參與多數態時沒有被選舉權，這樣做的好處是什麼呢？在同城商副本部署的情況下，這樣的結構可以滿足PAXOS協議。同時因為Loger節點不儲存資料，所以我們可以節省成本。而且這個Loger節點還可以用於日誌流的備份，和日誌訊息的推送。

還有一個改動點是Learner，跟標準的Learner不一樣，這裡的Learner只負責日誌的接收、消費，並不參與選舉和投票。

最後我們實現了靈活的切換策略。當Leader不可用的時候，我可以優先切換到同城的Follower。如果整個城市都不可用，我們可以提前定義切換到哪個城市。

X-PAXOS效能最佳化

  Batching是把多個訊息合併成一個訊息進行傳送，減少中間重複的消耗。Pipelining是不等待上一個訊息的反饋結果，直接傳送下一個訊息，來提高併發度。

一般情況下，遠距離傳輸資料，會因為網路頻寬延時浪費時間，所以適合小Batching、大Pipelining。當近距離傳輸時，網路問題限制比較小，但封包解包可能會消耗系統資源，這時候便適合使用大Batching、小Pipelining。

因此，X-PAXOS做到了自適應的Batching和Pipelining，它會探測整個叢集不同節點的網路拓撲，根據它們的網路頻寬和延時結合我們自推導的最優解演算法，為每個節點定製不一樣的Batching和Pipelining策略。

但是Pipelining的引入會產生另外一個問題——日誌亂序。所以我們開發了一個高效處理亂序的模組，透過它來遮蔽底層日誌亂序帶來的影響，同時結合我們的非同步化併發提交加大我們在接收端的處理能力。

X-PAXOS效能表現

做完了這些最佳化之後，我們看一下效能對比：

X-DB vs MySQL 5.7 GR：

藍色是X-DB，橘色是MySQL。在同城Insert的場景之下，我們可以做到MySQL的2.4倍。

在跨城的情況下，這個差距會進一步的拉大，表現出了我們Batching和Pipelining最佳化後的效果。

X-DB高效能的保證——X-Engine

我們為什麼要重新開發一個資料庫引擎？基於這幾點：

1、近幾年國產硬碟發展迅猛，但是關係型資料庫卻沒有很大突破，所以我們希望透過自研的方式將最新的軟硬體進行結合，重新打造一個效能強大的資料庫引擎，來解決資源利用率為問題。

2、基於雙十一的交易壓力，我們需要一個寫入效能強大的資料庫引擎，同時也希望可以節約成本。

為了高效能低成本，我們開始自研X-Engine。它有兩大核心：資料自動冷熱分層和基於資料分層架構下的計算和儲存最佳化。

在高效能方面為了加大吞吐，我們會使用BatchGroup和 Pipeline Commit，為了減少鎖資源的爭用，我們會實現Lock Free和Latch Free以及自適應的併發控制和FPGA技術。在低成本方面我們會使用資料分成儲存、自適應的資料生命週期管理、行列混合儲存和針對不同的資料型別做到自適應的Encoding，以及使用壓縮技術。

X-Engine架構

X-Engine借鑑了LSM-tree的思想，即所有寫入資料不會直接修改已有資料，而是使用Copy onLayout的方式追加到MemTable裡面。

在資料儲存方面，會記錄資料的訪問熱度，把資料劃分為大小不一樣的Key-rang，存放在不同的資料檔案中。訪問熱度比較高的資料存放在高速的儲存裝置上，訪問熱度較低的資料儲存在比較廉價的儲存裝置上，並且進行壓縮處理。

在記憶體方面，由於X-Engine無論是讀還是寫或者是後設資料管理都使用MemTable，它對讀寫的吞吐效能要求很高，所以我們採用了Skiplist代替原來的B-Tree，這樣更容易實現lock-free減少鎖的爭用。

FPGA加速

使用LSM-tree的資料庫都存在一個問題，它們必須要對資料進行合併，即Compaction操作。Compaction很佔用系統資源，它可能會給一個高壓態的資料庫帶來抖動，甚至影響業務。所以，我們在X-Engine上引入FPGA異構計算晶片進行加速。

透過這兩張圖我們可以對比一下，在沒有FPGA的時候，相關的Compaction任務都會交由CPU執行；使用了FPGA之後，CPU只負責Compaction任務的生成和排程，真正執行資料合併的被Offload到FPGA加速單元去操作。

效能對比

藍色的是X-Engine-CPU，橘色的是X-Engine-FPGA。很明顯，X-Engine-CPU效能抖動比較大，而X-Engine-FPGA相對平穩。

這裡面存在一個很大的挑戰：我們要給FPGA設計一款適合做Compaction的併發流水線，以及透過容錯最佳化解決FPGA內部記憶體翻轉的問題。

如果把圖放大，我們還是會發現X-Engine-FPGA曲線也有效能抖動，這也是我們需要進一步最佳化的地方。

X-DB架構的演進

這是一個標準的應用訪問資料庫鏈路圖。不同於以前的是，我們把資料庫的計算節點從物理級換成了Docker容器。2017年，阿里巴巴資料庫實現了全網百分之百的容器化部署。

不同於其他應用，資料庫是有狀態的，僅僅依賴容器化無法解決資料庫彈性部署問題。所以，我們需要引用一個新技術——儲存與計算分離，把資料存放在分散式的儲存叢集上，透過高速的網路和RDMA技術把整個架構串聯起來。

優點：

1、  儲存容量不再受限於單機物理磁碟的大小。

2、  對資料庫進行擴容、縮容，不再需要遷移資料。

3、  實現了更精確的成本控制。

使用者態檔案系統

為了進一步提升儲存與計算分離的效能，我們開發了一個使用者態的檔案系統。透過這個檔案系統，我們繞過了原來Linux核心態的IOG系統，計算節點跟儲存節點可以直接透過RDMA進行資料傳輸。

一寫多讀

怎樣實現一寫多讀？

這是一個X-DB叢集，我們使用了儲存與計算分離，底層共用同一份資料。這裡面有一個寫節點和多個讀節點，由於X-Engine對資料的寫入不會直接修改後設資料，所以我們透過X-PAXOS把這些日誌同步到每一個讀節點，讀節點會應用這些日誌更新MemTable，再結合底層共用的sit檔案，就可以做到跟讀節點一致的資料。透過這種方式，我們就可以快速搭建一個一寫多讀的X-DB叢集。

Table Partition

光有讀的擴充套件能力也不能滿足業務需求，還需要有寫的擴充套件能力。在介紹寫的擴充套件能力之前，我先引入一個概念——Table Partition 。Table Family類似於分庫分表中的邏輯總表，Table1、2、3就是每一張物理值子表。在X-DB，我們還會將每一張子表分為多個Partition，並且有後設資料記錄Partition對應哪個MemTable以及資料檔案位置。

動態計算節點擴容

這個架構圖同樣是一個使用了儲存和計算分離的X-DB叢集。我們的應用透過X -DRIVER聯絡X-DB叢集，對於 Table Partition的分距資訊，有一份會存放在X –DRIVER。如果需要對Table Partition 1和2進行資料修改，它會被路由到第一個X-SERVER上，如果需要對Table Partition 3和4進行修改，它會被路由到第二個X-SERVER上，同時這些修改都會透過X-PAXOS同步到叢集的每一個節點。

那麼怎樣做寫節點呢？如下圖所示：

只需要把Table Partition 2的寫入切換到第4個X-SERVER，Table Partition 4的寫入切換到第3個X-SERVER，然後更新後設資料。透過這樣的切換方式，整個叢集的寫入點從原來的兩個變成四個，整個叢集的TPS能力提高了一倍。

因此，透過X-DB各種元件的配合，以及架構調整，我們實現了資料庫架構的高度擴充套件。

所有新技術的落地都會經歷預研、驗證、部署三個階段，在2017年，阿里已經在其中一個交易單元對第四代資料庫架構（X-DB）進行了充分驗證。今年我們也會繼續往前推進，做到兩個百分百：百分百全網儲存與計算分離覆蓋、百分百X-DB部署。同時第四代資料庫架構更深入的技術也會重新投入到這個迴圈當中。