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

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

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

AliSQL X-Cluster 介紹

AliSQL X-Cluster(本文中簡(jiǎn)稱 X-Cluster)是阿里巴巴數(shù)據(jù)庫(kù)團(tuán)隊(duì)推出的兼容 MySQL 5.7，提供數(shù)據(jù)強(qiáng)一致功能，支持全球部署的分布式數(shù)據(jù)庫(kù)集群產(chǎn)品。

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

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

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

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

AliSQL X-Cluster 的整體架構(gòu)

先來(lái)看一下 X-Cluster 的基本架構(gòu)：

上圖展示的是一個(gè)部署三個(gè)實(shí)例的 Cluster 集群。X-Cluster 是一個(gè)單點(diǎn)寫入，多點(diǎn)可讀的集群系統(tǒng)。在同一時(shí)刻，整個(gè)集群中至多會(huì)有一個(gè) Leader 節(jié)點(diǎn)來(lái)承擔(dān)數(shù)據(jù)寫入的任務(wù)。

相比多點(diǎn)寫入，單點(diǎn)寫入不需要處理數(shù)據(jù)集沖突的問(wèn)題，可以達(dá)到更好的性能與吞吐率。

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

X-Cluster 為了追求***的性能，利用 MySQL 的 Binlog 進(jìn)行深度改造和定制來(lái)作為 X-Paxos 的 Consensus 日志，實(shí)現(xiàn)了一系列的 X-Paxos 日志接口，賦予 X-Paxos 直接操縱 MySQL 日志的能力。

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

事務(wù)提交、復(fù)制流程

X-Cluster 的復(fù)制流程是基于 X-Paxos 驅(qū)動(dòng) Consensus 日志進(jìn)行復(fù)制。

Leader 節(jié)點(diǎn)在事務(wù) prepare 階段會(huì)將事務(wù)產(chǎn)生的日志收集起來(lái)，傳遞給 X-Paxos 協(xié)議層后進(jìn)入等待。X-Paxos 協(xié)議層會(huì)將 Consensus 日志高效地轉(zhuǎn)發(fā)給集群內(nèi)其他節(jié)點(diǎn)。

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

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

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

Follower 的協(xié)調(diào)者線程會(huì)負(fù)責(zé)讀取達(dá)成多數(shù)派的日志并加以解析，并傳遞給各個(gè)回放工作線程進(jìn)行并發(fā)的數(shù)據(jù)更新。

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

Failover

X-Cluster 只要半數(shù)以上的節(jié)點(diǎn)存活就能保證集群正常對(duì)外服務(wù)。因此當(dāng)出現(xiàn)少數(shù)的follower節(jié)點(diǎn)故障時(shí)并不影響集群的服務(wù)能力。

當(dāng) Leader 節(jié)點(diǎn)故障時(shí)會(huì)自動(dòng)觸發(fā)集群的重新選主流程。選主流程由 X-Paxos 驅(qū)動(dòng)，在 Paxos 協(xié)議的基礎(chǔ)上，結(jié)合優(yōu)先級(jí)推選出新的 Leader 節(jié)點(diǎn)。

對(duì)于 X-Cluster 而言，failover_time =election_time + apply_time。

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

相對(duì)來(lái)說(shuō) Leader 節(jié)點(diǎn)故障之下是一個(gè)相對(duì)復(fù)雜的場(chǎng)景，故障包括了實(shí)例崩潰、服務(wù)器宕機(jī)、網(wǎng)絡(luò)隔離等等。

如上圖所示，一個(gè)三節(jié)點(diǎn)的 X-Cluster 集群，左邊的 Case 是原 Leader A 節(jié)點(diǎn)宕機(jī)，因此 B 節(jié)點(diǎn)和 C 節(jié)點(diǎn)會(huì)在較長(zhǎng)的時(shí)間內(nèi)收不到 Leader 的心跳。

因此在一個(gè)選舉超時(shí)周期后，B 節(jié)點(diǎn)開始嘗試推選自己為 Leader，并且 C 節(jié)點(diǎn)同意后，B 會(huì)成為新的主節(jié)點(diǎn)，恢復(fù)其服務(wù)能力。

右邊的 Case 是原 Leader A 節(jié)點(diǎn)發(fā)生網(wǎng)絡(luò)分區(qū)，此時(shí)在選舉超時(shí)后，BC 兩個(gè)節(jié)點(diǎn)的行為和之間的 Case 類似。

