阿里如何實現高性能分散式強一致的獨立 Paxos 基礎庫？

作者｜江疑、胡煒

編輯｜木環

Paxos 從理論界到工業界，阿里怎樣實現分散式系統的一致性？

1

寫在前面

近來 Paxos 的分享和討論越來越頻繁，它是分散式系統保持一致性的法寶，但是同時又有著最難理解的演算法之「美譽」。在阿里看來，雖然 Paxos 有一定社區熱度，但是真正工業級的應用仍屬少數。「X-Paxos」是阿里巴巴資料庫團隊面向高性能、全球部署以及阿里業務特徵等需求，實現的一個高性能分散式強一致的 Paxos 獨立基礎庫。不過 X-Paxos 並不是終點，阿里在乎的是基於 X-Paxos 的 AliSQL X-Cluster。那麼 X-Paxos 是有怎樣的技術參數？其技術架構、功能和性能是怎樣的？殺手鐧 X-Paxos 怎麼幫助到 AliSQL X-Cluster？

2

先從 Paxos 理論說起

分散式一致性協議（Consensus Protocol）是分散式計算的基石，用來保證分散式系統中各節點的狀態一致，而 Paxos 就是一種分散式一致性協議。

Chubby 的作者 Mike Burrows 在論文中說過「there is only one consensus protocol, and that』s Paxos」。這話雖然有點絕對，但是不無道理。現在的 Paxos 不單是指 Leslie Lamport 最初論文中提出的 Basic Paxos 或者 Multi Paxos，還泛指大量變種的 Paxos，例如 Cheap Paxos、Fast Paxos、Mecius、EPaxos 等；以及各種類 Paxos 的一致性協議，例如 Raft、ZAB、Viewstamped Replication。這些分散式一致性協議從本質上來說，都是相通的。大致上都包含了 衝突處理 / 選主、Quorum、Recovery、成員變更等技術組成，不同的 Paxos 其組成也各有差別，但是其本質上都是一樣的。在深入調研了廣泛的 Paxos 變種和類 Paxos 協議的基礎上，結合整體架構和設計目標，設計或繼承了 Paxos 中的各個技術組成，完成了阿里針對高性能、全球部署的 X-Paxos 分散式強一致協議。

3

Paxos 理論到工業應用的鴻溝

Paxos 的理論提出已經 17 年了，工業界第一個實現也已經 11 年了。近幾年，頂級會議、業內文章中有越來越多 Paxos 的討論。Google 並沒有開源其任何 Paxos 基礎庫（連包含 Paxos 的項目都沒有 開源過）; Facebook 也沒有公布過包含 Paxos 的產品 ; Apache 有 Zookeeper，但是其協議並不能支持 一個高吞吐的狀態機複製，且並沒有提供獨立的第三方庫，可供快速接入。在 Github 上能找到的 Paxos 的獨立庫，star 最高的是騰訊於去年開源的 PhxPaxos；但是阿里依然認為，止業內還鮮有真正成熟的工業級基礎類庫。

工業級的 Paxos 意味著什麼？首先，必須針對高吞吐、高延遲等工業級要求做針對性的架構設計和優化；其次，必須針對各種可能存在的網路分區 / 閃斷 / 丟包、硬體異常、節點 Crash 等做完善的設計，理論的論證及系統的測試；最後，必須在大規模的線上部署，並經過長期的實踐運行檢驗。目前業界滿足這些要求的 Paxos 基礎庫鳳毛麟角，同時這些基礎庫往往是大企業的核心競爭力，不會對外開源；同時 Paxos 往往結合 DB 等使用，也很少以雲服務形式對外提供，所以外界很難受益。

在《Paxos made live》就提到：Paxos 從理論到現實世界的實現之間有巨大的鴻溝，在真正實現一個 Paxos 的時候，往往需要對 Paxos 的經典理論做一些擴展，（尤其是在實現一個高性能的 Paxos 的時候，擴展點就更多了，可以參考後文的功能增強和性能優化），這往往會導致真正的 Paxos 實現其實都是基於一個未被完全證明的協議。這也就是傳說中，理論證明一個 Paxos 的實現，比實現這個 Paxos 還要難的原因了。

