阿里自研分布式強一致關系型數(shù)據(jù)庫——XDB,阿里分析型數(shù)據(jù)庫-ESG跨境

阿里自研分布式強一致關系型數(shù)據(jù)庫——XDB,阿里分析型數(shù)據(jù)庫

阿里自研分布式強一致關系型數(shù)據(jù)庫——XDB

0寫在前面

今年雙 11 是 XDB 的第一次大考，本次雙 11XDB 服務于天貓 / 淘寶核心交易系統(tǒng)、核心物流系統(tǒng)、核心 IM 系統(tǒng)，經(jīng)受了零點業(yè)務 32.5 萬筆 / 秒峰值的性能考驗（對應數(shù)據(jù)庫峰值每秒破億次的 SQL 調(diào)用）；同時 XDB 支撐起了新一代單元化架構，在分布式一致性算法 Paxos 的統(tǒng)一框架下，第一次提供了跨 Region 分布式強一致能力，實現(xiàn)高效的跨 Region 數(shù)據(jù)同步、跨 Region 容災，保證金融級的數(shù)據(jù)質量服務。

XDB 為了降低用戶的遷移和學習成本，選擇了兼容成熟的 MySQL 生態(tài)，并且做到了真正 100% 兼容 MySQL 生態(tài)，為業(yè)務，為傳統(tǒng)數(shù)據(jù)庫賦能?；?MySQL 的業(yè)務可以無縫從 MySQL 遷移到 XDB 上來，不需要任何評估和兼容測試，完全零成本遷移。基于 MySQL 的周邊工具平臺，甚至是 MySQL DBA 都可以非常平滑的轉移到 XDB 上來。阿里內(nèi)部從今年 6 月初第一個業(yè)務應用灰度切流，到目前為止 5 個月的時間里，XDB 已覆蓋了阿里集團及多個關聯(lián)公司旗下的多個事業(yè)群，為海量的線上業(yè)務提供服務，整個過程絕大部分業(yè)務都是無感知的。

XDB 擁有真正的跨 Region/ 跨國的數(shù)據(jù)強一致能力，并已得到實踐的檢驗。雙 11 前夕，核心物流系統(tǒng)、核心 IM 系統(tǒng)首次完成了中心 Region 所有數(shù)據(jù)庫不可用的“中心城市容災演練”，驗證業(yè)務擁有在整個中心 Region 均不可用情況下，XDB 和應用仍可以正常提供服務的能力，并保證數(shù)據(jù)零丟失。

1XDB 的核心優(yōu)勢和技術解析

XDB 是阿里自研的全球級分布式關系型數(shù)據(jù)庫。現(xiàn)在業(yè)界各種類型的分布式數(shù)據(jù)庫不斷涌現(xiàn)，互聯(lián)網(wǎng)巨頭、傳統(tǒng)數(shù)據(jù)庫廠商、數(shù)據(jù)庫創(chuàng)業(yè)公司都在不斷跟進。那么 XDB 到底有什么優(yōu)勢能戰(zhàn)勝這些競品，快速獲得業(yè)務價值呢

1. XDB 生態(tài) 100% 兼容 MySQL

新一代分布式關系型數(shù)據(jù)庫是對傳統(tǒng)關系型數(shù)據(jù)庫的傳承和革新。分布式數(shù)據(jù)庫雖然在高可能、強一致、高性能、低成本、高伸縮等多個方面作出了劃時代的變革；但其依舊傳承了傳統(tǒng)數(shù)據(jù)庫強大的 SQL 接口，系統(tǒng)管理能力。NoSQL 的衰弱和 NewSQL 的興起，恰恰證明了這一點。一個新的分布式數(shù)據(jù)庫，如果沒有傳承，自建一個新的生態(tài)，將會極大的提高用戶的學習和使用成本，整個工具和支持配套也將面臨很大的困難。因此，XDB 作為一個新一代分布式關系型數(shù)據(jù)庫，設計之初就選了業(yè)界相對開放和成熟的 MySQL 開源生態(tài)作為自己的基礎。這樣不單可以讓 MySQL 生態(tài)中的用戶零成本的切換到 XDB 中，快速賦予業(yè)務分布式數(shù)據(jù)庫所帶來的多種能力；同時可以讓 MySQL 生態(tài)中的各種周邊工具和 DBA 等生態(tài)的參與者平滑的切換到分布式時代，賦予其支撐分布式數(shù)據(jù)庫的能力。

