背景

分布式一致性算法(Consensus Algorithm)是一個(gè)分布式計(jì)算領(lǐng)域的基礎(chǔ)性問(wèn)題，其最基本的功能是為了在多個(gè)進(jìn)程之間對(duì)某個(gè)(某些)值達(dá)成一致(強(qiáng)一致);進(jìn)而解決分布式系統(tǒng)的可用性問(wèn)題(高可用)。Paxos是最重要的分布式一致性算法，很多人都把它作為“分布式一致性協(xié)議”的代名詞(Mike Burrows, inventor of the Chubby service at Google, says that“there is only one consensus protocol, and that’s Paxos”)。

關(guān)于Paxos的歷史和原理，已經(jīng)有很多經(jīng)典的論文可以參考，也有廠內(nèi)外的文章有詳細(xì)的描述，本文就不再重復(fù)了。感興趣的同學(xué)可以閱讀下這些論文[1,2,3,4]。

業(yè)內(nèi)

雖然Paxos的理論提出已經(jīng)17年了，從***個(gè)Paxos的工業(yè)實(shí)現(xiàn)到現(xiàn)在也已經(jīng)11年了，但是直到近幾年，無(wú)論是***會(huì)議，還是業(yè)內(nèi)，Paxos相關(guān)的文章和項(xiàng)目還是層出不窮。

轉(zhuǎn)向業(yè)內(nèi)，雖然使用了Paxos及各種變種的產(chǎn)品已經(jīng)層出不窮;但是真正工業(yè)級(jí)的，獨(dú)立的，Paxos基礎(chǔ)庫(kù)還是相當(dāng)?shù)纳僖?jiàn)：Google并沒(méi)有開(kāi)源其任何Paxos基礎(chǔ)庫(kù)(連包含Paxos的項(xiàng)目都沒(méi)有開(kāi)源過(guò)); Facebook也沒(méi)有公布過(guò)包含Paxos的產(chǎn)品; Apache有Zookeeper，但是其協(xié)議并不能支持一個(gè)高吞吐的狀態(tài)機(jī)復(fù)制，且并沒(méi)有提供獨(dú)立的第三方庫(kù)，可供快速接入。

在Github上能找到的Paxos的獨(dú)立庫(kù)，star***的是騰訊于去年開(kāi)源的phxpaxos(后文會(huì)作為競(jìng)品進(jìn)行詳細(xì)對(duì)比)。

因此到目前為止業(yè)內(nèi)還鮮有成熟可靠的，可供快速使用的獨(dú)立第三方Paxos庫(kù)，開(kāi)源的Paxos生態(tài)也尚未成熟。

X-Paxos

愿景

我們的初衷并不是要做一個(gè)Paxos的公共庫(kù)，X-Paxos誕生于阿里巴巴的分布式數(shù)據(jù)庫(kù)AliSQL X-Cluster，但X-Paxos并不屬于AliSQL X-Cluster。Paxos是分布式系統(tǒng)的基石，X-Paxos可用于解決各種各樣的分布式系統(tǒng)中的一致性問(wèn)題。

因此在整個(gè)分布式數(shù)據(jù)庫(kù)的設(shè)計(jì)之初，我們就獨(dú)立設(shè)計(jì)了分布式一致性協(xié)議模塊，并把它獨(dú)立為X-Paxos。X-Paxos為AliSQL X-Cluster解決了分布式一致性問(wèn)題，同樣可以快速賦予其他系統(tǒng)分布式一致性能力。

分布式一致性需求，并不是AliSQL X-Cluster所特有的，很多系統(tǒng)都存在這高可用和強(qiáng)一致的需求，我們把Paxos的能力獨(dú)立成一個(gè)基礎(chǔ)庫(kù)，希望能夠把這個(gè)能力帶給更多的其他系統(tǒng)。

例如：團(tuán)隊(duì)內(nèi)的同學(xué)把X-Paxos融入到單機(jī)KV數(shù)據(jù)庫(kù)RocksDB中，快速實(shí)現(xiàn)了一個(gè)分布式KV引擎。集團(tuán)已有業(yè)務(wù)團(tuán)隊(duì)團(tuán)隊(duì)把X-Paxos融入到業(yè)務(wù)存儲(chǔ)系統(tǒng)中，構(gòu)建全新的分布式強(qiáng)一致存儲(chǔ)服務(wù)。