因此一個成熟的 Paxos 實現很難獨立產生，往往需要和一個系統結合在一起，通過一個或者多個系統來驗證其可靠性和完備性。這也是為什麼大部分成熟的 Paxos 案例都是和分散式資料庫相結合的，例如最早的 Paxos 實現（Chubby），當前的主要 Paxos 實現（Google 的 MegaStore、Spanner，AWS 的 DynamoDB、S3 等）。而阿里的 X-Paxos 類庫也是依託於 AliSQL X-Cluster 驗證了其可靠性和完備性。

4

X-Paxos 對工業級應用的適配

上面已經提到，工業級的 Paxos，從性能設計，容錯設計、實現、測試、規模驗證都有非常高的要求。

X-Paxos 從架構設計到最終上線，都做了大量的工作：

針對高吞吐，整個 X-Paxos 都是建立在基於 SEDA 架構的非同步多線程框架之上

針對搞延遲，設計了一整套自適應的 Batching 和 Pipelining 機制，保證在延遲提升的情況下，不影響吞吐

X-Paxos 理論和實現都經過了 TLA+、Jepsen 等分散式測試框架的驗證，並長時間在自動隨機異常系統中進行 24 小時驗證

基於 X-Paxos 的 X-Cluster 已經在數千個線上業務集群長時間穩定運行，無異常。

5

X-Paxos 的技術解析

整體架構

X-Paxos 的整體架構如上圖所示，主要可分為網路層、服務層、演算法模塊、日誌模塊 4 個部分。

網路層：

網路層基於阿里內部非常成熟的網路庫 libeasy 實現。libeasy 的非同步框架和線程池非常契合阿里整體非同步化設計，此外 X-Paxos 還對 libeasy 的重連等邏輯進行了修改，以適應分散式協議的需求。

服務層：

服務層是驅動整個 Paxos 運行的基礎，為 Paxos 提供了事件驅動，定時回調等核心的運行功能，每 一個 Paxos 實現都有一個與之緊密相關的驅動層，驅動層的架構與性能和穩定性密切相關。 X-Paxos 的服務層是一個基於 C++11 特性實現的多線程非同步框架。常見的狀態機 / 回調模型存在開發效率較低，可讀性差等問題，一直被開發者所詬病；而協程又因其單線程的瓶頸，而使其應用場景受到限制。C++11 以後的新版本提供了完美轉發（argument forwarding）、可變模板參數（variadic templates）等特性，為實現一種全新的非同步調用模型提供了可能。 例如這是 X-Paxos 內實際的一行創建單次定時任務的代碼 。

以上一行程序，包含了定時器的創建，任意回調函數的設置，回調函數參數的轉發，並保證在回 調觸發後（Oneshot）內存的自動回收。同時服務層支持嵌套回調，即在回調函數中再一次生成一 個定時 / 即時任務，實現一個有限次定時循環邏輯。

演算法模塊：

X-Paxos 當前的演算法基於 unique proposer 的 multi-paxos[3] 實現，大量理論和實踐已經證明了基於 unique proposer 的 multi-paxos，性能好於 multi-paxos/basic paxos，當前成熟的基於 Paxos 的系統，大部分都採用了這種方式。

演算法模塊的基礎功能部分本文不再重複，感興趣的讀者可以參考相關論文 [1,2,4]。在基礎演算法的基礎上，結合阿里業務的場景以及高性能和生態的需求，X-Paxos 做了很多的創新性的功能和性能的 優化，使其相對於基礎的 multi-paxos，功能變的更加豐富，在多種部署場景下性能都有明顯的提 升。

日誌模塊：

