阿里10年分佈式數據庫技術沉澱，AliSQL X-Cluster的應用實戰

MySQL 數據庫從誕生以來就以簡單、易用、開源爲主打特色，成爲很多開發者首選的數據庫系統。阿里集團在 2008 年開始提出"去 IOE"的口號，邁入了  MySQL 數據庫的時代。系統使用大量的 MySQL，配合業務的改造替代原有的商業版 Oracle 系統。根據阿里交易型應用的特色，以及雙十一這樣業界罕有的需求推進下，咱們在官方的 MySQL 基礎上增長了很是多實用的功能、性能補丁，打造了 AliSQL 這個  MySQL 分支品牌。

時間很快走到 2014 年，隨着業務高速的增加，同城主備 AliSQL   部署的方式已經沒法知足阿里對可擴展的部署、國際化以及容災方面的需求。「異地多活」成爲了公司應用的新標準。「異地多活」也給底層的數據庫提出了新的容災要求。傳統的 Master-Slave   架構下，主備若是不使用強同步模式就會存在數據丟失的可能，然而強同步下一旦有節點異常則總體不可服務。並且，這套架構下須要 HA 工具來進行選主的仲裁和控制。過去阿里 DBA 們開發了高效可靠的 HA  以及一整套工具和流程來作主備切換後數據和日誌的校驗和訂正。

咱們相信技術的發展能帶來更大的運維便利性以及更好的用戶體驗，以 Google Spanner 以及 Amazon Aruora 爲表明的 NewSQL  系統爲數據庫的數據一致性給出了與以往不一樣的思路：基於一致性協議搭建分佈式的多副本數據庫。

AliSQL X-Cluster 介紹

AliSQL X-Cluster(本文中簡稱 X-Cluster)是阿里巴巴數據庫團隊推出的兼容 MySQL  5.7，提供數據強一致功能，支持全球部署的分佈式數據庫集羣產品。

說到 AliSQLX-Cluster 就不能不提其分佈式核心和一致性協議。

X-Paxos 是阿里巴巴自主研發的一致性協議庫，目標是填補市面上高性能、易接入的一致性協議庫的空白。而市面上已開源的一致性協議實現，包括 etcd  以及其餘廠商等都存在或性能不夠或功能上沒法知足複雜的現實應用場景需求的問題。

有了 X-Paxos，可基於它打造一套強一致的分佈式系統，X-Cluster 是第一個接入 X-Paxos 生態的重要產品，利用 X-Paxos  實現了自動選主，日誌同步，集羣內數據強一致，在線集羣配置變動等功能。

同時 X-Cluster 基於 MySQL 生態，兼容最新版本的 MySQL 5.7，集成了 AliSQL 過去的各類功能加強。MySQL  的用戶能夠零成本遷移到 X-Cluster 上。

AliSQL X-Cluster 的總體架構

先來看一下 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 而言，failover_time =election_time + apply_time。

election_time 表明協議選主的時間，通常在 10s 左右;apply_time  是數據應用日誌的時間，取決於回放的速度，優秀的並行回放算法能把應用日誌的時間控制在 10s 以內。

相對來講 Leader 節點故障之下是一個相對複雜的場景，故障包括了實例崩潰、服務器宕機、網絡隔離等等。

如上圖所示，一個三節點的 X-Cluster 集羣，左邊的 Case 是原 Leader A 節點宕機，所以 B 節點和 C 節點會在較長的時間內收不到  Leader 的心跳。

所以在一個選舉超時週期後，B 節點開始嘗試推選本身爲 Leader，而且 C 節點贊成後，B 會成爲新的主節點，恢復其服務能力。

右邊的 Case 是原 Leader A 節點發生網絡分區，此時在選舉超時後，BC 兩個節點的行爲和之間的 Case 相似。

A 節點因爲沒法將心跳和日誌發送給 BC   兩個節點在超時後會降級，而後不斷嘗試選本身爲主，可是由於沒有其餘節點的贊成，達不成多數派，一直都不會成功。當網絡分區恢復後，A 收到 B 節點的心跳，觸發  Leader stickness 機制，A 自動加回集羣。