事實證明 XDB 選擇的這條路是正確的。在阿里集團及生態(tài)下的子公司內(nèi)部，XDB 在短短的幾個月內(nèi)、在非常少的人力參與下，迅速的完成了對大量傳統(tǒng) MySQL/AliSQL 集群的換代升級，使得阿里數(shù)據(jù)庫整體進入了分布式時代，整個過程業(yè)務幾乎零參與。同時 XDB 對 MySQL 生態(tài)下的運維系統(tǒng) / 工具、知識體系也實現(xiàn)了兼容，整個 MySQL 時代的支撐平臺，支撐人員都可以平滑的過度到分布式數(shù)據(jù)庫時代，擁有了支撐下一代數(shù)據(jù)庫的能力，這個是非常難得的。

2. 跨 Region/ 全球強同步能力

業(yè)界支持分布式強一致的數(shù)據(jù)庫很多，但是其強一致都是有范圍的，有些支持 AZ 內(nèi)強一致，有些支持跨 AZ 強一致，真正能做到跨 Region/ 跨國強一致的卻是鳳毛麟角。目前業(yè)界主流數(shù)據(jù)庫中，只有 Spanner 宣稱自己是 Global Distribution，包括 Amazon Aurora 在內(nèi)的其他主流數(shù)據(jù)庫目前都不支持跨 Region 的強一致。XDB 是真正做到了跨 Region/ 跨國強一致的分布式數(shù)據(jù)庫，并且在業(yè)務上得到了驗證。今年音視頻服務全站遷移 XDB，同時 XDB 支撐了音視頻服務國際化等多個國際化項目，實現(xiàn)跨國部署。包括核心交易系統(tǒng)、核心物流系統(tǒng)、核心 IM 系統(tǒng)在內(nèi)的大量業(yè)務集群以跨 Region 強同步模式部署，使得業(yè)務擁有了城市級容災情況下，數(shù)據(jù)零丟失，服務秒級恢復的能力。核心物流系統(tǒng)、核心 IM 系統(tǒng)在雙 11 前夕分別進行了中心 Region 全不可用的容災演練，XDB 在 15 秒內(nèi)自動完成跨 Region 的重新激活，數(shù)據(jù)零丟失，這在整個行業(yè)都是先行者。

技術解析：XPaxos——高性能 Paxos 獨立庫

Paxos 是一種分布式一致性算法，其最基礎也是最重要的功能是保證分布式系統(tǒng)中多個節(jié)點的數(shù)據(jù)（日志）的強一致，它是分布式系統(tǒng)的基石。雖然 Paxos 算法被圖靈獎獲得者 Leslie Lamport 首次提出到現(xiàn)在已經(jīng) 19 年了，離第一個工業(yè)實現(xiàn)（Chubby）也已經(jīng) 11 年了，但是近幾年，頂級會議 / 業(yè)內(nèi)文章中 Paxos 的優(yōu)化和討論還是非常的多，而且到目前為止真正工業(yè)級的、高性能的、高可擴展的 Paxos 算法庫還是非常的少見。

XPaoxs 是阿里獨立設計 / 研發(fā)的，真正工業(yè)級的 Paxos 獨立庫，其在性能上好于業(yè)界對手 1、2 個數(shù)量級以上，同時其強大的擴展性和完善的生態(tài)系統(tǒng)都是競品所沒有的，XPaxos 為分布式高性能數(shù)據(jù)庫 XDB 奠定了堅實的基礎。