日誌模塊本是演算法模塊的一部分，但是出於對極致性能要求的考慮，日誌模塊還是被獨立出來，並實現了一個默認的高性能的日誌模塊；有極致性能以及成本需求的業務場景下，可以結合已有的日誌系統，對接日誌模塊介面，以獲取更高的性能和更低的成本。

功能

在線添加 / 刪除節點，在線轉讓 leader

X-Paxos 在標準 multi-paxos 的基礎上，支持在線添加 / 刪除多種角色的節點，支持在線快速將 leadership 節點轉移到其他節點（有主選舉）。

策略化多數派和權重化選主

集團及螞蟻目前的多地有中心的架構，很多應用因其部署的特點，往往要求其在未發生城市級容 災的情況下，僅在中心寫入資料庫，或調用其他分散式服務；同時又要求在發生城市級容災的時 候（同一個城市的多個機房全部不可用），可以完全不丟失任何數據的情況下，將寫入點切換到 非中心。

而經典的 multi-paxos 並不能滿足這些需求。經典理論中，多數派強同步以後即可完成提交，而多 數派是非特定的，並不能保證某個 / 某些節點一定能得到完整的數據，並激活服務。在實際實現 中，往往地理位置較近的節點會擁有強一致的數據，而地理位置較遠的節點，一直處於非強一致 結合廣泛的業務場景，構建開放的生態 節點，在容災的時候永遠無法激活為主節點，形同虛設。

同時當中心單節點出現故障需要容災的時候，往往需要將主節點就近切換到同中心的另外一個節 點；由於應用在多地的部署往往是非對稱的原因，才出現單個 region 全掛的時候，寫需要將主節點 切到特定的 region 內。這些需求都需要 Paxos 在選主的時候，可以由用戶指定規則，而經典理論中 同樣沒有類似的功能，添加權重也需要保證 Paxos 的正確性。

X-Paxos 在協議中實現了 【策略化多數派】 和【權重化選主】。基於策略化多數派，用戶可以通過動態配置， 指定某個 / 某些節點必須保有強一致的數據，在出現容災需求的時候，可以立即激活為主節點。基於權重化選主，用戶可以指定各個節點的選主權重，只有在高權重的節點全部不可用的時候，才會激活低權重的節點。

節點角色定製化（Proposer/Accepter/Learner 的獨立配置）

在經典的 multi-paxos 實現中，一般每個節點都包含了 Proposer/Accepter/Learner 三種功能，每一個 節點都是全功能節點。但是某些情況下並不需要所有節點都擁有全部的功能，例如：

經典的三個副本部署中，可以裁剪其中一個節點的狀態機，只保留日誌（無數據的純日誌 節點，但是在同步中作為多數派計算），此時需要裁剪掉協議中的 Proposer 功能（被選舉 權），保留 Accepter 和 Learner 功能。

我們希望可以有若干個節點可以作為下游，訂閱 / 消費協議產生的日誌流，而不作為集群的成員 （不作為多數派計算，因為這些節點不保存日誌流），此時裁剪掉協議的 Proposer/Accepter 功能，只保留 Learner 功能。

當然還有其他的組合方式，通過對節點角色的定製化組合，還可以開發出很多的定製功能節點。

Witness SDK

基於上節節點角色定製化中的單獨 Learner 角色的功能，引發了無窮的想像力。Learner 角色，可以抽象成一個數據流訂閱者（Witness Node），整個集群中可以加入無數個訂閱者，當有新的日誌被 提交的時候，這些訂閱者會收到其關心的日誌流，基於訂閱者功能，可以讓一個集群很容易的實現下游訂閱消費，日誌即時備份，配置變更推送等等的功能。

Learner 角色單獨封裝成了一個 SDK。基於這個 SDK，用戶可以快速的為自己的集群添加，訂閱註冊，流式訂閱定功能；結合特定的用途打造一個完成的生態。 例如日誌流 SDK 在 AliSQL X-Cluster 中打造的生態：

採用了 X-Paxos 也可以利用 Witness SDK 快速實現分散式系統和下游的其他系統的對接，形成一個完 整的生態。

