摘要： 今年雙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的統一框架下，
X-DB為了降低用戶的遷移和學習成本， 選擇了相容成熟的MySQL生態， 並且做到了真正100%相容MySQL生態， 為業務， 為傳統資料庫賦能。 基於MySQL的業務可以無縫從MySQL遷移到X-DB上來， 不需要任何評估和相容測試， 完全零成本遷移。 基於MySQL的周邊工具平臺， 甚至是MySQL DBA都可以非常平滑的轉移到X-DB上來。 阿裡內部從今年6月初第一個業務應用灰度切流， 到目前為止5個月的時間裡， X-DB已覆蓋了阿裡集團及多個關聯公司旗下的多個事業群， 為海量的線上業務提供服務， 整個過程絕大部分業務都是無感知的。
X-DB擁有真正的跨Region/跨國的資料強一致能力，
X-DB是阿裡自研的全球級分散式關係型數據庫。 現在業界各種類型的分散式資料庫不斷湧現， 互聯網巨頭、傳統資料庫廠商、資料庫創業公司都在不斷跟進。 那麼X-DB到底有什麼優勢能戰勝這些競品， 快速獲得業務價值呢？
X-DB生態100%相容MySQL
新一代分散式關係型數據庫是對傳統關係型數據庫的傳承和革新。 分散式資料庫雖然在高可能、強一致、高性能、低成本、高伸縮等多個方面作出了劃時代的變革；但其依舊傳承了傳統資料庫強大的SQL介面，
因此， X-DB作為一個新一代分散式關係型數據庫， 設計之初就選了業界相對開放和成熟的MySQL開源生態作為自己的基礎。 這樣不單可以讓MySQL生態中的用戶零成本的切換到X-DB中， 快速賦予業務分散式資料庫所帶來的多種能力；同時可以讓MySQL生態中的各種周邊工具和DBA等生態的參與者平滑的切換到分散式時代， 賦予其支撐分散式資料庫的能力。
事實證明X-DB選擇的這條路是正確的。
跨Region/全球強同步能力
業界支援分散式強一致的資料庫很多， 但是其強一致都是有範圍的， 有些支持AZ內強一致， 有些支持跨AZ強一致， 真正能做到跨Region/跨國強一致的卻是鳳毛麟角。 目前業界主流資料庫中， 只有Spanner宣稱自己是Global Distribution， 包括Amazon
Aurora在內的其他主流資料庫目前都不支援跨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 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計畫資料庫系統演進的最終形態。
它是分散式系統的基石。雖然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 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計畫資料庫系統演進的最終形態。