XPaxos 從基礎架構，到網(wǎng)絡模型，再到算法本身都有大量的創(chuàng)新：

基于 SEDA 架構的異步并發(fā)調(diào)度框架

由于 Paxos 的內(nèi)部狀態(tài)復雜，實現(xiàn)高效的單實例多線程的 Paxos 變成一個非常大的挑戰(zhàn)。大部分競品例如 Oracle/MySQL 的 Group Replication 等針對單個 Paxos 對象都是單線程實現(xiàn)。

XPaxos 實現(xiàn)了一整套高效的異步并發(fā)調(diào)度框架，并基于 SEDA（Staged EventDriven Architecture）思想，對整個 Paxos 協(xié)議進行了并發(fā)切分和實現(xiàn)，采用了大量無鎖設計；由異步并發(fā)調(diào)度框架進行調(diào)度和執(zhí)行，充分利用多核資源，實現(xiàn)高性能。

基于 Batching  Pipelining 的網(wǎng)絡優(yōu)化

跨 Region/ 跨國場景下對 XPaxos 來說最大的挑戰(zhàn)就是如何在高延遲網(wǎng)絡下保持高吞吐和相對低延遲，XPaxos 針對高延遲網(wǎng)絡做了大量的協(xié)議優(yōu)化嘗試和測試，并結合學術界現(xiàn)有的理論成果通過合理的 Batching 和 Pipelining，設計并實現(xiàn)了一整套自適應的針對高延遲高吞吐和低延遲高吞吐網(wǎng)絡的通信模式，極大的提升了 XPaxos 的性能。類似的優(yōu)化大部分還在理論階段，在同類競品中還非常的罕見。

Jepsen/TLA+ 的分布式原理 / 實現(xiàn)驗證

《Paxos made live》中有過一個說法，證明一個 Paxos 實現(xiàn)是正確的，比實現(xiàn)這個 Paxos 本身會更難。因此我們在設計和實現(xiàn) XPaxos 的時候，投入了大量的精力在 Paxos 的原理證明了實現(xiàn)驗證上。我們用 TLA+ 對 XPaxos 進行建模，驗證其理論正確性。我們將 Jepsen 對 XPaxos/XDB 進行適配，同時增加了大量的驗證 Case 和注入錯誤，7X24 小時運行，驗證其實現(xiàn)正確性。

3. 強一致下的高性能

業(yè)界習慣性的認為，強一致一定會帶來性能的下降，開強 MP 的 Oracle，在 SemiSync 的 MySQL，MySQL Group Replication 甚至于跨 Region 部署以后的 Spanner，會面臨大幅度的性能下降的問題。今年雙 11 XDB 在核心交易系統(tǒng)、核心物流系統(tǒng)等交易核心鏈路上 100% 切流，經(jīng)歷了多輪全鏈路壓測和雙 11 零點業(yè)務 32.5 萬筆 / 秒，數(shù)據(jù)庫 SQL 上億次 / 秒的峰值的性能考驗，證明了 XDB 完全有能力實現(xiàn)強一致和高性能的魚熊兼得。

XDB 從 Paxos 協(xié)議的實現(xiàn)，到 XPaxos 和 AliSQL 的日志結合，再到 AliSQL 本身的提交邏輯，鎖策略都做了大量的優(yōu)化。保證 XDB 無論是在多機房部署還是多 Region 部署下，都能保證性能和單節(jié)點模式（非強一致）下無大幅度劣化。特別是在跨 Region 部署時，和其他分布式數(shù)據(jù)庫相比，優(yōu)勢尤為明顯。這也是業(yè)務能夠接受 XDB 跨 Region 部署的主要原因。