以 MySQL 的日誌（binlog）備份來舉例：

普通方案

每隔固定時間 Tb，將 MySQL 生成的 binlog 文件備份到永久備份系統（OSS、S3 等）

RPO (Recovery Point Objective) 為 Tb

SDK 方案

X-Paxos 支持由 SDK 訂閱增量日誌，備份系統只需要簡單的實現從 SDK 流到 OSS 流的對接，即 可實現流式備份

RPO (Recovery Point Objective) 為 0

除備份以外，Witness SDK 在下游流式訂閱（DRC）、自封閉高可用系統（X-Driver）、非同步只讀備 庫等方面都有實戰案例，更多的應用案例在不斷的添加中。

性能

Batching & Pipelining

Paxos 除了設計之初的強一致和高可用以外，其高性能也是至關重要的，尤其是應用於 AliSQL X-Cluster 這種高性能分散式資料庫的時候，對協議的吞吐，延遲都提出了很高的要求。同時作為可 全球部署的分散式一致性協議，在高延遲下的性能挑戰變得尤為重要。

X-Paxos 針對高延遲網路做了大量的協議優化嘗試和測試，並結合學術界現有的理論成果 [5,6,7] 通 過合理的 Batching 和 Pipelining，設計並實現了一整套自適應的針對高延遲高吞吐和低延遲高吞吐 網路的通信模式，極大的提升了 X-Paxos 的性能。類似的優化在同類競品中還非常 的罕見。

Batching：將多個日誌合併成單個消息進行發送；Batching 可以有效的降低消息粒度帶來的額 外損耗，提升吞吐。但是過大 Batching 容易造成單請求的延遲過大，導致並發請求數過高，繼而影 響了吞吐和請求延遲。

Pipelining：是指在上一個消息返回結果以前，並發的發送下一個消息到對應節點的機制，通過提高 並發發送消息數量（Pipelining 數量），可以有效的降低並發單請求延遲，同時在 transmission delay 小於 propagation delay 的時候（高延遲高吞吐網路），有效提升性能。

經推導可知 Batching（消息大小:M）和 Pipeling（消息並發:P）在如下關係下，達到最高吞吐

其中 R 為網路帶寬，D 為網路傳播延遲（propagation delay，約為 RTT/2） X-Paxos 結合以上理論，通過內置探測，針對不同節點的部署延遲，自適應的調整針對每個節點的 Batching 和 Pipeling 參數，達到整體的最大吞吐。

Pipeling 的引入，需要解決日誌的亂序問題，特別是在異地場景下，window 加大，加大了亂序的概 率。X-Paxos 實現了一個高效的亂序處理模塊，可以對底層日誌實現屏蔽亂序問題，實現高效的亂序日誌存儲。

多線程，全非同步的 Paxos 庫

由於 Paxos 的內部狀態複雜，實現高效的單實例多線程的 Paxos 變成一個非常大的挑戰。無論上面提到的 github 中 star 最多的 PhxPaxos，還是 Oracle MySQL Group Replication 中使用的 xcom，都是單線程的實現。PhxPaxos 採用了單分區單線程，多實例聚合的方式提升總吞吐，但是對單分區 的性能非常的有限；而 xcom 是一個基於協程的單線程實現。單線程的 Paxos 實現，在處理序列化 / 反序列化，分發、發包等邏輯的時候都為串列執行，性能瓶頸明顯。

X-Paxos 完全基於多線程實現，可以在單個分區 Paxos 中完全的使用多線程的能力，所有的任務都有通用的 woker 來運行，消除了 CPU 的瓶頸。依賴於服務層的多線程非同步框架和非同步網路層，X-Paxos 除了必要的協議串列點外，大部分操作都可以並發執行，並且部分協議串列點採用了無鎖設 計，可以有效利用多線程能力，實現了 Paxos 的單分區多線程能力，單分區性能遠超競品，甚至超過了競品的多分區性能。

Locality Aware Content Distribution