同時(shí)也正是AliSQL X-Cluster，成就了X-Paxos。Google的論文《Paxos made live》中有一段話說(shuō)的很好，大意是說(shuō)：Paxos從理論到現(xiàn)實(shí)世界的實(shí)現(xiàn)之間有巨大的鴻溝，在真正實(shí)現(xiàn)一個(gè)Paxos的時(shí)候，往往需要對(duì)Paxos的經(jīng)典理論做一些擴(kuò)展，(尤其是在實(shí)現(xiàn)一個(gè)高性能的Paxos的時(shí)候，擴(kuò)展點(diǎn)就更多了，可以參考后文的功能增強(qiáng)和性能優(yōu)化)，這往往會(huì)導(dǎo)致真正的Paxos實(shí)現(xiàn)其實(shí)都是基于一個(gè)未被完全證明的協(xié)議。

這也就是傳說(shuō)中，理論證明一個(gè)Paxos的實(shí)現(xiàn)，比實(shí)現(xiàn)這個(gè)Paxos還要難的原因了。因此一個(gè)成熟的Paxos實(shí)現(xiàn)很難獨(dú)立產(chǎn)生，往往需要和一個(gè)系統(tǒng)結(jié)合在一起，通過(guò)一個(gè)或者多個(gè)系統(tǒng)來(lái)驗(yàn)證其可靠性和完備性。這也是為什么大部分成熟的Paxos案例都是和分布式數(shù)據(jù)庫(kù)相結(jié)合的，例如最早的Paxos實(shí)現(xiàn)(Chubby)，當(dāng)前的主要Paxos實(shí)現(xiàn)(Google的MegaStore、Spanner，AWS的DynamoDB、S3等)。而X-Paxos正是依托于AliSQL X-Cluster驗(yàn)證了其可靠性和完備性。

我們的愿景是希望能夠提供一個(gè)經(jīng)過(guò)實(shí)踐檢驗(yàn)的，高度成熟可靠的獨(dú)立Paxos基礎(chǔ)庫(kù)。使得一個(gè)后端服務(wù)能夠通過(guò)簡(jiǎn)單的接入，就能擁有Paxos算法賦予的強(qiáng)一致、高可用、自動(dòng)容災(zāi)等能力。真正將晦澀難懂的Paxos，變得平易近人，帶入千萬(wàn)家。

架構(gòu)

??

X-Paxos的整體架構(gòu)如上圖所示，主要可分為網(wǎng)絡(luò)層、服務(wù)層、算法模塊、日志模塊4個(gè)部分

網(wǎng)絡(luò)層

網(wǎng)絡(luò)層基于阿里內(nèi)部非常成熟的網(wǎng)絡(luò)庫(kù)libeasy實(shí)現(xiàn)。libeasy的異步框架和線程池非常契合我們的整體異步化設(shè)計(jì)，同時(shí)我們對(duì)libeasy的重連等邏輯進(jìn)行了修改，以適應(yīng)分布式協(xié)議的需求。

服務(wù)層

服務(wù)層是驅(qū)動(dòng)整個(gè)Paxos運(yùn)行的基礎(chǔ)，為Paxos提供了事件驅(qū)動(dòng)，定時(shí)回調(diào)等核心的運(yùn)行功能，每一個(gè)Paxos實(shí)現(xiàn)都有一個(gè)與之緊密相關(guān)的驅(qū)動(dòng)層，驅(qū)動(dòng)層的架構(gòu)與性能和穩(wěn)定性密切相關(guān)。

X-Paxos的服務(wù)層是一個(gè)基于C++11特性實(shí)現(xiàn)的多線程異步框架。常見(jiàn)的狀態(tài)機(jī)/回調(diào)模型存在開(kāi)發(fā)效率較低，可讀性差等問(wèn)題，一直被開(kāi)發(fā)者所詬病;而協(xié)程又因其單線程的瓶頸，而使其應(yīng)用場(chǎng)景受到限制。C++11以后的新版本提供了***轉(zhuǎn)發(fā)(argument forwarding)、可變模板參數(shù)(variadic templates)等特性，為我們能夠?qū)崿F(xiàn)一種全新的異步調(diào)用模型提供了可能。

例如這是X-Paxos內(nèi)實(shí)際的一行創(chuàng)建單次定時(shí)任務(wù)的代碼

new ThreadTimer(srv_->getThreadTimerService(),srv_, electionTimeout_, ThreadTimer::Oneshot,  
 &Paxos::checkLeaderTransfer, this, targetId, currentTerm_.load(),log_->getLastLogIndex());