AliSQL X-Cluster 的優化特性

X-Cluster 擁有一系列的新功能和特性，以知足不一樣類型的應用對於功能和性能上的需求。

跨地域部署

X-Cluster  的一個顯著功能就是可以支持跨地域部署，在跨域的狀況下也能保證集羣數據強一致，擁有城市級容災的能力。即便某個城市的機房所有宕機，只要保證集羣多數派節點存活，全部的數據都不會丟失。

依賴 X-Paxos 以及數據庫內核中異步化工做線程的改造，在數十毫秒的網絡 RTT(RoundTrip Time)下，X-Cluster  依然有很是高的吞吐性能。

擁有了跨地域部署的能力，X-Cluster  的部署方式是很是靈活的。業務能夠根據實際的業務狀況以及不一樣的容災級別需求，選擇同機房容災、機房容災、城市容災部署，而且能夠在不一樣的容災級別之間靈活切換。

集羣的動態配置和選舉

X-Cluster 支持在線集羣配置變動，包括：

• 增長節點下線節點。

• 修改節點類型爲一致性節點或者是隻讀節點。

• 修改節點優先級。

• 修改集羣的 Leader。

• 修改只讀節點複製源。

全部的上述修改配置的過程是在線進行的，不會阻塞業務的正常運行，集羣配置的變化也會嚴格按照 Paxos  協議進行，記錄日誌而且推進對應的狀態機變動，還有完善的恢復機制。

保證最終集羣內配置達成一致，不會由於集羣配置變動過程當中的異常致使腦裂或者其餘配置出現終態不一致的問題。

X-Cluster 集羣的節點從功能上看有兩個類型，包括參與選主與多數派協議的一致性協議節點還有隻讀節點。一致性協議節點是 X-Cluster  的基礎。

目前一個 X-Cluster 集羣支持至少 1 個一致性節點，至多 99  個一致性節點。只讀節點能夠無限擴展。用戶能夠從一開始的單節點集羣開始，後續不斷根據需求擴展不一樣類型的節點。

優先級

應用每每對於容災後新主節點是有要求的，在原先的主節點意外宕機後，新主若是落在了一個低規格的節點，那麼對於應用來講是很難接受的服務降級。

X-Cluster 支持同一個集羣中的節點擁有不一樣的優先級，用戶能夠根據實際的部署須要，在配置集羣時爲每一個實例節點設置優先級。

優先級功能主要包括如下兩方面：

• 權重化選主。

• 策略化多數派。

權重化選主表明選主的順序權重。只要在選舉的時候沒有網絡隔離，選舉 Leader  的順序會按照集羣存活節點的權重順序進行。權重越高的節點，就有更大的優先級被選爲 Leader。

咱們實現了兩段式的選舉時間，第一階段是集羣內統一的租約時間，而第二階段是根據權重來決定，權重越大的節點時間越短，也就是會越早發起自選舉。

除此以外，還有一重權重檢測機制來保證權重優先級，節點上任意時間會廣播檢測一遍全部可以聯通的集羣內節點，若是發現權重更高的節點會主動發起一次 Leader  Transfer 將 Leader 角色過繼過去的命令。

權重化選主在跨地域部署的場景下尤爲重要。跨地域的部署業務和數據庫之間的訪問延時會很是敏感，若是 Leader   節點隨機的切換到了另外一個地域的機房可能會致使應用大規模的訪問異地實例，大幅增長客戶端的響應時間。權重化選主能夠完美解決此問題。按照應用的部署需求進行動態設置，很是靈活。

策略化多數派是指在事務提交日誌同步過程當中，哪些節點必需要日誌複製完成。複製優先級分爲兩檔，強複製和弱複製。標準的 Paxos 只要超過半數的節點同步日誌便可推動狀態機，可是因爲每一個鏈接會自動分配路由的問題，可能在跨 Region 的訪問中 RTT  時間會有偏差。