A 節(jié)點(diǎn)由于無(wú)法將心跳和日志發(fā)送給 BC 兩個(gè)節(jié)點(diǎn)在超時(shí)后會(huì)降級(jí)，然后不斷嘗試選自己為主，但是因?yàn)闆](méi)有其他節(jié)點(diǎn)的同意，達(dá)不成多數(shù)派，一直都不會(huì)成功。當(dāng)網(wǎng)絡(luò)分區(qū)恢復(fù)后，A 收到 B 節(jié)點(diǎn)的心跳，觸發(fā) Leader stickness 機(jī)制，A 自動(dòng)加回集群。

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

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

跨地域部署

X-Cluster 的一個(gè)顯著功能就是能夠支持跨地域部署，在跨域的情況下也能保證集群數(shù)據(jù)強(qiáng)一致，擁有城市級(jí)容災(zāi)的能力。即使某個(gè)城市的機(jī)房全部宕機(jī)，只要保證集群多數(shù)派節(jié)點(diǎn)存活，所有的數(shù)據(jù)都不會(huì)丟失。

依賴 X-Paxos 以及數(shù)據(jù)庫(kù)內(nèi)核中異步化工作線程的改造，在數(shù)十毫秒的網(wǎng)絡(luò) RTT(RoundTrip Time)下，X-Cluster 依然有非常高的吞吐性能。

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

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

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

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

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

保證最終集群內(nèi)配置達(dá)成一致，不會(huì)因?yàn)榧号渲米兏^(guò)程中的異常導(dǎo)致腦裂或者其他配置出現(xiàn)終態(tài)不一致的問(wèn)題。

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

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

優(yōu)先級(jí)

應(yīng)用往往對(duì)于容災(zāi)后新主節(jié)點(diǎn)是有要求的，在原先的主節(jié)點(diǎn)意外宕機(jī)后，新主如果落在了一個(gè)低規(guī)格的節(jié)點(diǎn)，那么對(duì)于應(yīng)用來(lái)說(shuō)是很難接受的服務(wù)降級(jí)。

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

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

• 權(quán)重化選主。
• 策略化多數(shù)派。

權(quán)重化選主代表選主的順序權(quán)重。只要在選舉的時(shí)候沒(méi)有網(wǎng)絡(luò)隔離，選舉 Leader 的順序會(huì)按照集群存活節(jié)點(diǎn)的權(quán)重順序進(jìn)行。權(quán)重越高的節(jié)點(diǎn)，就有更大的優(yōu)先級(jí)被選為 Leader。

我們實(shí)現(xiàn)了兩段式的選舉時(shí)間，***階段是集群內(nèi)統(tǒng)一的租約時(shí)間，而第二階段是根據(jù)權(quán)重來(lái)決定，權(quán)重越大的節(jié)點(diǎn)時(shí)間越短，也就是會(huì)越早發(fā)起自選舉。

除此之外，還有一重權(quán)重檢測(cè)機(jī)制來(lái)保證權(quán)重優(yōu)先級(jí)，節(jié)點(diǎn)上任意時(shí)間會(huì)廣播檢測(cè)一遍所有能夠聯(lián)通的集群內(nèi)節(jié)點(diǎn)，如果發(fā)現(xiàn)權(quán)重更高的節(jié)點(diǎn)會(huì)主動(dòng)發(fā)起一次 Leader Transfer 將 Leader 角色過(guò)繼過(guò)去的命令。

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

策略化多數(shù)派是指在事務(wù)提交日志同步過(guò)程中，哪些節(jié)點(diǎn)必須要日志復(fù)制完成。復(fù)制優(yōu)先級(jí)分為兩檔，強(qiáng)復(fù)制和弱復(fù)制。標(biāo)準(zhǔn)的 Paxos 只要超過(guò)半數(shù)的節(jié)點(diǎn)同步日志即可推進(jìn)狀態(tài)機(jī)，但是由于每個(gè)連接會(huì)自動(dòng)分配路由的問(wèn)題，可能在跨 Region 的訪問(wèn)中 RTT 時(shí)間會(huì)有誤差。

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

低成本副本管理

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

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

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

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

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

因此無(wú)論是存儲(chǔ)還是 CPU 的開銷，日志型副本相比普通副本都有很大的優(yōu)勢(shì)。在實(shí)際應(yīng)用規(guī)劃中，非常適合用來(lái)作容災(zāi)型的節(jié)點(diǎn)部署。