XDB 是 AliSQL 和 XPaxos 的緊密結合而產(chǎn)生的。高性能的 XPaxos 為不單為 XDB 帶來了高可用和強一致的能力，同時為 XDB 的在強一致下的高可用奠定了堅實的基礎。除此以外，我們在 AliSQL 和 XPaxos 的結合上也做了大量的優(yōu)化，例如一體化日志設計和異步事務提交。

技術解析：一體化日志設計

XDB 的 Consensus 日志采用了單一事務日志的方案（區(qū)別于 MySQL 的 binlog 和 relaylog 兩份日志），單一事務日志格式 MySQL binlog 的事務日志格式。這份日志被用于集群節(jié)點間數(shù)據(jù)的同步以及下游應用的消費。

一體化日志設計帶來的好處是顯而易見的，首先是日志量的減少。MySQL 接收到主庫的網(wǎng)絡消息后會先本地落一份 relaylog 日志，在消費后再產(chǎn)生一份 binlog 日志。雖然 relaylog 會很快被回收，但是日志的寫入量是實實在在的兩份。反觀 XDB 在統(tǒng)一了日志后，同一個事務在一個實例節(jié)點上只需要記錄一份日志。其次統(tǒng)一日志能夠讓日志真正按照產(chǎn)生的先后續(xù)做到邏輯和物理上的一致，這對于日志的檢索效率來說是大有裨益的。首先是順序掃描日志的時候可以做到物理 IO 上的順序性，其次 Paxos 算法的運轉對于日志的檢索和獲取都有較高的要求，如果檢索一份日志需要先后掃描兩份日志跳轉來判斷比較，那對于效率來說是非常低下的。

技術解析：異步事務提交

在數(shù)據(jù)庫中，服務端的線程池是非常有效降低線程上下文切換開銷，提升系統(tǒng)吞吐的技術。但是在跨城 / 跨國環(huán)境下，巨大的網(wǎng)絡延遲使得線程池本身會成為一種瓶頸。例如 XDB 集群的節(jié)點分布在網(wǎng)絡 RTT 達到幾十毫秒級別的兩個 Region 中，那么在實際的運行中會發(fā)現(xiàn)線程池中絕大部份線程都在等待日志跨 Region 同步回包，而客戶端的請求就沒有足夠的線程去處理了，這其實造成了服務器資源的嚴重浪費。

重新回到非線程池的狀態(tài)不是一個明智之舉，既要低上下文開銷又要有高資源利用率。我們采取的解決方案是將事務處理中可能最為費時的等待事務日志回報做成異步化。 這樣就把一個完整的事務流程拆成了：處理請求 等待同步 事務提交的三個步驟，三個步驟可以分別由線程池的不同線程來完成。每個步驟 XDB 可以精確控制并發(fā)量，例如可以用最少的線程數(shù)量來處理事務等待日志同步的工作，用大量的線程來處理事務提交等等。在異步化改造后，只要用戶的并發(fā)請求量足夠多，系統(tǒng)吞吐量上可以有明顯的提高。

4. 豐富靈活的部署模式

針對電商雙 11 這種，不同時期不同需求的業(yè)務模型，XDB 提供了非常豐富并且靈活的部署模式，例如核心交易系統(tǒng)、核心物流系統(tǒng)，在今年雙 11 前夕，將部署模式從跨城強同步模式一鍵切換回同城強同步模式，并動態(tài)調(diào)整拓撲，在保證機房級強一致的前提下，有效的降低了 RT，提升了吞吐。

集團內(nèi)外不同的業(yè)務對數(shù)據(jù)庫的部署需求各不相同，為了更廣泛的支持不同的業(yè)務 XDB 支持的部署模式非常的靈活。業(yè)務可以根據(jù)自己的容災和業(yè)務需求，在不同的部署范圍內(nèi)（同城多機房 / 國內(nèi)多 Region/ 跨國等）選擇任意數(shù)量、任意角色的節(jié)點進行部署，節(jié)點的部署和角色同樣可以在線修改以適應業(yè)務的不同時期的不同需求，例如雙 11。這樣說有點抽象，這里舉 2 個實際的案例.

