摘要： 今年雙11是X-DB的第一次大考，本次雙11X-DB服務于天貓/淘寶核心交易系統、核心物流系統、核心IM系統，經受了零點業務32.5萬筆/秒峰值的性能考驗,同時X-DB支撐起了新一代單元化架構.

作者：章穎強（江疑）、胡煒

X-DB 1.0(X-Cluster)是阿里自主研發的，100%兼容MySQL生態的，全球級分布式強一致的關系型數據庫系統。今年雙11是X-DB的第一次大考，本次雙11X-DB服務于天貓/淘寶核心交易系統、核心物流系統、核心IM系統，經受了零點業務32.5萬筆/秒峰值的性能考驗（對應數據庫峰值每秒破億次的SQL調用）；同時X-DB支撐起了新一代單元化架構，在分布式一致性算法Paxos的統一框架下，第一次提供了跨Region分布式強一致能力，實現高效的跨Region數據同步、跨Region容災，保證金融級的數據質量服務。

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

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

X-DB的核心優勢和技術解析
X-DB是阿里自研的全球級分布式關系型數據庫。現在業界各種類型的分布式數據庫不斷涌現，互聯網巨頭、傳統數據庫廠商、數據庫創業公司都在不斷跟進。那么X-DB到底有什么優勢能戰勝這些競品，快速獲得業務價值呢？

X-DB生態100%兼容MySQL
新一代分布式關系型數據庫是對傳統關系型數據庫的傳承和革新。分布式數據庫雖然在高可能、強一致、高性能、低成本、高伸縮等多個方面作出了劃時代的變革；但其依舊傳承了傳統數據庫強大的SQL接口，系統管理能力。NoSQL的衰弱和NewSQL的興起，恰恰證明了這一點。一個新的分布式數據庫，如果沒有傳承，自建一個新的生態，將會極大的提高用戶的學習和使用成本，整個工具和支持配套也將面臨很大的困難。

因此，X-DB作為一個新一代分布式關系型數據庫，設計之初就選了業界相對開放和成熟的MySQL開源生態作為自己的基礎。這樣不單可以讓MySQL生態中的用戶零成本的切換到X-DB中，快速賦予業務分布式數據庫所帶來的多種能力；同時可以讓MySQL生態中的各種周邊工具和DBA等生態的參與者平滑的切換到分布式時代，賦予其支撐分布式數據庫的能力。

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

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

技術解析：X-Paxos——高性能Paxos獨立庫
Paxos是一種分布式一致性算法，其最基礎也是最重要的功能是保證分布式系統中多個節點的數據（日志）的強一致，它是分布式系統的基石。雖然Paxos算法被圖靈獎獲得者Leslie Lamport首次提出到現在已經19年了，離第一個工業實現（Chubby）也已經11年了，但是近幾年，頂級會議/業內文章中Paxos的優化和討論還是非常的多，而且到目前為止真正工業級的、高性能的、高可擴展的Paxos算法庫還是非常的少見。

X-Paoxs是阿里獨立設計/研發的，真正工業級的Paxos獨立庫，其在性能上好于業界對手1、2個數量級以上，同時其強大的擴展性和完善的生態系統都是競品所沒有的，X-Paxos為分布式高性能數據庫X-DB奠定了堅實的基礎。

X-Paxos從基礎架構，到網絡模型，再到算法本身都有大量的創新：

基于SEDA架構的異步并發調度框架
由于Paxos的內部狀態復雜，實現高效的單實例多線程的Paxos變成一個非常大的挑戰。大部分競品例如Oracle/MySQL的Group Replication等針對單個Paxos對象都是單線程實現。X-Paxos實現了一整套高效的異步并發調度框架，并基于SEDA（Staged Event-Driven Architecture）思想，對整個Paxos協議進行了并發切分和實現，采用了大量無鎖設計；由異步并發調度框架進行調度和執行，充分利用多核資源，實現高性能。
基于Batching & Pipelining的網絡優化
跨Region/跨國場景下對X-Paxos來說最大的挑戰就是如何在高延遲網絡下保持高吞吐和相對低延遲，X-Paxos針對高延遲網絡做了大量的協議優化嘗試和測試，并結合學術界現有的理論成果通過合理的Batching和Pipelining，設計并實現了一整套自適應的針對高延遲高吞吐和低延遲高吞吐網絡的通信模式，極大的提升了X-Paxos的性能。類似的優化大部分還在理論階段，在同類競品中還非常的罕見。