只讀節(jié)點(diǎn)管理

如上圖所示，X-Cluster 集群中的只讀節(jié)點(diǎn)可以從任何一個(gè)一致性節(jié)點(diǎn)復(fù)制日志，這不僅是考慮到如果所有節(jié)點(diǎn)的日志都從 Leader 節(jié)點(diǎn)復(fù)制會(huì)對(duì) Leader 節(jié)點(diǎn)造成過(guò)大的網(wǎng)絡(luò)和 IO 瓶頸。

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

但是這時(shí)的問(wèn)題就是如果某個(gè)一致性節(jié)點(diǎn)發(fā)生了宕機(jī)，那么和它建立復(fù)制關(guān)系的只讀節(jié)點(diǎn)應(yīng)該如何進(jìn)行災(zāi)備聯(lián)動(dòng)?

作為一個(gè)自運(yùn)維的數(shù)據(jù)庫(kù)服務(wù)，X-Cluster 自然要解決好這個(gè)問(wèn)題。X-Cluster 定義了 Learner Source Group。每個(gè) Group 是一個(gè)只讀節(jié)點(diǎn)的容災(zāi)單元。

當(dāng) Group 內(nèi)某個(gè)一致性節(jié)點(diǎn)發(fā)生意外狀況(宕機(jī)或者網(wǎng)絡(luò)隔離)，集群會(huì)根據(jù) Group 的配置，將掛載在故障節(jié)點(diǎn)下的只讀節(jié)點(diǎn)配置到 Group 中另外一個(gè)正常工作的節(jié)點(diǎn)下進(jìn)行數(shù)據(jù)同步。

高性能日志

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

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

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

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

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

異步化事務(wù)提交

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

集群需要跨地域部署下，一次事務(wù)的提交由于需要在集群之間同步事務(wù)日志，受限于網(wǎng)絡(luò)的 RTT 的限制，會(huì)達(dá)到數(shù)十毫秒的級(jí)別，那么對(duì)于一個(gè)普通的寫事務(wù)來(lái)說(shuō)，大量的時(shí)間會(huì)耗費(fèi)在同步節(jié)點(diǎn)日志等待事務(wù)提交的過(guò)程。

在大壓力下，很快數(shù)據(jù)庫(kù)內(nèi)部的工作線程會(huì)耗盡，吞吐達(dá)到瓶頸。如果一味的放大數(shù)據(jù)庫(kù)內(nèi)部的工作線程數(shù)目，那么線程上下文的代價(jià)會(huì)大幅增加。

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

異步化改造的說(shuō)明示意圖如下所示：

X-Cluster 的異步化提交核心思想是將每個(gè)事務(wù)的請(qǐng)求分成兩個(gè)階段：

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

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

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

事務(wù)等待多數(shù)派完成后會(huì)被推入等待提交隊(duì)列。這個(gè)隊(duì)列里的事務(wù)都是可以被立即提交的。所有的 Worker 線程發(fā)現(xiàn)該隊(duì)列里有事務(wù)，就可以順道取出來(lái)執(zhí)行提交操作。

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

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

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

熱點(diǎn)更新

熱點(diǎn)更新原本就是數(shù)據(jù)庫(kù)的一個(gè)難題，受制于行鎖競(jìng)爭(zhēng)，性能吞吐一直很難提升上去。X-Cluster 面對(duì)跨域場(chǎng)景下的長(zhǎng)傳網(wǎng)絡(luò)更加是雪上加霜，提交的時(shí)間變長(zhǎng)，事務(wù)占據(jù)行鎖的時(shí)間也顯著增加。

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

如上圖所示，X-Cluster 針對(duì)熱點(diǎn)行更新的基本思路是合并多個(gè)事務(wù)對(duì)同一行的更新。

為了讓批量的更新事務(wù)能夠同時(shí)進(jìn)行提交，X-Cluster 增加了一種新的行鎖類型——熱點(diǎn)行鎖。在熱點(diǎn)行鎖下，熱點(diǎn)更新的事務(wù)之間是相容的。

X-Cluster 為了保證數(shù)據(jù)的一致性，對(duì)同一批的熱點(diǎn)更新事務(wù)日志打上特殊標(biāo)志，X-Paxos 會(huì)根據(jù)這些標(biāo)志將這一整批事務(wù)的日志組成一個(gè)單獨(dú)的網(wǎng)絡(luò)包進(jìn)行集群間的數(shù)據(jù)同步，保證這些事務(wù)是原子的提交/回滾。