基於 unique proposer 的分散式系統的存在的一個瓶頸點就是主節點是唯一的內容輸出源，當集群 存在大量節點的時候，主節點的大量網路收發工作會導致主節點的負載過大，引發 CPU 和帶寬的瓶頸；在全國 / 全球部署的時候，所有節點和主節點之間的直接通信會造成跨 region 之間的長傳 / 國際 鏈路的帶寬佔用過大。

X-Paxos 是旨在解決全球分散式強一致問題的 Paxos 獨立庫，在設計之初就考慮到了這個問題。X-Paxos 在穩態運行時會感知各個節點之間的網路延遲（物理距離），並形成級聯拓撲，有效降低主 節點的負載，降低長傳鏈路的帶寬使用；而在有節點異常的時候，又會自動重組拓撲，保證各個 存活節點間的同行的正常進行。同時 X-Paxos 支持有業務來設定重組拓撲的規則，業務可以根據自 己 APP 的部署架構和延遲特性來針對性的設置拓撲重組規則。

可插拔日誌

X-Paxos 和現有的大部分 paxos 庫很大的不同點就是 X-Paxos 支持可插拔的日誌模塊。日誌模塊是 Paxos 中一個重要的模塊，它的持久化關係到數據的一致性，它的讀寫性能很大程度上會影響協議 整體的讀寫性能。當前大部分獨立 Paxos 庫都是內置日誌模塊，並且不支持插拔的。這會帶來兩個弊端：

默認的日誌模塊提供通用的功能，很難結合具體的系統做針對性的優化

現有的系統往往已經存在了 WAL（Write Ahead Log）, 而 Paxos 協議中需要再存一份。這使得 a) 單次 commit 本地需要 sync 2 次（影響性能）；b) 雙份日誌浪費了大量的存儲

例如：PhxPaxos 內置的日誌模塊採用 LevelDB，作為日誌系統其操作大量冗餘，無針對優化，性能 堪憂；同時採用 PhxPaxos 的 phxsql 單節點需要即保存 binlog，又保存 Paxos log(在獨立的 phxbinlogsvr 中)，嚴重影響了性能，浪費了存儲空間。而採用 X-Paxos 的 AliSQL X-Cluster 直接改造 了現有的 binlog 模塊，對接到 X-Paxos 的日誌模塊，單節點僅一份日誌，即降低了存儲，又提高了性能。

核心武器

X-Paxos 的核心武器有兩點： 高性能；全球部署能力。

在高性能方面：

服務層實現了一整套基於 SEDA 架構和 C++ 11/14 特性的多線程非同步調度服務。

基於高性能的服務層，將整個 X-Paxos 的流程進行完全的非同步化，消除 IO（網路 / 磁碟）和臨界資源引發的線程調度，提高 CPU 執行效率

服務層實現了同類任務自動合併和同類任務線程親和，降低了任務指令數，同時提升了 CPU 指令緩存（icache）命中率，從而提升 IPC

在 Paxos 實現上引入了大量無鎖操作，提升並發能力

在全球部署方面：

X-Paxos 在架構設計上支持 Batching 和 Pipelining，並且支持動態調整；同時從理論上結合了網路通信的最佳效率模型，針對不同距離的節點，自適應的調整每個節點間的通信模型，保證最高的通信效率。

從而使得 X-Paxos 無論是在小範圍部署還是在跨 Region 或者全球部署中都保持高吞吐當然 X-Paxos 還有很多其他的優勢，例如插件日誌、豐富的定製角色、LACD 等，都是非常領先的。

迷思：網路延遲不影響吞吐？

理論上來說網路延遲其實是不影響吞吐的，但是現實的強一致系統中，往往在網路延遲增加的情況下，會導致吞吐的急劇下降呢？究其原因，是在於現實中的系統，往往在內部調用或者是網路通信上存在同步點，或者說不能完全的 scale out。