Jepsen/TLA+的分布式原理/實現驗證
《Paxos made live》中有過一個說法，證明一個Paxos實現是正確的，比實現這個Paxos本身會更難。因此我們在設計和實現X-Paxos的時候，投入了大量的精力在Paxos的原理證明了實現驗證上。我們用TLA+對X-Paxos進行建模，驗證其理論正確性。我們將Jepsen對X-Paxos/X-DB進行適配，同時增加了大量的驗證Case和注入錯誤，7X24小時運行，驗證其實現正確性。
強一致下的高性能
業界習慣性的認為，強一致一定會帶來性能的下降，開強MP的Oracle，在Semi-Sync的MySQL，MySQL Group Replication甚至于跨Region部署以后的Spanner，會面臨大幅度的性能下降的問題。

今年雙11 X-DB在核心交易系統、核心物流系統等交易核心鏈路上100%切流，經歷了多輪全鏈路壓測和雙11零點業務32.5萬筆/秒，數據庫SQL上億次/秒的峰值的性能考驗，證明了X-DB完全有能力實現強一致和高性能的魚熊兼得。

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

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

技術解析：一體化日志設計
X-DB的Consensus日志采用了單一事務日志的方案（區別于MySQL的binlog和relay_log兩份日志），單一事務日志格式MySQL binlog的事務日志格式。這份日志被用于集群節點間數據的同步以及下游應用的消費。

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

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

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

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

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

案例：同城跨機房模式

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

機房級容災數據零丟失，10秒級容災切換
相對于主備方案零成本增加（2數據副本，1日志副本，日志副本資源需求可忽略）
RPO < 1S（通過X-Paxos SDK持續備份）
當然業務可以在這個模式的基礎上做多種擴展，例如增加只讀無選舉權的learner節點；增加有選舉權的follower節點等來提升容災等級和讀能力。
案例：跨城單元化模式

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

真正的跨城強一致能力：任意城市整體不可用不影響集群可用性，零數據丟失
高性能：在跨城強同步下依然保持高性能
靈活的切換策略：可分別設置同城節點，跨城節點切換優先級
高伸縮能力：可任意增加/刪除/動態修改任意Region的數量和角色
目前核心交易系統、核心物流系統、核心IM系統等核心集群均采用類似部署方案保證跨城容災能力。
更重要的是X-DB支持動態切換部署模式，例如核心交易系統、核心物流系統等集群在雙11期間一鍵動態將跨城模式切換到同城模式，在保持機房級容災能力的前提下，獲得更高的性能；音視頻服務通過在海外Region動態擴展一個Leaner角色的節點實現國際化。

技術解析：Paxos框架下的角色定制和動態變更
在分布式數據庫中經典的Paxos用法是將Paxos作為一個整體來解決高可用和強一致問題。然而Paxos算法不單單能解決高可用強一致問題。在X-Paxos中我們對Paxos算法進行了擴展，將Paxos算法中節點的三個角色（Proposer/Accepter/Learner）進行了剝離和重組，形成了多種不同角色的節點，這些節點組合后，可以形成多種適合不同業務的部署模式，同時X-Paxos設計了一整套動態Configure Change算法支持所有部署模式之間的動態切換，對業務非常友好。

X-DB的演進
X-DB 1.0是整個X-DB的計劃的一部分，整個X-DB計劃將按照三步進行

X-DB 1.0(X-Cluster): 集成X-Paxos，實現金融級分布式強一致能力、一體化的架構設計以及統一的生態環境。
X-DB 2.0: 基于自研高性能低成本存儲引擎X-Engine，與分布式存儲結合打造的計算與存儲分離架構，能獨立擴展計算和存儲的能力，為業務在不同場景的負載下，提供靈活的伸縮能力。同時得益于全新設計的存儲引擎，能夠提供其他同類產品難以匹敵的性能。
X-DB 3.0: 新一代分布式關系型數據庫，同時支持了數據自動分片負載均衡，多點可讀可寫，跨域強同步，AZ內快速擴充計算節點的計算存儲分離架構，應用了一系列技術：為充分發揮硬件性能的軟硬件結合技術以及根據數據冷熱特點的分層混合存儲技術，無論上是在擴展性和高可用性，還是成本和性能上都做到極致，是X-DB計劃數據庫系統演進的最終形態。

總結

以上是生活随笔為你收集整理的2017双11技术揭秘—X-DB支撑双11进入分布式数据库时代的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。