【51CTO.com原創(chuàng)稿件】MySQL 數據庫從誕生以來就以簡單、易用、開源為主打特點，成為不少開發(fā)者***的數據庫系統(tǒng)。阿里集團在 2008 年開始提出"去 IOE"的口號，邁入了 MySQL 數據庫的時代。系統(tǒng)使用大量的 MySQL，配合業(yè)務的改造替代原有的商業(yè)版 Oracle 系統(tǒng)。根據阿里交易型應用的特點，以及雙十一這樣業(yè)界罕有的需求推動下，我們在官方的 MySQL 基礎上增加了非常多實用的功能、性能補丁，打造了 AliSQL 這個 MySQL 分支品牌。

時間很快走到 2014 年，隨著業(yè)務高速的增長，同城主備 AliSQL 部署的方式已經無法滿足阿里對可擴展的部署、國際化以及容災方面的需求。“異地多活”成為了公司應用的新標準。“異地多活”也給底層的數據庫提出了新的容災要求。傳統(tǒng)的 Master-Slave 架構下，主備如果不使用強同步模式就會存在數據丟失的可能，然而強同步下一旦有節(jié)點異常則整體不可服務。而且，這套架構下需要 HA 工具來進行選主的仲裁和控制。過去阿里 DBA 們開發(fā)了高效可靠的 HA 以及一整套工具和流程來做主備切換后數據和日志的校驗和訂正。

我們相信技術的發(fā)展能帶來更大的運維便利性以及更好的用戶體驗，以 Google Spanner 以及 Amazon Aruora 為代表的 NewSQL 系統(tǒng)為數據庫的數據一致性給出了與以往不同的思路：基于一致性協(xié)議搭建分布式的多副本數據庫。

AliSQL X-Cluster 介紹

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

說到 AliSQLX-Cluster 就不能不提其分布式核心和一致性協(xié)議。

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

有了 X-Paxos，可基于它打造一套強一致的分布式系統(tǒng)，X-Cluster 是***個接入 X-Paxos 生態(tài)的重要產品，利用 X-Paxos 實現了自動選主，日志同步，集群內數據強一致，在線集群配置變更等功能。

同時 X-Cluster 基于 MySQL 生態(tài)，兼容***版本的 MySQL 5.7，集成了 AliSQL 過去的各種功能增強。MySQL 的用戶可以零成本遷移到 X-Cluster 上。

AliSQL X-Cluster 的整體架構

先來看一下 X-Cluster 的基本架構：

上圖展示的是一個部署三個實例的 Cluster 集群。X-Cluster 是一個單點寫入，多點可讀的集群系統(tǒng)。在同一時刻，整個集群中至多會有一個 Leader 節(jié)點來承擔數據寫入的任務。

相比多點寫入，單點寫入不需要處理數據集沖突的問題，可以達到更好的性能與吞吐率。

X-Cluster 的每個實例都是一個單進程的系統(tǒng)，X-Paxos 被深度整合到了數據庫內核之中，替換了原有的復制模塊。集群節(jié)點之間的增量數據同步完全是通過 X-Paxos 來自驅動，如何復制，從哪個點回放不再需要運維人員或者外部工具來介入。

X-Cluster 為了追求***的性能，利用 MySQL 的 Binlog 進行深度改造和定制來作為 X-Paxos 的 Consensus 日志，實現了一系列的 X-Paxos 日志接口，賦予 X-Paxos 直接操縱 MySQL 日志的能力。

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

事務提交、復制流程

X-Cluster 的復制流程是基于 X-Paxos 驅動 Consensus 日志進行復制。

Leader 節(jié)點在事務 prepare 階段會將事務產生的日志收集起來，傳遞給 X-Paxos 協(xié)議層后進入等待。X-Paxos 協(xié)議層會將 Consensus 日志高效地轉發(fā)給集群內其他節(jié)點。

當日志在超過集群半數實例上落盤后， X-Paxos 會通知事務可以進入提交步驟。否則如果期間發(fā)生 Leader 變更，prepare 的事務會根據 Paxos 日志的狀態(tài)進行相應的回滾操作。

相比原生 MySQL，日志傳輸采用了多線程、異步化、Batching、Pipelining 等優(yōu)化手段，特別是在長傳鏈路的場景中，效率提升明顯。