除此之外為了提升日志回放的效率，X-Cluster 將每個(gè)批次事務(wù)中對(duì)于熱點(diǎn)行的更新日志也做了合并。

一體化的客戶端和服務(wù)端

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

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

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

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

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

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

X-Cluster 最為經(jīng)典的兩個(gè)部署方案是同城三副本，兩份數(shù)據(jù)一份日志，以及跨地域 5 副本，四份數(shù)據(jù)一份日志。

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

這兩類經(jīng)典的部署方案都是考慮了可用性以及成本之間的權(quán)衡，以較小的代價(jià)換來(lái)目標(biāo)的容災(zāi)能力。

如上圖，X-Cluster 的同城部署三副本能夠方便的實(shí)現(xiàn)零數(shù)據(jù)丟失的實(shí)例容災(zāi)以及機(jī)房級(jí)容災(zāi)。相比主備方式，額外增加了一個(gè)日志節(jié)點(diǎn)，換取強(qiáng)一致以及可用性。

如上圖，三地五實(shí)例(四數(shù)據(jù)、五日志)能夠保證城市級(jí)容災(zāi)，任何一個(gè)城市的節(jié)點(diǎn)全部宕機(jī)都不會(huì)影響到集群可用性，5 個(gè)節(jié)點(diǎn)中至少還有 3 個(gè)節(jié)點(diǎn)能夠正常運(yùn)行。

在日常運(yùn)行中，5 節(jié)點(diǎn)在每次事務(wù)提交的時(shí)候必定需要將日志同步到 3 個(gè)節(jié)點(diǎn)，因此必然會(huì)出現(xiàn)一次跨域的網(wǎng)絡(luò)同步，這也就是長(zhǎng)傳鏈路網(wǎng)絡(luò)場(chǎng)景，X-Cluster 對(duì)于慢網(wǎng)絡(luò)的優(yōu)化正是應(yīng)對(duì)類似這樣的需求。

AliSQL X-Cluster 的性能表現(xiàn)

我們使用了三節(jié)點(diǎn)部署的方式，分別在同域三機(jī)房、跨域三機(jī)房的網(wǎng)絡(luò)環(huán)境下進(jìn)行了測(cè)試。

測(cè)試工具使用標(biāo)準(zhǔn)的 Sysbench 的 insert/oltp，在 Insert 測(cè)試下，并且每個(gè)事務(wù)中只包含一條插入語(yǔ)句，屬于密集的小事務(wù)場(chǎng)景，而相反的 OLTP 是讀寫大事務(wù)。

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

因此可以認(rèn)為只讀測(cè)試對(duì)于 X-Cluster 這樣的分布式系統(tǒng)是沒(méi)有意義的。所有的測(cè)試，數(shù)據(jù)量為 10 張表，每張表 20 萬(wàn)條記錄。

作為對(duì)比，我們使用了***的開源單機(jī)版 MySQL 5.7.19 以及該版本下的 Group Replication。Group Replication 在測(cè)試中關(guān)閉限流，測(cè)試機(jī)均是 64core 256G 內(nèi)存 PCIE SSD。

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

在同一個(gè)域下，X-Cluster 的吞吐和響應(yīng)時(shí)間表現(xiàn)都是非常出色的，甚至略好于單機(jī)版本的 MySQL 5.7.19。

相比 Group Replication，在本次測(cè)試的壓力下，Insert case X-Cluster 有超過(guò)一倍的吞吐以及 55% 左右的響應(yīng)時(shí)間，OLTP case X-Cluster 有超過(guò) 5% 的吞吐以及接近 70% 的響應(yīng)時(shí)間表現(xiàn)。

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

當(dāng)集群部署在不同域時(shí)，X-Cluster 和 Group Replication 相比同域的部署下吞吐都有下降，響應(yīng)時(shí)間受到物理網(wǎng)絡(luò)延遲的影響也有顯著提高。

然而在 Insert case 下，X-Cluster 仍然可以領(lǐng)先 Group Replication 5 倍，響應(yīng)時(shí)間只有 GR 的四分之一。OLTP case 下，X-Cluster 的吞吐領(lǐng)先 Group Replication 接近 4 倍，響應(yīng)時(shí)間只有三分之一。