以上一行程序，包含了定時(shí)器的創(chuàng)建，任意回調(diào)函數(shù)的設(shè)置，回調(diào)函數(shù)參數(shù)的轉(zhuǎn)發(fā)，并保證在回調(diào)觸發(fā)后(Oneshot)內(nèi)存的自動(dòng)回收。同時(shí)服務(wù)層支持嵌套回調(diào)，即在回調(diào)函數(shù)中再一次生成一個(gè)定時(shí)/即時(shí)任務(wù)，實(shí)現(xiàn)一個(gè)有限次定時(shí)循環(huán)邏輯。

算法模塊

X-Paxos當(dāng)前的算法基于unique proposer的multi-paxos[3]實(shí)現(xiàn)，大量理論和實(shí)踐已經(jīng)證明了基于unique proposer的multi-paxos，性能好于multi-paxos/basic paxos，當(dāng)前成熟的基于Paxos的系統(tǒng)，大部分都采用了這種方式。

算法模塊的基礎(chǔ)功能部分本文不再重復(fù)，感興趣的同學(xué)可以參考相關(guān)論文[1,2,4]。在基礎(chǔ)算法的基礎(chǔ)上，結(jié)合阿里業(yè)務(wù)的場(chǎng)景以及高性能和生態(tài)的需求，X-Paxos做了很多的創(chuàng)新性的功能和性能的優(yōu)化，使其相對(duì)于基礎(chǔ)的multi-paxos，功能變的更加豐富，在多種部署場(chǎng)景下性能都有明顯的提升。下一章中，將對(duì)這些優(yōu)化進(jìn)行詳細(xì)的介紹。

日志模塊

日志模塊本是算法模塊的一部分，但是出于對(duì)***性能要求的考慮，我們把日志模塊獨(dú)立出來(lái)，并實(shí)現(xiàn)了一個(gè)默認(rèn)的高性能的日志模塊;有***性能以及成本需求的用戶，可以結(jié)合已有的日志系統(tǒng)，對(duì)接日志模塊接口，以獲取更高的性能和更低的成本。這也是X-Paxos作為高性能獨(dú)立庫(kù)特有的優(yōu)勢(shì)，下一章會(huì)進(jìn)行詳細(xì)的介紹。

功能增強(qiáng)

結(jié)合廣泛的業(yè)務(wù)場(chǎng)景，構(gòu)建開(kāi)放的生態(tài)

1. 在線添加/刪除節(jié)點(diǎn)，在線轉(zhuǎn)讓leader

X-Paxos在標(biāo)準(zhǔn)multi-paxos的基礎(chǔ)上，支持在線添加/刪除多種角色的節(jié)點(diǎn)，支持在線快速將leadership節(jié)點(diǎn)轉(zhuǎn)移到其他節(jié)點(diǎn)(有主選舉)。

2. 策略化多數(shù)派和權(quán)重化選主

集團(tuán)及螞蟻目前的多地有中心的架構(gòu)，很多應(yīng)用因其部署的特點(diǎn)，往往要求其在未發(fā)生城市級(jí)容災(zāi)的情況下，僅在中心寫(xiě)入數(shù)據(jù)庫(kù)，或調(diào)用其他分布式服務(wù);同時(shí)又要求在發(fā)生城市級(jí)容災(zāi)的時(shí)候(同一個(gè)城市的多個(gè)機(jī)房全部不可用)，可以完全不丟失任何數(shù)據(jù)的情況下，將寫(xiě)入點(diǎn)切換到非中心。

而經(jīng)典的multi-paxos并不能滿足這些需求。經(jīng)典理論中，多數(shù)派強(qiáng)同步以后即可完成提交，而多數(shù)派是非特定的，并不能保證某個(gè)/某些節(jié)點(diǎn)一定能得到完整的數(shù)據(jù)，并激活服務(wù)。在實(shí)際實(shí)現(xiàn)中，往往地理位置較近的節(jié)點(diǎn)會(huì)擁有強(qiáng)一致的數(shù)據(jù)，而地理位置較遠(yuǎn)的節(jié)點(diǎn)，一直處于非強(qiáng)一致節(jié)點(diǎn)，在容災(zāi)的時(shí)候永遠(yuǎn)無(wú)法激活為主節(jié)點(diǎn)，形同虛設(shè)。

