AliSQL X-Cluster（摘選）

時間很快走到2014年，隨著業務高速的增長，同城主備AliSQL部署的方式已經無法滿足阿里對可擴充套件的部署、國際化、以及容災方面的需求。“異地多活”成為了公司應用的新標準。“異地多活”也給底層的資料庫提出了新的容災要求。傳統的Master-Slave架構下，主備如果不使用強同步模式就會存在資料丟失的可能，然而強同步下一旦有節點異常則整體不可服務。而且這套架構下需要HA工具來進行選主的仲裁和控制。過去阿里巴巴的DBA們開發了高效可靠的HA以及一整套工具和流程來做主備切換後資料和日誌的校驗和訂正。然而我們相信技術的發展能帶來更大的運維便利性以及更好的使用者體驗。 以Google Spanner以及Amazon Aruora 為代表的NewSQL系統為資料庫的資料一致性給出了與以往不同的思路： 基於一致性協議搭建分散式的多副本資料庫。

AliSQL X-Cluster 介紹

AliSQL X-Cluster(本文中簡稱X-Cluster)是阿里巴巴資料庫團隊推出的相容MySQL 5.7，提供資料強一致功能，支援全球部署的分散式資料庫叢集產品。

說到AliSQL X-Cluster就不能不提其分散式核心，一致性協議。

X-Paxos是阿里巴巴自主研發的一致性協議庫，目標是填補市面上高效能、易接入的一致性協議庫的空白。而市面上已開源的一致性協議實現，包括etcd以及其他廠商等都存在或效能不夠，或功能上無法滿足複雜的現實應用場景需求的問題。 有了X-Paxos，可基於它打造一套強一致的分散式系統，X-Cluster是第一個接入X-Paxos生態的重要產品，利用了X-Paxos實現了自動選主，日誌同步，叢集內資料強一致，線上叢集配置變更等功能。同時X-Cluster基於MySQL生態，相容最新版本的MySQL 5.7，整合了AliSQL過去的各種功能增強。 MySQL的使用者可以零成本遷移到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兩個節點在超時後會降級，然後不斷嘗試選自己為Leader，但是因為沒有其他節點的同意，達不成多數派，一直都不會成功。當網路分割槽恢復後，A收到B節點的心跳，觸發Leader stickness機制，A降級成為Follower，整個叢集保持一致。

在選舉的過程中是否能成為Leader需要根據節點的日誌情況來決定。X-Cluster 承諾在failover的情況下不會丟失提交的資料。Paxos協議保證了在叢集恢復後一定能保證所有的節點日誌一致。那麼只要資料是按照日誌進行回放，就能保證所有節點的狀態機(資料)一致。 成為Leader的節點要求有最長的日誌。如右上所示，假設A節點當機或者分割槽前已經把3號日誌複製到了B節點，那麼在重新選舉後，B節點由於日誌較多，因此能夠被選舉成Leader。 在成為Leader後B節點會嘗試將3號日誌再複製到C節點。最終，ABC三個節點都會有1，2，3號日誌，因此資料也是一致的。

AliSQL X-Cluster的優化特性

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

跨地域部署

X-Cluster的一個顯著功能就是能夠支援跨地域部署，在跨域的情況下也能保證叢集資料強一致，擁有城市級容災的能力。即使某個城市的機房全部當機，只要保證叢集多數派節點存活，所有的資料都不會丟失。 依賴X-Paxos以及資料庫核心中非同步化工作執行緒的改造，在數十毫秒的網路RTT(Round Trip 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 per Connection的工作模式， 在引入執行緒池後是以一個執行緒池孵化一定數量的工作執行緒， 每個執行緒負責處理一次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最為經典的兩個部署方案是同城3副本，兩份資料一份日誌。以及跨地域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仍然可以達到超過單機版50%的吞吐，領先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異常的環境。在這套環境下網路分割槽、丟包、各種IO異常，各種例項當機可以隨機組合。同時使用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也給大家會帶來更多的驚喜。