例如從阿里的測試來看 MySQL Group Replication 在網路延遲從 0.1ms 上升到 30ms 的時候，吞吐下降到原來的 1/4，而 PhxPaxos 在同樣的網路延遲上升情況下，吞吐下降到原來的 1/30。從公開資料和源碼可以看到，MySQL Group Replication 核心的 Paxos 庫 xcom，只支持固定的 10 條 pipelining；而 PhxPaxos 不支持 pipelining，可想而知。

X-Paxos 實現了完全動態的 pipelining，可以動態任意的調節 pipelining 數量；同時 X-Paxos 基於網路最優化理論和每個節點間的網路延遲不同，可以自適應的獨立調整每個節點的 pipelining 數量，以及 batching 大小，從而使得 X-Paxos 在網路延遲從 0.1ms 上升到 30ms 的時候，其吞吐完全沒有下降。

我們的願景是希望能夠提供一個經過實踐檢驗的，高度成熟可靠的獨立 Paxos 基礎庫。使得一個後 端服務能夠通過簡單的接入，就能擁有 Paxos 演算法賦予的強一致、高可用、自動容災等能力。真正將晦澀難懂的 Paxos，變得平易近人，帶入千萬家。——江疑

6

X-Paxos 應用：深度整合 AliSQL X-Cluster，替換原有複製機制

單純的 X-Paxos 並不是終點，它是阿里巴巴分散式資料庫 AliSQL X-Cluster 的前期鋪墊工作。如上文提到 Paxos 是分散式系統的基石，用於解決分散式系統中的一致性問題。

X-Cluster 是第一個接入 X-Paxos 生態的重要產品，利用了 X-Paxos 實現了自動選主、日誌同步、集群內數據強一致，在線集群配置變更等功能。AliSQL X-Cluster 替換了原有的複製機制。整體的複製、回放、提交、恢復都整合了 Paxos 邏輯，並且針對 WAN 部署做了針對性的優化。

同時 X-CLuster 基於 MySQL 生態，兼容最新版本的 MySQL 5.7，集成 AliSQL。 MySQL 的用戶可以零成本遷移到 X-Cluster 上。

AliSQL X-Cluster 整體架構思路

上圖展示的是一個部署三個實例的 Cluster 集群。X-Cluster 是一個單點寫入，多點可讀的集群系統。在同一時刻，整個集群中至多會有一個 Leader 節點 來承擔數據寫入的任務。相比多點寫入，單點寫入不需要處理數據集衝突的問題，可以達到更好的性能與吞吐率。

X-Cluster 的每個實例都是一個單進程的系統，X-Paxos 被深度整合到了資料庫內核之中，替換了原有的複製模塊。集群節點之間的增量數據同步完全 是通過 X-Paxos 來自驅動，如何複製，從哪個點回放不再需要運維人員或者外部工具來介入。 X-Cluster 利用 MySQL 的 Binlog 進 行深度改造和定製來作為 X-Paxos 的 Consensus 日誌，實現了一系列的 X-Paxos 日誌介面，賦予 X-Paxos 直接操縱 MySQL 日誌的能力。

為了保證集群數據的一致性以及全球部署的能力，在事務提交、日誌複製回放以及恢復上 X-Cluster 都進行了重新設計。

事務提交、複製流程

X-Cluster 的複製流程是基於 X-Paxos 驅動 Consensus 日誌進行複製。

Leader 節點在事務 prepare 階段會將事務產生的日誌收集起來，傳遞給 X-Paxos 協議層後進入等待。X-Paxos 協議層會將 Consensus 日誌高效地轉發給 集群內其他節點。當日誌在超過集群半數實例上落盤後 X-Paxos 會通知事務可以進入提交步驟。否則如果期間發生 Leader 變更，期間 prepare 的事務會 根據 Paxos 日誌的狀態進行相應的回滾操作。相比原生 MySQL，日誌傳輸採用了多線程、非同步化、Batching、Pipelining 等優化手段，特別是在長傳鏈 路的場景中，效率提升明顯。