Follower 節(jié)點也使用 X-Paxos 進行日志的管理操作，為提升接收效率，收到 Leader 傳遞過來的日志以后將日志內容 Append 到 Consensus Log 末尾，Leader 會異步的將達成多數派的日志的消息發(fā)送給 Follower。

Follower 的協(xié)調者線程會負責讀取達成多數派的日志并加以解析，并傳遞給各個回放工作線程進行并發(fā)的數據更新。

Follower 的并發(fā)回放可以有多種方式，包括按照 Leader 上的 Group Commit 維度或者是按照表級別的維度，未來會引入***的writeset方式來精確控制***并發(fā)。

Failover

X-Cluster 只要半數以上的節(jié)點存活就能保證集群正常對外服務。因此當出現少數的follower節(jié)點故障時并不影響集群的服務能力。

當 Leader 節(jié)點故障時會自動觸發(fā)集群的重新選主流程。選主流程由 X-Paxos 驅動，在 Paxos 協(xié)議的基礎上，結合優(yōu)先級推選出新的 Leader 節(jié)點。

對于 X-Cluster 而言，failover_time =election_time + apply_time。

election_time 代表協(xié)議選主的時間，一般在 10s 左右;apply_time 是數據應用日志的時間，取決于回放的速度，優(yōu)秀的并行回放算法能把應用日志的時間控制在 10s 之內。

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

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

因此在一個選舉超時周期后，B 節(jié)點開始嘗試推選自己為 Leader，并且 C 節(jié)點同意后，B 會成為新的主節(jié)點，恢復其服務能力。

右邊的 Case 是原 Leader A 節(jié)點發(fā)生網絡分區(qū)，此時在選舉超時后，BC 兩個節(jié)點的行為和之間的 Case 類似。

A 節(jié)點由于無法將心跳和日志發(fā)送給 BC 兩個節(jié)點在超時后會降級，然后不斷嘗試選自己為主，但是因為沒有其他節(jié)點的同意，達不成多數派，一直都不會成功。當網絡分區(qū)恢復后，A 收到 B 節(jié)點的心跳，觸發(fā) Leader stickness 機制，A 自動加回集群。

AliSQL X-Cluster 的優(yōu)化特性

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

跨地域部署

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

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

擁有了跨地域部署的能力，X-Cluster 的部署方式是非常靈活的。業(yè)務可以根據實際的業(yè)務情況以及不同的容災級別需求，選擇同機房容災、機房容災、城市容災部署，并且可以在不同的容災級別之間靈活切換。

集群的動態(tài)配置和選舉

X-Cluster 支持在線集群配置變更，包括：

• 增加節(jié)點下線節(jié)點。
• 修改節(jié)點類型為一致性節(jié)點或者是只讀節(jié)點。
• 修改節(jié)點優(yōu)先級。
• 修改集群的 Leader。
• 修改只讀節(jié)點復制源。

所有的上述修改配置的過程是在線進行的，不會阻塞業(yè)務的正常運行，集群配置的變化也會嚴格按照 Paxos 協(xié)議進行，記錄日志并且推動對應的狀態(tài)機變更，還有完善的恢復機制。

保證最終集群內配置達成一致，不會因為集群配置變更過程中的異常導致腦裂或者其他配置出現終態(tài)不一致的問題。

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

目前一個 X-Cluster 集群支持至少 1 個一致性節(jié)點，至多 99 個一致性節(jié)點。只讀節(jié)點可以***擴展。用戶可以從一開始的單節(jié)點集群開始，后續(xù)不斷根據需求擴展不同類型的節(jié)點。

優(yōu)先級

應用往往對于容災后新主節(jié)點是有要求的，在原先的主節(jié)點意外宕機后，新主如果落在了一個低規(guī)格的節(jié)點，那么對于應用來說是很難接受的服務降級。

X-Cluster 支持同一個集群中的節(jié)點擁有不同的優(yōu)先級，用戶可以根據實際的部署需要，在配置集群時為每個實例節(jié)點設置優(yōu)先級。

優(yōu)先級功能主要包括以下兩方面：

• 權重化選主。
• 策略化多數派。

權重化選主代表選主的順序權重。只要在選舉的時候沒有網絡隔離，選舉 Leader 的順序會按照集群存活節(jié)點的權重順序進行。權重越高的節(jié)點，就有更大的優(yōu)先級被選為 Leader。