同時(shí)當(dāng)中心單節(jié)點(diǎn)出現(xiàn)故障需要容災(zāi)的時(shí)候，往往需要將主節(jié)點(diǎn)就近切換到同中心的另外一個(gè)節(jié)點(diǎn);由于應(yīng)用在多地的部署往往是非對(duì)稱的原因，才出現(xiàn)單個(gè)region全掛的時(shí)候，寫(xiě)需要將主節(jié)點(diǎn)切到特定的region內(nèi)。這些需求都需要Paxos在選主的時(shí)候，可以由用戶指定規(guī)則，而經(jīng)典理論中同樣沒(méi)有類似的功能，添加權(quán)重也需要保證Paxos的正確性。

X-Paxos在協(xié)議中實(shí)現(xiàn)了策略化多數(shù)派和權(quán)重化選主?；诓呗曰鄶?shù)派，用戶可以通過(guò)動(dòng)態(tài)配置，指定某個(gè)/某些節(jié)點(diǎn)必須保有強(qiáng)一致的數(shù)據(jù)，在出現(xiàn)容災(zāi)需求的時(shí)候，可以立即激活為主節(jié)點(diǎn)?；跈?quán)重化選主，用戶可以指定各個(gè)節(jié)點(diǎn)的選主權(quán)重，只有在高權(quán)重的節(jié)點(diǎn)全部不可用的時(shí)候，才會(huì)激活低權(quán)重的節(jié)點(diǎn)。

3. 節(jié)點(diǎn)角色定制化(Proposer/Accepter/Learner的獨(dú)立配置)

在經(jīng)典的multi-paxos實(shí)現(xiàn)中，一般每個(gè)節(jié)點(diǎn)都包含了Proposer/Accepter/Learner三種功能，每一個(gè)節(jié)點(diǎn)都是全功能節(jié)點(diǎn)。但是某些情況下我們并不需要所有節(jié)點(diǎn)都擁有全部的功能，例如：

1. 經(jīng)典的三個(gè)副本部署中，我們可以裁剪其中一個(gè)節(jié)點(diǎn)的狀態(tài)機(jī)，只保留日志(無(wú)數(shù)據(jù)的純?nèi)罩竟?jié)點(diǎn)，但是在同步中作為多數(shù)派計(jì)算)，此時(shí)我們需要裁剪掉協(xié)議中的Proposer功能(被選舉權(quán))，保留Accepter和Learner功能。
2. 我們希望可以有若干個(gè)節(jié)點(diǎn)可以作為下游，訂閱/消費(fèi)協(xié)議產(chǎn)生的日志流，而不作為集群的成員(不作為多數(shù)派計(jì)算，因?yàn)檫@些節(jié)點(diǎn)不保存日志流)，此時(shí)我們裁剪掉協(xié)議的Proposer/Accepter功能，只保留Learner功能

當(dāng)然還有其他的組合方式，通過(guò)對(duì)節(jié)點(diǎn)角色的定制化組合，我們可以開(kāi)發(fā)出很多的定制功能節(jié)點(diǎn)，即節(jié)約了成本，又豐富了功能。

??

4. Witness SDK

基于上節(jié)節(jié)點(diǎn)角色定制化中的單獨(dú)Learner角色的功能，引發(fā)了無(wú)窮的想象力。Learner角色，可以抽象成一個(gè)數(shù)據(jù)流訂閱者(Witness Node)，整個(gè)集群中可以加入無(wú)數(shù)個(gè)訂閱者，當(dāng)有新的日志被提交的時(shí)候，這些訂閱者會(huì)收到其關(guān)心的日志流，基于訂閱者功能，我們可以讓一個(gè)集群很容易的實(shí)現(xiàn)下游訂閱消費(fèi)，日志即時(shí)備份，配置變更推送等等的功能。

因此我們把Learner角色單獨(dú)封裝成了一個(gè)SDK?；谶@個(gè)SDK，用戶可以快速的為自己的集群添加，訂閱注冊(cè)，流式訂閱定功能;結(jié)合特定的用途打造一個(gè)完成的生態(tài)。

例如日志流SDK在AliSQL X-Cluster中打造的生態(tài)：

??

采用了X-Paxos也可以利用Witness SDK快速實(shí)現(xiàn)分布式系統(tǒng)和下游的其他系統(tǒng)的對(duì)接，形成一個(gè)完整的生態(tài)。

我們拿MySQL的日志(binlog)備份來(lái)舉例：

• 普通方案

? 每隔固定時(shí)間Tb，將MySQL生成的binlog文件備份到***備份系統(tǒng)(OSS、S3等)

? RPO (Recovery PointObjective)為 Tb

• SDK方案