爲了縮短網絡/節點故障後，按照選主優先級從新選主並繼續服務的時間間隔，咱們能夠配置在規定日誌複製到多數節點的基礎上必須還要複製到全部強複製的節點才能夠推動狀態機並返回客戶端事務提交成功的響應。這是一個類 Max protection 模式的設計，若是檢測到強一致節點的宕機，可選擇適當的降級。

低成本副本管理

在 X-Cluster 中，副本按照是否有數據狀態機分爲兩類：

• 普通型(Normal)。

• 日誌型(Log)。

普通型擁有所有的功能;日誌型只擁有日誌不包含數據。若是日誌型節點仍是一個參與 Paxos 投票的一致性節點，那麼它只有投票權，沒有被選舉權。

之因此要建立不一樣類型的副本，仍是出於應用需求以及成本控制的考慮。相比傳統的兩節點主備複製，X-Cluster 的常規同城部署方式是三節點。

日誌型副本是做爲下降部署成本的一種選擇。日誌型副本只存儲日誌，不須要存儲數據，也不須要回放日誌更新數據。

所以不管是存儲仍是 CPU 的開銷，日誌型副本相比普通副本都有很大的優點。在實際應用規劃中，很是適合用來做容災型的節點部署。

只讀節點管理

如上圖所示，X-Cluster 集羣中的只讀節點能夠從任何一個一致性節點複製日誌，這不只是考慮到若是全部節點的日誌都從 Leader 節點複製會對  Leader 節點形成過大的網絡和 IO 瓶頸。

並且因爲跨區域部署下不一樣地域的數據狀態機可能會有延時，設置了讀寫分離的用戶在特定的場景下須要有特定的只讀狀態延時的要求。

可是這時的問題就是若是某個一致性節點發生了宕機，那麼和它創建複製關係的只讀節點應該如何進行災備聯動?

做爲一個自運維的數據庫服務，X-Cluster 天然要解決好這個問題。X-Cluster 定義了 Learner Source Group。每一個  Group 是一個只讀節點的容災單元。

當 Group 內某個一致性節點發生意外情況(宕機或者網絡隔離)，集羣會根據 Group 的配置，將掛載在故障節點下的只讀節點配置到 Group  中另一個正常工做的節點下進行數據同步。

高性能日誌

MySQL 系統在開啓主備複製的狀況下，除了會記錄 Binlog 以外，在備庫上還會記錄一份 RelayLog，即從庫經過指定對應主庫的 Binlog  位置去同步一份二進制日誌寫入 RelayLog 供複製線程讀取和回放。

在 X-Cluster 中，只使用一份日誌進行節點間的同步，利用 X-Paxos 的插件式日誌模塊的特性，每一個節點有一份 Consensus  日誌。

這樣既方便了對 Consensus 日誌的管理，也下降了日誌存儲以及讀寫的開銷。

Consensus Log 擁有 Append，Get，Truncate 以及 Purge 等基本接口，它的控制權完整地交給了 X-Paxos，由  X-Paxos 進行控制。

除此以外，X-Cluster 爲 Consensus Log  設計了日誌索引和日誌緩存、預讀機制，極大的提高了日誌模塊的性能以保證一致性協議運做的高效性。

異步化事務提交

傳統的 MySQL 都是 One Thread perConnection  的工做模式，在引入線程池後是以一個線程池孵化必定數量的工做線程，每一個線程負責處理一次 query 的解析、優化、修改數據、提交、回傳網絡包等等。

集羣須要跨地域部署下，一次事務的提交因爲須要在集羣之間同步事務日誌，受限於網絡的 RTT  的限制，會達到數十毫秒的級別，那麼對於一個普通的寫事務來講，大量的時間會耗費在同步節點日誌等待事務提交的過程。

在大壓力下，很快數據庫內部的工做線程會耗盡，吞吐達到瓶頸。若是一味的放大數據庫內部的工做線程數目，那麼線程上下文的代價會大幅增長。

若是將整個事務的提交異步化，將工做線程從等待 X-Paxos 日誌同步中解放出來，去處理新的鏈接請求，在大負載下能夠擁有更高的處理能力。

異步化改造的說明示意圖以下所示：