我們實現了兩段式的選舉時間，***階段是集群內統(tǒng)一的租約時間，而第二階段是根據權重來決定，權重越大的節(jié)點時間越短，也就是會越早發(fā)起自選舉。

除此之外，還有一重權重檢測機制來保證權重優(yōu)先級，節(jié)點上任意時間會廣播檢測一遍所有能夠聯(lián)通的集群內節(jié)點，如果發(fā)現權重更高的節(jié)點會主動發(fā)起一次 Leader Transfer 將 Leader 角色過繼過去的命令。

權重化選主在跨地域部署的場景下尤其重要?？绲赜虻牟渴饦I(yè)務和數據庫之間的訪問延時會非常敏感，如果 Leader 節(jié)點隨機的切換到了另一個地域的機房可能會導致應用大規(guī)模的訪問異地實例，大幅增加客戶端的響應時間。權重化選主可以***解決此問題。按照應用的部署需求進行動態(tài)設置，非常靈活。

策略化多數派是指在事務提交日志同步過程中，哪些節(jié)點必須要日志復制完成。復制優(yōu)先級分為兩檔，強復制和弱復制。標準的 Paxos 只要超過半數的節(jié)點同步日志即可推進狀態(tài)機，但是由于每個連接會自動分配路由的問題，可能在跨 Region 的訪問中 RTT 時間會有誤差。

為了縮短網絡/節(jié)點故障后，按照選主優(yōu)先級重新選主并繼續(xù)服務的時間間隔，我們可以配置在規(guī)定日志復制到多數節(jié)點的基礎上必須還要復制到所有強復制的節(jié)點才可以推進狀態(tài)機并返回客戶端事務提交成功的響應。這是一個類 Max protection 模式的設計，如果檢測到強一致節(jié)點的宕機，可選擇適當的降級。

低成本副本管理

在 X-Cluster 中，副本按照是否有數據狀態(tài)機分為兩類：

• 普通型(Normal)。
• 日志型(Log)。

普通型擁有全部的功能;日志型只擁有日志不包含數據。如果日志型節(jié)點還是一個參與 Paxos 投票的一致性節(jié)點，那么它只有投票權，沒有被選舉權。

之所以要創(chuàng)建不同類型的副本，還是出于應用需求以及成本控制的考慮。相比傳統(tǒng)的兩節(jié)點主備復制，X-Cluster 的常規(guī)同城部署方式是三節(jié)點。

日志型副本是作為降低部署成本的一種選擇。日志型副本只存儲日志，不需要存儲數據，也不需要回放日志更新數據。

因此無論是存儲還是 CPU 的開銷，日志型副本相比普通副本都有很大的優(yōu)勢。在實際應用規(guī)劃中，非常適合用來作容災型的節(jié)點部署。

只讀節(jié)點管理

如上圖所示，X-Cluster 集群中的只讀節(jié)點可以從任何一個一致性節(jié)點復制日志，這不僅是考慮到如果所有節(jié)點的日志都從 Leader 節(jié)點復制會對 Leader 節(jié)點造成過大的網絡和 IO 瓶頸。

而且由于跨區(qū)域部署下不同地域的數據狀態(tài)機可能會有延時，設置了讀寫分離的用戶在特定的場景下需要有特定的只讀狀態(tài)延時的要求。

但是這時的問題就是如果某個一致性節(jié)點發(fā)生了宕機，那么和它建立復制關系的只讀節(jié)點應該如何進行災備聯(lián)動?

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

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

高性能日志

MySQL 系統(tǒng)在開啟主備復制的情況下，除了會記錄 Binlog 之外，在備庫上還會記錄一份 RelayLog，即從庫通過指定對應主庫的 Binlog 位置去同步一份二進制日志寫入 RelayLog 供復制線程讀取和回放。

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

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

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

除此之外，X-Cluster 為 Consensus Log 設計了日志索引和日志緩存、預讀機制，極大的提升了日志模塊的性能以保證一致性協(xié)議運作的高效性。

異步化事務提交

傳統(tǒng)的 MySQL 都是 One Thread perConnection 的工作模式，在引入線程池后是以一個線程池孵化一定數量的工作線程，每個線程負責處理一次 query 的解析、優(yōu)化、修改數據、提交、回傳網絡包等等。

集群需要跨地域部署下，一次事務的提交由于需要在集群之間同步事務日志，受限于網絡的 RTT 的限制，會達到數十毫秒的級別，那么對于一個普通的寫事務來說，大量的時間會耗費在同步節(jié)點日志等待事務提交的過程。