熱點(diǎn)更新是 X-Cluster 的一大亮點(diǎn)功能，根據(jù)測(cè)試結(jié)果，無(wú)論是同域還是跨域部署， X-Cluster 的吞吐和響應(yīng)時(shí)間表現(xiàn)都要遠(yuǎn)遠(yuǎn)超過(guò)單機(jī) MySQL 和 Group Replication。

AliSQL X-Cluster 的正確性保障

分布式系統(tǒng)的測(cè)試是非常復(fù)雜的，因?yàn)闆](méi)有人能夠通過(guò)窮舉來(lái)羅列所有可能出現(xiàn)的情況。

簡(jiǎn)單的接口測(cè)試和性能回歸也只能覆蓋一小部分場(chǎng)景，無(wú)法衡量一個(gè)分布式系統(tǒng)版本的質(zhì)量。只有日復(fù)一日的測(cè)試以及線上系統(tǒng)的正常運(yùn)行能夠真正地說(shuō)明分布式系統(tǒng)的魯棒性。

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

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

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

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

Consensus 日志解析工具可以快速解析日志內(nèi)容進(jìn)行比對(duì)。這套測(cè)試環(huán)境幫助我們發(fā)現(xiàn)了非常多的系統(tǒng) Bug，包括實(shí)例恢復(fù)的 Bug，網(wǎng)絡(luò)異常導(dǎo)致的 Bug 等等。

我們認(rèn)為一個(gè)穩(wěn)定版本的標(biāo)準(zhǔn)是一定需要通過(guò)這個(gè)場(chǎng)景長(zhǎng)時(shí)間的測(cè)試，并且各種表現(xiàn)要符合預(yù)期。

除了數(shù)據(jù)和日志的最終一致性，對(duì)于數(shù)據(jù)的線性一致，事務(wù)隔離性，我們引入了 Jepsen 工具。

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

AliSQL X-Cluster與同類的對(duì)比

AliSQL X-Cluster 不是***個(gè)基于 MySQL 的強(qiáng)一致集群方案，然而是最適合阿里這樣體量公司的數(shù)據(jù)庫(kù)解決方案。對(duì)比下面這些同類產(chǎn)品：

Galera

Galara 是 MariaDB 支持的 MySQL 集群版本，支持強(qiáng)同步，支持多點(diǎn)寫入，自動(dòng)的集群配置以及節(jié)點(diǎn) Failover，支持行級(jí)別的并行復(fù)制，支持原生的 MySQL 客戶端。

在這套架構(gòu)下，Slave 不會(huì)有延時(shí)，任意節(jié)點(diǎn)讀到的都是一致數(shù)據(jù)，不會(huì)有事務(wù)數(shù)據(jù)丟失，讀寫可擴(kuò)展。

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

組播由于是 P2P 的通信，隨著節(jié)點(diǎn)數(shù)增加，延時(shí)會(huì)放大，響應(yīng)時(shí)間會(huì)變慢，并且只適用于低延時(shí)的局域網(wǎng)。

除此之外，組播還有一個(gè)問(wèn)題，如果組內(nèi)的某臺(tái)機(jī)器宕機(jī)，組播會(huì)超時(shí)，在踢掉 fail 的機(jī)器重新確定組內(nèi)成員關(guān)系之前，整個(gè)集群不可服務(wù)。

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

Group Replication

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

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

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

總結(jié)

X-Cluster 是針對(duì)數(shù)據(jù)質(zhì)量要求較高的用戶推出的全新的數(shù)據(jù)庫(kù)解決方案。

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

未來(lái) X-Cluster 會(huì)在此基礎(chǔ)上做更多的優(yōu)化，例如支持多分片的 Paxos，多節(jié)點(diǎn)提供強(qiáng)一致讀等功能。

隨著 X-Paxos 和 AliSQL 的不斷進(jìn)化，X-Cluster 也會(huì)給大家?guī)?lái)更多的驚喜。

參考文獻(xiàn)

[[199498]]

2016 年加入阿里巴巴，數(shù)據(jù)庫(kù)技術(shù)團(tuán)隊(duì) AliSQL 內(nèi)核貢獻(xiàn)者，X-Cluster 的核心開發(fā)成員。畢業(yè)于浙江大學(xué)，專攻數(shù)據(jù)庫(kù)方向。從業(yè)以來(lái)一直深耕于數(shù)據(jù)庫(kù)領(lǐng)域，擅長(zhǎng) RDBMS，NOSQL 等技術(shù)方向。

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