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 也會給大家帶來更多的驚喜。

參考文獻

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

本文出自 “雪夜雕零” 博客，請務必保留此出處http://wangxy.blog.51cto.com/12562290/1954711

阿裏10年分布式數據庫技術沈澱，AliSQL X-Cluster的應用實戰