在大壓力下，很快數據庫內部的工作線程會耗盡，吞吐達到瓶頸。如果一味的放大數據庫內部的工作線程數目，那么線程上下文的代價會大幅增加。

如果將整個事務的提交異步化，將工作線程從等待 X-Paxos 日志同步中解放出來，去處理新的連接請求，在大負載下可以擁有更高的處理能力。

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

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

• 提交之前階段。
• 提交和回包階段。

兩個階段都可以由不同的工作線程來完成。為了完成異步化的改造，X-Cluster 增加了等待同步隊列和等待提交隊列，用于存儲處于不同階段的事務。前者隊列中的事務是等待 Paxos 多數派日志同步的事務，后者是等待提交的事務。

當用戶發(fā)起 Commit/Rollback/XA_Prepare 時，處理用戶連接的線程池 Worker 產生事務日志并將事務上下文存儲到等待同步的隊列中。等待同步隊列的消費由少量數目的 Worker 線程來完成，其余工作線程可以直接參與其他任務的處理。

事務等待多數派完成后會被推入等待提交隊列。這個隊列里的事務都是可以被立即提交的。所有的 Worker 線程發(fā)現該隊列里有事務，就可以順道取出來執(zhí)行提交操作。

這樣一來，系統(tǒng)中只有少數的線程在等待日志同步操作，其余的線程可以充分利用 CPU 處理客戶端的請求。

X-Cluster 以這樣的思路為指導原則，結合 MySQL 的 Group Commit 邏輯，將原有需要等待的操作全部異步化，讓 Worker 線程可以去執(zhí)行新的請求響應。

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

熱點更新

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

為了解決此問題，X-Cluster 在單機版 AliSQL 的熱點功能之上優(yōu)化了復制，使得在保證數據強一致的情況下，熱點更新性能提升 200 倍。

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

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

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

除此之外為了提升日志回放的效率，X-Cluster 將每個批次事務中對于熱點行的更新日志也做了合并。

一體化的客戶端和服務端

X-Cluster 有完整的 Client-Server 生態(tài)。所以整個系統(tǒng)不需要外部組件的介入，能夠自封閉的成為一個生態(tài)閉環(huán)。作為客戶端的 X-Driver 能夠訂閱 Server 端發(fā)生的一切改變，從而進行自動尋主，實例列表動態(tài)維護等功能。

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

優(yōu)化的備份以及數據訂閱體系

基于強大的 X-Paxos 體系，日志備份以及數據訂閱系統(tǒng)都能夠以日志訂閱者的方式接入進來。

由于有了 X-Paxos 的全局唯一位點的支持，這些訂閱系統(tǒng)的 Failover 不會再有難以找到準確位點的困擾。而且由于 X-Paxos 是流式的推送日志消息，因此數據的實時性也能大幅改進。

AliSQL X-Cluster 的實戰(zhàn)部署方案

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

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

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

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

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

在日常運行中，5 節(jié)點在每次事務提交的時候必定需要將日志同步到 3 個節(jié)點，因此必然會出現一次跨域的網絡同步，這也就是長傳鏈路網絡場景，X-Cluster 對于慢網絡的優(yōu)化正是應對類似這樣的需求。

AliSQL X-Cluster 的性能表現

我們使用了三節(jié)點部署的方式，分別在同域三機房、跨域三機房的網絡環(huán)境下進行了測試。

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

針對熱點環(huán)境，測試的場景是改造 update_non_index ，使其更新同一行數據。只讀場景不在本次測試的范疇內，原因是只讀不涉及到節(jié)點的日志、數據同步。

因此可以認為只讀測試對于 X-Cluster 這樣的分布式系統(tǒng)是沒有意義的。所有的測試，數據量為 10 張表，每張表 20 萬條記錄。

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

測試同域下的集群，Insert 我們使用 300 并發(fā)線程、 OLTP 使用 400 并發(fā)線程，熱點更新使用 300 并發(fā)線程。

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

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

測試跨域下的集群需要大量的連接來保證吞吐，因此 Insert 使用 2000 并發(fā)線程，OLTP 使用 700 并發(fā)線程，熱點更新使用 2500 并發(fā)線程。

當集群部署在不同域時，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 的正確性保障