X-Cluster 的異步化提交核心思想是將每一個事務的請求分紅兩個階段：

• 提交以前階段。

• 提交和回包階段。

兩個階段均可以由不一樣的工做線程來完成。爲了完成異步化的改造，X-Cluster  增長了等待同步隊列和等待提交隊列，用於存儲處於不一樣階段的事務。前者隊列中的事務是等待 Paxos 多數派日誌同步的事務，後者是等待提交的事務。

當用戶發起 Commit/Rollback/XA_Prepare 時，處理用戶鏈接的線程池 Worker  產生事務日誌並將事務上下文存儲到等待同步的隊列中。等待同步隊列的消費由少許數目的 Worker 線程來完成，其他工做線程能夠直接參與其餘任務的處理。

事務等待多數派完成後會被推入等待提交隊列。這個隊列裏的事務都是能夠被當即提交的。全部的 Worker  線程發現該隊列裏有事務，就能夠順道取出來執行提交操做。

這樣一來，系統中只有少數的線程在等待日誌同步操做，其他的線程能夠充分利用 CPU 處理客戶端的請求。

X-Cluster 以這樣的思路爲指導原則，結合 MySQL 的 Group Commit 邏輯，將原有須要等待的操做所有異步化，讓 Worker  線程能夠去執行新的請求響應。

在測試中，異步化改造在同城部署的場景中相比同步提交有 10% 的吞吐率提高，跨區域的部署後有幾倍的吞吐提高。

熱點更新

熱點更新本來就是數據庫的一個難題，受制於行鎖競爭，性能吞吐一直很難提高上去。X-Cluster  面對跨域場景下的長傳網絡更加是雪上加霜，提交的時間變長，事務佔據行鎖的時間也顯著增長。

爲了解決此問題，X-Cluster 在單機版 AliSQL 的熱點功能之上優化了複製，使得在保證數據強一致的狀況下，熱點更新性能提高 200 倍。

如上圖所示，X-Cluster 針對熱點行更新的基本思路是合併多個事務對同一行的更新。

爲了讓批量的更新事務可以同時進行提交，X-Cluster 增長了一種新的行鎖類型——熱點行鎖。在熱點行鎖下，熱點更新的事務之間是相容的。

X-Cluster 爲了保證數據的一致性，對同一批的熱點更新事務日誌打上特殊標誌，X-Paxos  會根據這些標誌將這一整批事務的日誌組成一個單獨的網絡包進行集羣間的數據同步，保證這些事務是原子的提交/回滾。

除此以外爲了提高日誌回放的效率，X-Cluster 將每一個批次事務中對於熱點行的更新日誌也作了合併。

一體化的客戶端和服務端

X-Cluster 有完整的 Client-Server 生態。因此整個系統不須要外部組件的介入，可以自封閉的成爲一個生態閉環。做爲客戶端的  X-Driver 可以訂閱 Server 端發生的一切改變，從而進行自動尋主，實例列表動態維護等功能。

客戶端的元數據就保存在 X-Cluster  服務內部。相比外置的元數據中心，這套自封閉體系可以以最快的時間獲取到準確的集羣變化，下降集羣變動對用戶的感知程度。

優化的備份以及數據訂閱體系

基於強大的 X-Paxos 體系，日誌備份以及數據訂閱系統都可以以日誌訂閱者的方式接入進來。

因爲有了 X-Paxos 的全局惟一位點的支持，這些訂閱系統的 Failover 不會再有難以找到準確位點的困擾。並且因爲 X-Paxos  是流式的推送日誌消息，所以數據的實時性也能大幅改進。

AliSQL X-Cluster 的實戰部署方案

X-Cluster 最爲經典的兩個部署方案是同城三副本，兩份數據一份日誌，以及跨地域 5 副本，四份數據一份日誌。

它們分別用於知足機房級容災和城市級容災需求。這裏的副本概念指的都是一致性節點的部署，只讀節點部署不影響容災能力。

這兩類經典的部署方案都是考慮了可用性以及成本之間的權衡，以較小的代價換來目標的容災能力。