? X-Paxos支持由SDK訂閱增量日志，備份系統(tǒng)只需要簡(jiǎn)單的實(shí)現(xiàn)從SDK流到OSS流的對(duì)接，即可實(shí)現(xiàn)流式備份

? RPO (Recovery PointObjective)為 0除備份以外，Witness SDK在下游流式訂閱(DRC)、自封閉高可用系統(tǒng)(X-Driver)、異步只讀備庫(kù)等方面都有實(shí)戰(zhàn)案例，更多的應(yīng)用案例在不斷的添加中。

性能優(yōu)化

我們一直堅(jiān)信網(wǎng)絡(luò)延遲不應(yīng)該影響吞吐

1. Batching & Pipelining

Paxos除了設(shè)計(jì)之初的強(qiáng)一致和高可用以外，其高性能也是至關(guān)重要的，尤其是應(yīng)用于AliSQL X-Cluster這種高性能分布式數(shù)據(jù)庫(kù)的時(shí)候，對(duì)協(xié)議的吞吐，延遲都提出了很高的要求。同時(shí)作為可全球部署的分布式一致性協(xié)議，在高延遲下的性能挑戰(zhàn)變得尤為重要。

X-Paxos針對(duì)高延遲網(wǎng)絡(luò)做了大量的協(xié)議優(yōu)化嘗試和測(cè)試，并結(jié)合學(xué)術(shù)界現(xiàn)有的理論成果[5,6,7]通過(guò)合理的Batching和Pipelining，設(shè)計(jì)并實(shí)現(xiàn)了一整套自適應(yīng)的針對(duì)高延遲高吞吐和低延遲高吞吐網(wǎng)絡(luò)的通信模式，極大的提升了X-Paxos的性能(對(duì)比見(jiàn)下節(jié))。類似的優(yōu)化在同類競(jìng)品中還非常的罕見(jiàn)。

Batching是指，將多個(gè)日志合并成單個(gè)消息進(jìn)行發(fā)送;Batching可以有效的降低消息粒度帶來(lái)的額外損耗，提升吞吐。但是過(guò)大Batching容易造成單請(qǐng)求的延遲過(guò)大，導(dǎo)致并發(fā)請(qǐng)求數(shù)過(guò)高，繼而影響了吞吐和請(qǐng)求延遲。

Pipelining是指在上一個(gè)消息返回結(jié)果以前，并發(fā)的發(fā)送下一個(gè)消息到對(duì)應(yīng)節(jié)點(diǎn)的機(jī)制，通過(guò)提高并發(fā)發(fā)送消息數(shù)量(Pipelining數(shù)量)，可以有效的降低并發(fā)單請(qǐng)求延遲，同時(shí)在transmission delay小于propagationdelay的時(shí)候(高延遲高吞吐網(wǎng)絡(luò))，有效提升性能。

經(jīng)推導(dǎo)可知 Batching(消息大小:M)和Pipeling(消息并發(fā):P)在如下關(guān)系下，達(dá)到***吞吐

M/R * P = D

其中R為網(wǎng)絡(luò)帶寬，D為網(wǎng)絡(luò)傳播延遲(propagation delay，約為RTT/2)X-Paxos結(jié)合以上理論，通過(guò)內(nèi)置探測(cè)，針對(duì)不同節(jié)點(diǎn)的部署延遲，自適應(yīng)的調(diào)整針對(duì)每個(gè)節(jié)點(diǎn)的Batching和Pipeling參數(shù)，達(dá)到整體的***吞吐。

Pipeling的引入，需要解決日志的亂序問(wèn)題，特別是在異地場(chǎng)景下，window加大，加大了亂序的概率。X-Paxos實(shí)現(xiàn)了一個(gè)高效的亂序處理模塊，可以對(duì)底層日志實(shí)現(xiàn)屏蔽亂序問(wèn)題，實(shí)現(xiàn)高效的亂序日志存儲(chǔ)。

??

2. 多線程，全異步的Paxos庫(kù)

由于Paxos的內(nèi)部狀態(tài)復(fù)雜，實(shí)現(xiàn)高效的單實(shí)例多線程的Paxos變成一個(gè)非常大的挑戰(zhàn)。無(wú)論我們上面提到的github中star最多的phxpaxos，還是Oracle MySQL Group Replication中使用的xcom，都是單線程的實(shí)現(xiàn)。phxpaxos采用了單分區(qū)單線程，多實(shí)例聚合的方式提升總吞吐，但是對(duì)單分區(qū)的性能非常的有限;而xcom是一個(gè)基于協(xié)程的單線程實(shí)現(xiàn)。單線程的Paxos實(shí)現(xiàn)，在處理序列化/反序列化，分發(fā)、發(fā)包等邏輯的時(shí)候都為串行執(zhí)行，性能瓶頸明顯。