Follower 節點也使用 X-Paxos 進行日誌的管理操作，為提升接收效率，收到 Leader 傳遞過來的日誌以後將日誌內容 Append 到 Consensus Log 末尾，Leader 會非同步的將達成多數派的日誌的消息發送給 Follower，Follower 的協調者線程會負責讀取達成多數派的日誌並加以解析，並傳遞給各個回放 工作線程進行並發的數據更新。 Follower 的並發回放可以有多種方式，包括按照 Leader 上的 Group Commit 維度或者是按照表級別的維度，未來會引入 最新的 writeset 方式來精確控制最大並發。

Failover

X-Cluster 只要半數以上的節點存活就能保證集群正常對外服務。 因此當少數的 follower 節點故障時並不影響集群的服務能力。當 Leader 節點故障時會 自動觸發集群的重新選主流程。 選主流程由 X-Paxos 驅動，在 Paxos 協議的基礎上，結合優先順序推選出新的 Leader 節點。

對於 X-Cluster 而言，failovertime = electiontime + apply_time electiontime 代表協議選主的時間，一般在 10s 左右， applytime 是數據應用日誌的時間，取決於回放的速度，優秀的並行回放演算法能把應用日誌的時間 控制在非常短的時間之內。

相對來說之下 Leader 節點故障是一個相對複雜的場景，故障包括了宕機、網路隔離等等。

如上圖所示，一個經典的三節點的 X-Cluster 集群，左邊的 Case 是原 Leader A 節點宕機，因此 B 節點和 C 節點會在較長的時間內收不到 Leader 的心跳，因此在 一個選舉超時周期後，B 節點開始嘗試推選自己為 Leader， 並且 C 節點同意， 那麼 B 成為新的主節點，恢復服務能力。

右邊的 Case 是原 Leader A 節點發生網路分區，此時在選舉超時後，BC 兩個節點的行為和之間的 Case 類似。 A 節點由於無法將心跳和日誌發送給 BC 兩個節點在超時後會降級，然後不斷嘗試選自己為 Leader，但是因為沒有其他節點的同意，達不成多數派，一直都不會成功。當網路分區恢復後，A 收到 B 節點的心跳，觸發 Leader stickness 機制，A 節點加回集群。

為什麼 MySQL 的 Galera 和 Group Replication 方案並不足夠？

在傳統的 Master-Slave 下數據一致性和可用性是很難同時保證的，並且很容易在網路分區時產生腦裂的問題。過去，DBA 們更多的使用的是回滾回補方式來盡量保證節點數據的一致性，但是對於用戶來說，更新丟失，stall read 這樣的問題很難避免。 Paxos 和類 Paxos 協議是目前已經論證的解決分散式一致性問題最好的手段。曾經很多開發者使用 Zookeeper 或者 etcd 這樣的提供一致性能力的組件來做 Master-Slave 的仲裁。這樣的方式能避免腦裂，但是依然無法解決上述數據回滾回補以及用戶可能會遇到的不一致問題。

這兩年，有開發者嘗試將協議和資料庫做深度整合。 目前市面上開源的 Paxos 協議庫多是一體化的日誌 / 狀態機 / 協議 實現，這樣協議庫要記錄一份狀態機、日誌，資料庫要維護一份數據和日誌，對於整體系統來說是冗餘和低效的。X-Paxos 有插件化的狀態機和日誌實現，提供了一種更為高效的接入方式。除此之外 X-Paxos 本身對於 WAN 下的傳輸同步效率是很高的，這也給 X-Cluster 在跨域部署下的性能打下了良好的基礎。

阿里希望的是高性能、低成本、能提供數據強一致能力，可以承擔阿里巴巴巨大體量電商系統業務的資料庫系統。

X-Cluter、Galera、Group Replication 三種方案相比而言：Galera 是先驅，然而從實現原理以及目前的表現上上無法支持阿里的目標。GR 是官方出品但 GA 時日尚短，這兩個開源的產品在功能和性能上在實測評估中無法滿足阿里的要求。