如上圖，X-Cluster  的同城部署三副本可以方便的實現零數據丟失的實例容災以及機房級容災。相比主備方式，額外增長了一個日誌節點，換取強一致以及可用性。

如上圖，三地五實例(四數據、五日誌)可以保證城市級容災，任何一個城市的節點所有宕機都不會影響到集羣可用性，5 個節點中至少還有 3  個節點可以正常運行。

在平常運行中，5 節點在每次事務提交的時候一定須要將日誌同步到 3 個節點，所以必然會出現一次跨域的網絡同步，這也就是長傳鏈路網絡場景，X-Cluster  對於慢網絡的優化正是應對相似這樣的需求。

AliSQL X-Cluster 的性能表現

咱們使用了三節點部署的方式，分別在同域三機房、跨域三機房的網絡環境下進行了測試。

測試工具使用標準的 Sysbench 的 insert/oltp，在 Insert  測試下，而且每一個事務中只包含一條插入語句，屬於密集的小事務場景，而相反的 OLTP 是讀寫大事務。

針對熱點環境，測試的場景是改造 update_non_index  ，使其更新同一行數據。只讀場景不在本次測試的範疇內，緣由是隻讀不涉及到節點的日誌、數據同步。

所以能夠認爲只讀測試對於 X-Cluster 這樣的分佈式系統是沒有意義的。全部的測試，數據量爲 10 張表，每張表 20 萬條記錄。

做爲對比，咱們使用了最新的開源單機版 MySQL 5.7.19 以及該版本下的 Group Replication。Group Replication  在測試中關閉限流，測試機均是 64core 256G 內存 PCIE SSD。

測試同域下的集羣，Insert 咱們使用 300 併發線程、 OLTP 使用 400 併發線程，熱點更新使用 300 併發線程。

在同一個域下，X-Cluster 的吞吐和響應時間表現都是很是出色的，甚至略好於單機版本的 MySQL 5.7.19。

相比 Group Replication，在本次測試的壓力下，Insert case X-Cluster 有超過一倍的吞吐以及 55%  左右的響應時間，OLTP case X-Cluster 有超過 5% 的吞吐以及接近 70% 的響應時間表現。

測試跨域下的集羣須要大量的鏈接來保證吞吐，所以 Insert 使用 2000 併發線程，OLTP 使用 700 併發線程，熱點更新使用 2500  併發線程。

當集羣部署在不一樣域時，X-Cluster 和 Group Replication  相比同域的部署下吞吐都有降低，響應時間受到物理網絡延遲的影響也有顯著提升。

然而在 Insert case 下，X-Cluster 仍然能夠領先 Group Replication 5 倍，響應時間只有 GR 的四分之一。OLTP  case 下，X-Cluster 的吞吐領先 Group Replication 接近 4 倍，響應時間只有三分之一。

熱點更新是 X-Cluster 的一大亮點功能，根據測試結果，不管是同域仍是跨域部署， X-Cluster 的吞吐和響應時間表現都要遠遠超過單機  MySQL 和 Group Replication。

AliSQL X-Cluster 的正確性保障

分佈式系統的測試是很是複雜的，由於沒有人可以經過窮舉來羅列全部可能出現的狀況。

簡單的接口測試和性能迴歸也只能覆蓋一小部分場景，沒法衡量一個分佈式系統版本的質量。只有日復一日的測試以及線上系統的正常運行可以真正地說明分佈式系統的魯棒性。

X-Cluster 最大的挑戰就是保證基於分佈式一致性協議實現的正確性。通過實踐證實，灰盒測試是最有效的手段。

X-Cluster 集成了 X-Paxos，X-Paxos 項目自己有一系列的測試框架用於發現和迴歸。除此以外，X-Cluster 基於  tc、systemtap 等工具構建了多種多樣模擬網絡異常、實例宕機、I/O 異常的環境。

在這套環境下網絡分區、丟包、各類 I/O 異常，各類實例宕機能夠隨機組合。同時使用 benchmark  工具對每一個節點施加大壓力的讀寫，按期的去校驗集羣中不一樣節點的數據以及日誌的一致性。