X-Paxos完全基于多線程實(shí)現(xiàn)，可以在單個(gè)分區(qū)Paxos中完全的使用多線程的能力，所有的任務(wù)都有通用的woker來(lái)運(yùn)行，消除了CPU的瓶頸。依賴于服務(wù)層的多線程異步框架和異步網(wǎng)絡(luò)層，X-Paxos除了必要的協(xié)議串行點(diǎn)外，大部分操作都可以并發(fā)執(zhí)行，并且部分協(xié)議串行點(diǎn)采用了無(wú)鎖設(shè)計(jì)，可以有效利用多線程能力，實(shí)現(xiàn)了Paxos的單分區(qū)多線程能力，單分區(qū)性能遠(yuǎn)超競(jìng)品，甚至超過(guò)了競(jìng)品的多分區(qū)分區(qū)性能。

3. Locality Aware ContentDistribution

基于unique proposer的分布式系統(tǒng)的存在的一個(gè)瓶頸點(diǎn)就是主節(jié)點(diǎn)是唯一的內(nèi)容輸出源，當(dāng)集群存在大量節(jié)點(diǎn)的時(shí)候，主節(jié)點(diǎn)的大量網(wǎng)絡(luò)收發(fā)工作會(huì)導(dǎo)致主節(jié)點(diǎn)的負(fù)載過(guò)大，引發(fā)CPU和帶寬的瓶頸;在全國(guó)/全球部署的時(shí)候，所有節(jié)點(diǎn)和主節(jié)點(diǎn)之間的直接通信會(huì)造成跨region之間的長(zhǎng)傳/國(guó)際鏈路的帶寬占用過(guò)大。

X-Paxos是旨在解決全球分布式強(qiáng)一致問(wèn)題的Paxos獨(dú)立庫(kù)，在設(shè)計(jì)之初就考慮到了這個(gè)問(wèn)題。X-Paxos在穩(wěn)態(tài)運(yùn)行時(shí)會(huì)感知各個(gè)節(jié)點(diǎn)之間的網(wǎng)絡(luò)延遲(物理距離)，并形成級(jí)聯(lián)拓?fù)洌行Ы档椭鞴?jié)點(diǎn)的負(fù)載，降低長(zhǎng)傳鏈路的帶寬使用;而在有節(jié)點(diǎn)異常的時(shí)候，又會(huì)自動(dòng)重組拓?fù)洌ＷC各個(gè)存活節(jié)點(diǎn)間的同行的正常進(jìn)行。同時(shí)X-Paxos支持有業(yè)務(wù)來(lái)設(shè)定重組拓?fù)涞囊?guī)則，業(yè)務(wù)可以根據(jù)自己APP的部署架構(gòu)和延遲特性來(lái)針對(duì)性的設(shè)置拓?fù)渲亟M規(guī)則。

??

4. 可插拔日志

X-Paxos和現(xiàn)有的大部分paxos庫(kù)很大的不同點(diǎn)就是X-Paxos支持可插拔的日志模塊。日志模塊是Paxos中一個(gè)重要的模塊，它的持久化關(guān)系到數(shù)據(jù)的一致性，它的讀寫(xiě)性能很大程度上會(huì)影響協(xié)議整體的讀寫(xiě)性能。當(dāng)前大部分獨(dú)立Paxos庫(kù)都是內(nèi)置日志模塊，并且不支持插拔的。這會(huì)帶來(lái)2個(gè)弊端：

1. 默認(rèn)的日志模塊提供通用的功能，很難結(jié)合具體的系統(tǒng)做針對(duì)性的優(yōu)化
2. 現(xiàn)有的系統(tǒng)往往已經(jīng)存在了WAL(Write Ahead Log),而Paxos協(xié)議中需要再存一份。這使得 a)單次commit本地需要sync 2次(影響性能);b)雙份日志浪費(fèi)了大量的存儲(chǔ)