案例：同城跨機房模式

上圖是一個經(jīng)典的同城跨機房強同步方案，滿足以下需求

機房級容災數(shù)據(jù)零丟失，10 秒級容災切換

相對于主備方案零成本增加（2 數(shù)據(jù)副本，1 日志副本，日志副本資源需求可忽略）

RPO  1S（通過 XPaxos SDK 持續(xù)備份）

當然業(yè)務可以在這個模式的基礎上做多種擴展，例如增加只讀無選舉權的 learner 節(jié)點；增加有選舉權的 follower 節(jié)點等來提升容災等級和讀能力。

案例：跨城單元化模式

上圖是一個經(jīng)典的跨城強同步方案，滿足以下需求

真正的跨城強一致能力：任意城市整體不可用不影響集群可用性，零數(shù)據(jù)丟失

高性能：在跨城強同步下依然保持高性能

靈活的切換策略：可分別設置同城節(jié)點，跨城節(jié)點切換優(yōu)先級

高伸縮能力：可任意增加 / 刪除 / 動態(tài)修改任意 Region 的數(shù)量和角色

目前核心交易系統(tǒng)、核心物流系統(tǒng)、核心 IM 系統(tǒng)等核心集群均采用類似部署方案保證跨城容災能力。

更重要的是 XDB 支持動態(tài)切換部署模式，例如核心交易系統(tǒng)、核心物流系統(tǒng)等集群在雙 11 期間一鍵動態(tài)將跨城模式切換到同城模式，在保持機房級容災能力的前提下，獲得更高的性能；音視頻服務通過在海外 Region 動態(tài)擴展一個 Leaner 角色的節(jié)點實現(xiàn)國際化。

大促模式

擴展讀 Region

技術解析：Paxos 框架下的角色定制和動態(tài)變更

在分布式數(shù)據(jù)庫中經(jīng)典的 Paxos 用法是將 Paxos 作為一個整體來解決高可用和強一致問題。然而 Paxos 算法不單單能解決高可用強一致問題。在 XPaxos 中我們對 Paxos 算法進行了擴展，將 Paxos 算法中節(jié)點的三個角色（Proposer/Accepter/Learner）進行了剝離和重組，形成了多種不同角色的節(jié)點，這些節(jié)點組合后，可以形成多種適合不同業(yè)務的部署模式，同時 XPaxos 設計了一整套動態(tài) Configure Change 算法支持所有部署模式之間的動態(tài)切換，對業(yè)務非常友好。

2XDB 的演進

XDB 1.0 是整個 XDB 的計劃的一部分，整個 XDB 計劃將按照三步進行

XDB 1.0(XCluster): 集成 XPaxos，實現(xiàn)金融級分布式強一致能力、一體化的架構設計以及統(tǒng)一的生態(tài)環(huán)境。

XDB 2.0: 基于自研高性能低成本存儲引擎 XEngine，與分布式存儲結合打造的計算與存儲分離架構，能獨立擴展計算和存儲的能力，為業(yè)務在不同場景的負載下，提供靈活的伸縮能力。同時得益于全新設計的存儲引擎，能夠提供其他同類產(chǎn)品難以匹敵的性能。

XDB 3.0: 新一代分布式關系型數(shù)據(jù)庫，同時支持了數(shù)據(jù)自動分片負載均衡，多點可讀可寫，跨域強同步，AZ 內(nèi)快速擴充計算節(jié)點的計算存儲分離架構，應用了一系列技術：為充分發(fā)揮硬件性能的軟硬件結合技術以及根據(jù)數(shù)據(jù)冷熱特點的分層混合存儲技術，無論上是在擴展性和高可用性，還是成本和性能上都做到極致，是 XDB 計劃數(shù)據(jù)庫系統(tǒng)演進的最終形態(tài)。

特別聲明：以上文章內(nèi)容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內(nèi)容、版權或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。