一致性相關全部的操做都會記錄在 X-Cluster  專門的日誌中，方便追溯集羣節點間的交互行爲。數據和日誌的最終一致性校驗由外部系統來完成。阿里內部有專門的分片校驗系統能夠作 X-Cluster  不一樣節點的全量數據校驗。

Consensus 日誌解析工具能夠快速解析日誌內容進行比對。這套測試環境幫助咱們發現了很是多的系統 Bug，包括實例恢復的 Bug，網絡異常致使的  Bug 等等。

咱們認爲一個穩定版本的標準是必定須要經過這個場景長時間的測試，而且各類表現要符合預期。

除了數據和日誌的最終一致性，對於數據的線性一致，事務隔離性，咱們引入了 Jepsen 工具。

Jepsen 幫助大量分佈式系統發現了分佈式協議和實現的正確性問題。咱們爲 X-Cluster  專門構造了一系列的測試用例來儘量覆蓋各類異常場景，來發現系統在隔離性和一致性上的問題。

AliSQL X-Cluster與同類的對比

AliSQL X-Cluster 不是第一個基於 MySQL  的強一致集羣方案，然而是最適合阿里這樣體量公司的數據庫解決方案。對比下面這些同類產品：

Galera

Galara 是 MariaDB 支持的 MySQL 集羣版本，支持強同步，支持多點寫入，自動的集羣配置以及節點  Failover，支持行級別的並行複製，支持原生的 MySQL 客戶端。

在這套架構下，Slave 不會有延時，任意節點讀到的都是一致數據，不會有事務數據丟失，讀寫可擴展。

Galera 的集羣通訊用了一種基於單令牌環的 Totem  組播協議。爲了能支持多點寫入，主機在收到寫請求後，會原子廣播到組內全部的機器，由它們各自的事務管理層來決定是否提交或者回滾。

組播因爲是 P2P 的通訊，隨着節點數增長，延時會放大，響應時間會變慢，而且只適用於低延時的局域網。

除此以外，組播還有一個問題，若是組內的某臺機器宕機，組播會超時，在踢掉 fail 的機器從新肯定組內成員關係以前，整個集羣不可服務。

Galera 採用了專門的文件 gcache 進行增量狀態複製，gcache 不作任何他用，所以 gcache  自己須要額外的計算和存儲代價進行維護。

Group Replication

Group Replication 是 MySQL 官方出品的集羣方案。Group Replication 借鑑了 Galera  的思想，一樣支持多主多點寫入。

Group Replication 實現了一個 X-COM 的通訊層，它在新版本中已經使用了 Paxos 算法。目前一個 GR 集羣中最多能夠有 9  個節點，響應延時相對穩定，在節點同步日誌層面，GR 使用 Binlog，相比 Galera 更加的通用。

Group Replication 的協議層複製是 XCOM，且在複製中強依賴  GTID。在測試中的性能表現，特別是跨域部署下還達不到需求，目前的版本中也仍然有大量的 Bug  在修復，徹底可用於生產環境還有待後續版本的穩定性和性能提高。

總結

X-Cluster 是針對數據質量要求較高的用戶推出的全新的數據庫解決方案。

X-Cluster 不只可以享受到開源社區帶來的紅利，其中涉及一致性的關鍵技術也可以作到徹底的自主、可控，可以針對業務的需求進行靈活的變動。

將來 X-Cluster 會在此基礎上作更多的優化，例如支持多分片的 Paxos，多節點提供強一致讀等功能。

隨着 X-Paxos 和 AliSQL 的不斷進化，X-Cluster 也會給你們帶來更多的驚喜。

參考文獻

1.Group Replication is GA with MySQL 5.7.17 – comparison with Galera  http://lefred.be/content/group-replication-vs-galera/ 2.MySQL HighAvailability Blog http://mysqlhighavailability.com/tag/mysql-group-replication/ 3.Introduction to Galera https://www.slideshare.net/henrikingo/introduction-to-galera 4.GALERA CLUSTER DOCUMENTATION http://galeracluster.com/documentation-webpages/

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