2017雙11技術揭秘—X-DB支撐雙11進入分散式資料庫時代

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

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計劃將按照三步進行

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

推薦閱讀：