例如：phxpaxos內(nèi)置的日志模塊采用LevelDB，作為日志系統(tǒng)其操作大量冗余，無(wú)針對(duì)優(yōu)化，性能堪憂;同時(shí)采用phxpaxos的phxsql單節(jié)點(diǎn)需要即保存binlog，又保存Paxos log(在獨(dú)立的phxbinlogsvr中)，嚴(yán)重影響了性能，浪費(fèi)了存儲(chǔ)空間。而采用X-Paxos的AliSQL X-Cluster直接改造了現(xiàn)有的binlog模塊，對(duì)接到X-Paxos的日志模塊，單節(jié)點(diǎn)僅一份日志，即降低了存儲(chǔ)，又提高了性能。

分布式正確性驗(yàn)證

對(duì)于一個(gè)分布式強(qiáng)一致協(xié)議來(lái)說(shuō)，正確性是生命線。上文已經(jīng)提及，一個(gè)分布式強(qiáng)一致協(xié)議，很難完整的理論證明其正確性，再加上工程實(shí)現(xiàn)的問(wèn)題，困難就更多了。我們從理論和工程2方面用了大量的理論和技術(shù)手段來(lái)保證X-Paxos的正確性和完備性。

1. Jepsen

• Jepsen是開(kāi)源社區(qū)比較公認(rèn)的分布式數(shù)據(jù)庫(kù)的測(cè)試框架。Jepsen驗(yàn)證過(guò)包VoltDB、CockroachDB、Galera、MongoDB、etcd在內(nèi)的幾乎所有的主流分布式數(shù)據(jù)庫(kù)/系統(tǒng)，檢驗(yàn)出了不少的問(wèn)題。
•  X-Paxos完成了和Jepsen的對(duì)接，并驗(yàn)證了各個(gè)分布式數(shù)據(jù)庫(kù)已有的case。

2. TLA+

• TLA+是Paxos創(chuàng)始人、圖靈獎(jiǎng)獲得者Leslie Lamport老爺子發(fā)明的一種形式化規(guī)約語(yǔ)言。TLA+專用于設(shè)計(jì)、建模和驗(yàn)證分布式并發(fā)系統(tǒng)。Amazon DynamoDB/S3/EBSMicrosoftCosmos DB都通過(guò)TLA+的模型驗(yàn)證發(fā)現(xiàn)了不少問(wèn)題
• X-Paxos目前已經(jīng)通過(guò)了TLA+的模型驗(yàn)證。

3. 隨機(jī)異常系統(tǒng)

• 我們搭建了一套自動(dòng)隨機(jī)異常驗(yàn)證系統(tǒng)，可以自動(dòng)化驗(yàn)證各種異常場(chǎng)景下的協(xié)議正確性和穩(wěn)定性。驗(yàn)證X-Paxos在模擬網(wǎng)絡(luò)丟包、閃斷、隔離，磁盤(pán)故障等情況下的功能正確和數(shù)據(jù)一致。

4. 異?；貧w系統(tǒng)

• X-Paxos擁有一套異常case回歸系統(tǒng)，對(duì)于曾經(jīng)出現(xiàn)過(guò)或者預(yù)期的并發(fā)異常case，都會(huì)加到異常case庫(kù)中，進(jìn)行日?；貧w驗(yàn)證。同時(shí)異常case庫(kù)也在不斷的豐富中。

競(jìng)品分析和對(duì)比

XCOM (MySQL Group Replication)

MySQL GroupReplication是MySQL官方借鑒Galera的思想，在MySQL上構(gòu)建分布式強(qiáng)一致集群的一個(gè)插件。MySQL Group Replication早期采用的分布式協(xié)議是CoroSync，這是由Red Hat開(kāi)發(fā)的基于Totem(The Totem Single-Ring Ordering and MembershipProtocol)[8]協(xié)議開(kāi)發(fā)的分布式一致性協(xié)議庫(kù);由于Totem算法本身存在的一些局限性能原因，從MySQL 5.7.9以后，官方采用了自己研發(fā)的基于類Paxos(Mencius)[10]的一致性協(xié)議庫(kù)XCOM。

XCOM是MySQL Group Replication的核心組件，稱為Group Communication Core[9]。我們分析了XCOM的源碼，XCOM內(nèi)部是一個(gè)由純C語(yǔ)言編譯的核心模塊以及有C++實(shí)現(xiàn)的proxy實(shí)現(xiàn)的系統(tǒng)。純C模塊由單線程驅(qū)動(dòng)，依賴協(xié)程實(shí)現(xiàn)任務(wù)調(diào)度。因此Client(MySQL GroupReplication Plugin)必須用tcp連接向XCOM發(fā)送請(qǐng)求。因此XCOM存在如下的不足之處:

1. 單線程驅(qū)動(dòng)，無(wú)多線程能力

• 架構(gòu)決定，很難突破

2. 通信流需要額外的一次TCP協(xié)議棧

• 在內(nèi)存拷貝都要精細(xì)計(jì)算的應(yīng)用中，線程間多一次網(wǎng)絡(luò)通信很難接受

3. XCOM雖然實(shí)現(xiàn)了Batching和Pipelining，但是其值均為固定值，很難適應(yīng)真實(shí)的場(chǎng)景

• 官方的文檔中也提到了這一點(diǎn)[9]
• 這也使得MySQL Group Replication在跨Region場(chǎng)景中性能很不理想(見(jiàn)AliSQL X-Cluster對(duì)比測(cè)試)

phxpaxos (phxsql)

phxpaxos是騰訊推出的基于Paxos協(xié)議的獨(dú)立庫(kù)，其和MySQL結(jié)合后推出了phxsql項(xiàng)目，也是基于MySQL實(shí)現(xiàn)的分布式強(qiáng)一致MySQL集群。phxpaxos可獨(dú)立用于其他項(xiàng)目，是目前github上star最多(1000+)的Paxos獨(dú)立庫(kù)。關(guān)于phxsql的細(xì)節(jié)本文不再敘述，可以參考(AliSQL X-Cluster的競(jìng)品分析部分)，我們這里主要分析phxpaxos。

phxpaxos也是基于multi-Paxos實(shí)現(xiàn)的獨(dú)立庫(kù)，其架構(gòu)上采用單Paxos單線程設(shè)計(jì)，但是支持多Paxos分區(qū)以擴(kuò)展多線程能力，這種擴(kuò)展需要多數(shù)據(jù)進(jìn)行提前分區(qū)。因此phxpaxos的不足之處如下：

1. 單Paxos對(duì)象只支持單線程;可支持多Paxos對(duì)象，共享網(wǎng)絡(luò)層
2. 不支持pipelining，在跨Region環(huán)境(高延遲)下，幾乎不可用
3. 多份日志冗余，基于LevelDB的日子系統(tǒng)性能瓶頸

性能對(duì)比

我們還是拿騰訊的phxpaxos作為競(jìng)品和我們進(jìn)行對(duì)比(XCOM無(wú)獨(dú)立組件，可間接參考MySQL Group Replication和AliSQL X-Cluster的對(duì)比測(cè)試結(jié)果)

我們分別在a) Region內(nèi)3節(jié)點(diǎn)部署 b) 3個(gè)Region各一個(gè)節(jié)點(diǎn)部署調(diào)節(jié)下,以不同的請(qǐng)求大小進(jìn)行壓測(cè)。

??

??

從上面2個(gè)對(duì)比圖中可以看到：

1. X-Paxos的同Region性能是phxpaxos的100倍以上
2. 跨Region場(chǎng)景下phxpaxos幾乎不可用，而X-Paxos在444Byte(sysbench insert場(chǎng)景單請(qǐng)求大小)，性能只有3.5%的下降，幾乎不影響吞吐。

現(xiàn)狀與未來(lái)

現(xiàn)狀

目前X-Paxos一期已經(jīng)發(fā)布上線。

基于X-Paxos的集團(tuán)數(shù)據(jù)庫(kù)團(tuán)隊(duì)產(chǎn)品AliSQL X-Cluster已在集團(tuán)內(nèi)廣泛使用。

X-Paxos和業(yè)務(wù)系統(tǒng)結(jié)合打造的分布式服務(wù)也相繼落地上線。

未來(lái)

Paxos是分布式系統(tǒng)的基石，即使是近幾年，學(xué)術(shù)界關(guān)于Paxos的文章，新的演進(jìn)方向一致在不斷的涌現(xiàn)，我們的X-Paxos也會(huì)不停的發(fā)展，以更好的適應(yīng)集團(tuán)內(nèi)外的需求，未來(lái)主要的發(fā)展方向如下：

• 高效率，多分區(qū)支持

? 基于新的異步框架，實(shí)現(xiàn)一個(gè)深度底層共享的多分區(qū)Paxos

• 多節(jié)點(diǎn)強(qiáng)一致讀

? 經(jīng)典的multi-paxos只有在leader上才能提供強(qiáng)一致讀，spanner和業(yè)界都有一些在多節(jié)點(diǎn)上提供強(qiáng)一致讀的方案，但還是有比較明顯的缺陷。

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

??戳這里，看該作者更多好文??