這三者之間是有明顯的相同點和不同點的。這三個產品都是為了解決數據強一致問題的基於 MySQL 的高可用解決方案。都是通過類 binlog event 的方式進行複製，同樣只支持事務引擎，failover 對於運維友好。

然而他們之間的不同點也是非常多了。首先是從同步協議上，Galera 採用的是 Totem 演算法，而 GR 和 X-Cluster 是採用的 Paxos，因此 Galera 需要每個節點都接受 writeset 後才能提交，而 GR 和 X-Cluster 一樣採用多數派 ack 即可提交的方式。Galera 和 GR 支持多點寫入（雖然衝突嚴重很容易導致事務失敗）而 X-Cluster 是單點寫入系統。Galera 和 X-Cluster 是明確支持 WAN 部署的，而 GR 在 WAN 下則是不被推薦的。Galera 和 GR 都是 All nodes have all data 系統， X-Cluster 還提供低成本的 node have no data 的選項。GR 支持最多 9 個節點，X-Cluster 支持 99 個一致性節點而 Galera 支持的更多的節點（雖然意義不大）。

運維方面：Galera 和 X-Cluster 支持分區節點自動恢復而 GR 需要手動運維；

性能方面：Galera 集群性能取決於最慢的節點，這不滿足對於低延時、異地容災部署的需求。

而且，Galera 的同步使用 GCache，而不是 binlog，這對於已有的外部配套系統不是很友好，如果同時又開啟 binlog 的話會額外付出存儲和 IO 的代價。GR 對於分區的運維不夠友好，被隔離的節點無法自動加回集群， 在 WAN 下表現一般，官方也不推薦在這種網路環境下的部署。 X-Cluster 繼承了 AliSQL 的優勢，又特別優化了 WAN 下的性能。對於同一行數據更新，相比 Galera 和 GR 的表現，而 X-Cluster 的性能完全滿足阿里的預期，這在類似於秒殺的場景下會非常有用。除此之外，X-Cluster 繼承於 AliSQL，因此除了支持 InnoDB 引擎之外還支持 Rocksdb 引擎，可以有效的優化存儲成本。

阿里還進行了 AliSQL X-Cluster 性能表現的測試，測試使用了三節點部署方式，分別在同城三機房、跨城三機房的網路環境下進行了測試，測試工具使用標準的 Sysbench 的 insert/oltp。

Insert 測試下，並且每個事務中只包含一條插入語句，屬於密集的小事務場景， 而相反的 OLTP 是讀寫大事務。 針對熱點環境，測試的場景是改造update_nonindex ， 使更新同一行數據。 只讀場景不在本次測試的範疇內，原因是只讀不涉及到節點的日誌、數據同步，因此可以認為只讀測試對分散式系統是沒有意義的。

Sysbench 主要是針對寫以及讀寫混合場景下的測試，數據量為 10 張表，每張表 20 萬記錄。測試同域下的集群，Insert 使用 300 並發線程、 OLTP 使用 400 並發線程， 熱點更新使用 300 並發線程。

備註：最新的單機版 MySQL 5.7.19 以及該版本下的 Group Replication。Group Replication 在測試中關閉限流，測試機均是 64core 512G 內存 PCIE SSD。

7

作者簡介

江疑，10+ 年 Linux C/C++ 底層研發經驗，資料庫內核研發經驗。長期從事 MySQL 內核研發，分散式資料庫研發工作。同時作為資料庫內核負責人多次參加阿里巴巴雙十一購物節。AliSQL 項目主要開發人員，主導阿里的分散式強一致協議 X-Paxos 開發工作。

胡煒，2016 年加入阿里巴巴，資料庫技術團隊 AliSQL 內核貢獻者，X-Cluster 的核心開發成員。畢業於浙江大學，專攻資料庫方向。從業以來一直深耕於資料庫領域，擅長 RDBMS, NOSQL 等技術方向。

今日薦文

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！