分布式系統(tǒng)的測試是非常復雜的，因為沒有人能夠通過窮舉來羅列所有可能出現的情況。

簡單的接口測試和性能回歸也只能覆蓋一小部分場景，無法衡量一個分布式系統(tǒng)版本的質量。只有日復一日的測試以及線上系統(tǒng)的正常運行能夠真正地說明分布式系統(tǒng)的魯棒性。

X-Cluster ***的挑戰(zhàn)就是保證基于分布式一致性協(xié)議實現的正確性。經過實踐證明，灰盒測試是最有效的手段。

X-Cluster 集成了 X-Paxos，X-Paxos 項目本身有一系列的測試框架用于發(fā)現和回歸。除此之外，X-Cluster 基于 tc、systemtap 等工具構建了多種多樣模擬網絡異常、實例宕機、I/O 異常的環(huán)境。

在這套環(huán)境下網絡分區(qū)、丟包、各種 I/O 異常，各種實例宕機可以隨機組合。同時使用 benchmark 工具對每個節(jié)點施加大壓力的讀寫，定期的去校驗集群中不同節(jié)點的數據以及日志的一致性。

一致性相關所有的操作都會記錄在 X-Cluster 專門的日志中，方便追溯集群節(jié)點間的交互行為。數據和日志的最終一致性校驗由外部系統(tǒng)來完成。阿里內部有專門的分片校驗系統(tǒng)可以做 X-Cluster 不同節(jié)點的全量數據校驗。

Consensus 日志解析工具可以快速解析日志內容進行比對。這套測試環(huán)境幫助我們發(fā)現了非常多的系統(tǒng) Bug，包括實例恢復的 Bug，網絡異常導致的 Bug 等等。

我們認為一個穩(wěn)定版本的標準是一定需要通過這個場景長時間的測試，并且各種表現要符合預期。

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

Jepsen 幫助大量分布式系統(tǒng)發(fā)現了分布式協(xié)議和實現的正確性問題。我們?yōu)?X-Cluster 專門構造了一系列的測試用例來盡可能覆蓋各種異常場景，來發(fā)現系統(tǒng)在隔離性和一致性上的問題。

AliSQL X-Cluster與同類的對比

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

Galera

Galara 是 MariaDB 支持的 MySQL 集群版本，支持強同步，支持多點寫入，自動的集群配置以及節(jié)點 Failover，支持行級別的并行復制，支持原生的 MySQL 客戶端。

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

Galera 的集群通信用了一種基于單令牌環(huán)的 Totem 組播協(xié)議。為了能支持多點寫入，主機在收到寫請求后，會原子廣播到組內所有的機器，由它們各自的事務管理層來決定是否提交或者回滾。

組播由于是 P2P 的通信，隨著節(jié)點數增加，延時會放大，響應時間會變慢，并且只適用于低延時的局域網。

除此之外，組播還有一個問題，如果組內的某臺機器宕機，組播會超時，在踢掉 fail 的機器重新確定組內成員關系之前，整個集群不可服務。

Galera 采用了專門的文件 gcache 進行增量狀態(tài)復制，gcache 不做任何他用，因此 gcache 本身需要額外的計算和存儲代價進行維護。

Group Replication

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

Group Replication 實現了一個 X-COM 的通信層，它在新版本中已經使用了 Paxos 算法。目前一個 GR 集群中最多可以有 9 個節(jié)點，響應延時相對穩(wěn)定，在節(jié)點同步日志層面，GR 使用 Binlog，相比 Galera 更加的通用。

Group Replication 的協(xié)議層復制是 XCOM，且在復制中強依賴 GTID。在測試中的性能表現，特別是跨域部署下還達不到需求，目前的版本中也仍然有大量的 Bug 在修復，完全可用于生產環(huán)境還有待后續(xù)版本的穩(wěn)定性和性能提升。

總結

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

X-Cluster 不僅能夠享受到開源社區(qū)帶來的紅利，其中涉及一致性的關鍵技術也能夠做到完全的自主、可控，能夠針對業(yè)務的需求進行靈活的變更。

未來 X-Cluster 會在此基礎上做更多的優(yōu)化，例如支持多分片的 Paxos，多節(jié)點提供強一致讀等功能。

隨著 X-Paxos 和 AliSQL 的不斷進化，X-Cluster 也會給大家?guī)砀嗟捏@喜。

參考文獻

[[199498]]

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

【51CTO原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為51CTO.com】