Paxos(分布式一致性算法)作為分布式系統(tǒng)的基石，一直都是計算機系統(tǒng)工程領(lǐng)域的熱門話題。Paxos 號稱是最難理解的算法，其實當(dāng)真這么困難么?

X-Paxos 是阿里巴巴數(shù)據(jù)庫團(tuán)隊面向高性能、全球部署以及阿里業(yè)務(wù)特征等需求，實現(xiàn)的一個高性能分布式強一致的 Paxos 獨立基礎(chǔ)庫。X-Paxos 具體有哪些優(yōu)勢，能給現(xiàn)有的系統(tǒng)帶來什么樣的收益呢?

[[199324]]

X-Paxos 的愿景：將 Paxos 帶入千萬家

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

轉(zhuǎn)向業(yè)內(nèi)，真正工業(yè)級的、獨立的 Paxos 基礎(chǔ)庫還是相當(dāng)?shù)纳僖姡?/span>

• Google 并沒有開源任何 Paxos 基礎(chǔ)庫(連包含 Paxos 的項目都沒有開源過)。
• Facebook 也沒有公布過包含 Paxos 的產(chǎn)品。
• Apache 有 Zookeeper，但是其協(xié)議并不能支持一個高吞吐的狀態(tài)機復(fù)制，且并沒有提供獨立的第三方庫，可供快速接入。
• 在 Github 上，能找到的 Paxos 的獨立庫，star ***的是騰訊去年開源的 phxpaxos。

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

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

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

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

例如，團(tuán)隊內(nèi)的同學(xué)把 X-Paxos 融入到單機 KV 數(shù)據(jù)庫 RocksDB 中，快速實現(xiàn)了一個分布式 KV 引擎。集團(tuán)已有業(yè)務(wù)團(tuán)隊把 X-Paxos 融入到業(yè)務(wù)存儲系統(tǒng)中，構(gòu)建全新的分布式強一致存儲服務(wù)。同時也正是 AliSQL X-Cluster，成就了 X-Paxos。Google 的論文《Paxos made live》中有一段話說的很好，大意是說：Paxos 從理論到現(xiàn)實世界的實現(xiàn)之間有巨大的鴻溝，在真正實現(xiàn)一個 Paxos 的時候，往往需要對 Paxos 的經(jīng)典理論做一些擴展。

尤其是在實現(xiàn)一個高性能的 Paxos 的時候，擴展點就更多了，可以參考后文的功能增強和性能優(yōu)化，這往往會導(dǎo)致真正的 Paxos 實現(xiàn)都是基于一個未被完全證明的協(xié)議。這也就是傳說中，理論證明一個 Paxos 的實現(xiàn)，比實現(xiàn)這個 Paxos 還要難的原因了。因此一個成熟的 Paxos 實現(xiàn)很難獨立產(chǎn)生，往往需要和一個系統(tǒng)結(jié)合在一起，通過一個或者多個系統(tǒng)來驗證其可靠性和完備性。這也是為什么大部分成熟的 Paxos 案例都是和分布式數(shù)據(jù)庫相結(jié)合的，例如最早的 Paxos 實現(xiàn)(Chubby)，當(dāng)前的主要 Paxos 實現(xiàn)(Google 的 MegaStore、Spanner，AWS 的 DynamoDB、S3 等)。而 X-Paxos 正是依托于 AliSQL X-Cluster 驗證了其可靠性和完備性。

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

阿里巴巴 X-Paxos 應(yīng)用實踐

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

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

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

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

服務(wù)層

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

X-Paxos 的服務(wù)層是一個基于 C++11 特性實現(xiàn)的多線程異步框架。常見的狀態(tài)機/回調(diào)模型存在開發(fā)效率較低，可讀性差等問題，一直被開發(fā)者所詬病。

而協(xié)程又因其單線程的瓶頸，而使其應(yīng)用場景受到限制。C++11 以后的新版本提供了***轉(zhuǎn)發(fā)(argument forwarding)、可變模板參數(shù)(variadic templates)等特性，為我們能夠?qū)崿F(xiàn)一種全新的異步調(diào)用模型提供了可能。

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

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

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

算法模塊

X-Paxos 當(dāng)前的算法基于 unique proposer 的 multi-paxos [3] 實現(xiàn)，大量理論和實踐已經(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ù)的場景以及高性能和生態(tài)的需求，X-Paxos 做了很多的創(chuàng)新性的功能和性能的優(yōu)化，使其相對于基礎(chǔ)的 multi-paxos，功能變的更加豐富，在多種部署場景下性能都有明顯的提升。

日志模塊

日志模塊本是算法模塊的一部分，但是出于對***性能要求的考慮，我們把日志模塊獨立出來，并實現(xiàn)了一個默認(rèn)的高性能的日志模塊。

有***性能以及成本需求的用戶，可以結(jié)合已有的日志系統(tǒng)，對接日志模塊接口，以獲取更高的性能和更低的成本。這也是 X-Paxos 作為高性能獨立庫特有的優(yōu)勢。

X-Paxos 的功能增強

我們結(jié)合廣泛的業(yè)務(wù)場景，構(gòu)建開放的生態(tài)：

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

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

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

目前，阿里集團(tuán)及螞蟻金服的多地有中心的架構(gòu)，很多應(yīng)用因其部署的特點，往往要求它在未發(fā)生城市級容災(zāi)的情況下，僅在中心寫入數(shù)據(jù)庫，或調(diào)用其他分布式服務(wù)。

同時又要求在發(fā)生城市級容災(zāi)的時候(同一個城市的多個機房全部不可用)，可以在完全不丟失任何數(shù)據(jù)的情況下，將寫入點切換到非中心。

而經(jīng)典的 multi-paxos 并不能滿足這些需求。經(jīng)典理論中，多數(shù)派強同步以后即可完成提交，而多數(shù)派是非特定的，并不能保證某個/某些節(jié)點一定能得到完整的數(shù)據(jù)，并激活服務(wù)。

在實際實現(xiàn)中，往往地理位置較近的節(jié)點會擁有強一致的數(shù)據(jù)，而地理位置較遠(yuǎn)的節(jié)點，一直處于非強一致節(jié)點，在容災(zāi)的時候永遠(yuǎn)無法激活為主節(jié)點，這樣就形同虛設(shè)。

同時，當(dāng)中心單節(jié)點出現(xiàn)故障需要容災(zāi)的時候，往往需要將主節(jié)點就近切換到同中心的另外一個節(jié)點。由于應(yīng)用在多地的部署往往是非對稱的原因，出現(xiàn)單個 Region 全掛的時候，需要將主節(jié)點切到特定的 Region 內(nèi)。

這些需求都需要 Paxos 在選主的時候，可以由用戶指定規(guī)則，而經(jīng)典理論中同樣沒有類似的功能，添加權(quán)重也需要保證 Paxos 的正確性。

X-Paxos 在協(xié)議中實現(xiàn)了策略化多數(shù)派和權(quán)重化選主：

基于策略化多數(shù)派，用戶可以通過動態(tài)配置，指定某個/某些節(jié)點必須保有強一致的數(shù)據(jù)，在出現(xiàn)容災(zāi)需求的時候，可以立即激活為主節(jié)點。

基于權(quán)重化選主，用戶可以指定各個節(jié)點的選主權(quán)重，只有在高權(quán)重的節(jié)點全部不可用的時候，才會激活低權(quán)重的節(jié)點。

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

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

在經(jīng)典的三個副本部署中，我們可以裁剪其中一個節(jié)點的狀態(tài)機，只保留日志(無數(shù)據(jù)的純?nèi)罩竟?jié)點，但是在同步中作為多數(shù)派計算)，此時我們需要裁剪掉協(xié)議中的 Proposer 功能(被選舉權(quán))，保留 Accepter 和 Learner 功能。

我們希望可以有若干個節(jié)點可以作為下游，訂閱/消費協(xié)議產(chǎn)生的日志流，而不作為集群的成員(不作為多數(shù)派計算，因為這些節(jié)點不保存日志流)，此時我們裁剪掉協(xié)議的 Proposer/Accepter 功能，只保留 Learner 功能。

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

4. Witness SDK

基于上節(jié)節(jié)點角色定制化中的單獨 Learner 角色的功能，引發(fā)了無窮的想象力。

Learner 角色，可以抽象成一個數(shù)據(jù)流訂閱者(Witness Node)，整個集群中可以加入無數(shù)個訂閱者，當(dāng)有新的日志被提交的時候，這些訂閱者會收到他關(guān)心的日志流，基于訂閱者功能。

我們可以讓一個集群很容易的實現(xiàn)下游訂閱消費，日志即時備份，配置變更推送等等的功能。

因此我們把 Learner 角色單獨封裝成了一個 SDK。基于這個 SDK，用戶可以快速地為自己的集群添加，訂閱注冊，流式訂閱定功能;結(jié)合特定的用途打造一個完整的生態(tài)。

例如，日志流 SDK 在 AliSQL X-Cluster 中打造的生態(tài)。如下圖，采用了 X-Paxos 也可以利用 Witness SDK 快速實現(xiàn)分布式系統(tǒng)和下游的其他系統(tǒng)的對接，形成一個完整的生態(tài)。

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

• 普通方案。每隔固定時間 Tb，將 MySQL 生成的 binlog 文件備份到***備份系統(tǒng)(OSS、S3 等)。RPO (Recovery Point Objective)為 Tb。
• SDK 方案。X-Paxos 支持由 SDK 訂閱增量日志，備份系統(tǒng)只需要簡單的實現(xiàn)從 SDK 流到 OSS 流的對接，即可實現(xiàn)流式備份。RPO (Recovery Point Objective)為 0。

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

X-Paxos 的性能優(yōu)化

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

Batching & Pipelining

Paxos 除了設(shè)計之初的強一致和高可用以外，其高性能也是至關(guān)重要的，尤其是應(yīng)用于 AliSQL X-Cluster 這種高性能分布式數(shù)據(jù)庫的時候，對協(xié)議的吞吐，延遲都提出了很高的要求。

同時作為可全球部署的分布式一致性協(xié)議，在高延遲下的性能挑戰(zhàn)變得尤為重要。

X-Paxos 針對高延遲網(wǎng)絡(luò)做了大量的協(xié)議優(yōu)化嘗試和測試，并結(jié)合學(xué)術(shù)界現(xiàn)有的理論成果 [5,6,7] 通過合理的 Batching 和 Pipelining，設(shè)計并實現(xiàn)了一整套自適應(yīng)的針對高延遲高吞吐和低延遲高吞吐網(wǎng)絡(luò)的通信模式。

極大的提升了 X-Paxos 的性能(對比見下節(jié))。類似的優(yōu)化在同類競品中還非常的罕見。

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

Pipelining 是指在上一個消息返回結(jié)果以前，并發(fā)的發(fā)送下一個消息到對應(yīng)節(jié)點的機制，通過提高并發(fā)發(fā)送消息數(shù)量(Pipelining 數(shù)量)，可以有效的降低并發(fā)單請求延遲。

同時在 transmission delay 小于 propagationdelay 的時候(高延遲高吞吐網(wǎng)絡(luò))，有效提升性能。

經(jīng)推導(dǎo)可知 Batching(消息大?。篗)和 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é)合以上理論，通過內(nèi)置探測，針對不同節(jié)點的部署延遲，自適應(yīng)的調(diào)整針對每個節(jié)點的 Batching 和 Pipeling 參數(shù)，達(dá)到整體的***吞吐。

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

多線程，全異步的 Paxos 庫

由于 Paxos 的內(nèi)部狀態(tài)復(fù)雜，實現(xiàn)高效的單實例多線程的 Paxos 變成一個非常大的挑戰(zhàn)。無論我們上面提到的 Github 中 star 最多的 phxpaxos，還是 Oracle MySQL Group Replication 中使用的 xcom，都是單線程的實現(xiàn)。

phxpaxos 采用了單分區(qū)單線程，多實例聚合的方式提升總吞吐，但是對單分區(qū)的性能提升非常有限;而 xcom 是一個基于協(xié)程的單線程實現(xiàn)。單線程的 Paxos 實現(xiàn)，在處理序列化/反序列化，分發(fā)、發(fā)包等邏輯的時候都為串行執(zhí)行，性能瓶頸明顯。

X-Paxos 是完全基于多線程實現(xiàn)的，可以在單個分區(qū) Paxos 中完全的使用多線程的能力，所有的任務(wù)都有通用的 woker 來運行，消除了 CPU 的瓶頸。

依賴于服務(wù)層的多線程異步框架和異步網(wǎng)絡(luò)層，X-Paxos 除了必要的協(xié)議串行點外，大部分操作都可以并發(fā)執(zhí)行，并且部分協(xié)議串行點采用了無鎖設(shè)計，可以有效利用多線程能力，實現(xiàn)了 Paxos 的單分區(qū)多線程能力，單分區(qū)性能遠(yuǎn)超競品，甚至超過了競品的多分區(qū)性能。

Locality Aware Content Distribution

基于 unique proposer 的分布式系統(tǒng)存在的一個瓶頸點就是主節(jié)點是唯一的內(nèi)容輸出源，當(dāng)集群存在大量節(jié)點的時候，主節(jié)點的大量網(wǎng)絡(luò)收發(fā)工作會導(dǎo)致主節(jié)點的負(fù)載過大，引發(fā) CPU 和帶寬的瓶頸。

在全國/全球部署的時候，所有節(jié)點和主節(jié)點之間的直接通信會造成跨 Region 之間的長傳/國際鏈路的帶寬占用過大。

X-Paxos 是旨在解決全球分布式強一致問題的 Paxos 獨立庫，在設(shè)計之初就考慮到了這個問題。

X-Paxos 在穩(wěn)態(tài)運行時會感知各個節(jié)點之間的網(wǎng)絡(luò)延遲(物理距離)，并形成級聯(lián)拓?fù)洌行Ы档椭鞴?jié)點的負(fù)載，降低長傳鏈路的帶寬使用;而在有節(jié)點異常的時候，又會自動重組拓?fù)?，保證各個存活節(jié)點間的同行的正常進(jìn)行。

同時 X-Paxos 支持由業(yè)務(wù)來設(shè)定重組拓?fù)涞囊?guī)則，業(yè)務(wù)可以根據(jù)自己 APP 的部署架構(gòu)和延遲特性來針對性的設(shè)置拓?fù)渲亟M規(guī)則。

可插拔日志

X-Paxos 和現(xiàn)有的大部分 paxos 庫很大的不同點就是 X-Paxos 支持可插拔的日志模塊。日志模塊是 Paxos 中一個重要的模塊，它的持久化關(guān)系到數(shù)據(jù)的一致性，它的讀寫性能很大程度上會影響協(xié)議整體的讀寫性能。

當(dāng)前大部分獨立 Paxos 庫都是內(nèi)置日志模塊，并且不支持插拔的。這會帶來兩個弊端：

默認(rèn)的日志模塊提供通用的功能，很難結(jié)合具體的系統(tǒng)做針對性的優(yōu)化。

現(xiàn)有的系統(tǒng)往往已經(jīng)存在了 WAL(Write Ahead Log)，而 Paxos 協(xié)議中需要再存一份。這使得 a)單次 commit 本地需要 sync 2 次(影響性能);b)雙份日志浪費了大量的存儲。

例如，phxpaxos 內(nèi)置的日志模塊采用的 LevelDB，作為日志系統(tǒng)其操作大量冗余，無針對優(yōu)化，性能堪憂。

同時采用 phxpaxos 的 phxsql 單節(jié)點需要既保存 binlog，又保存 Paxos log(在獨立的 phxbinlogsvr 中)，嚴(yán)重影響了性能，浪費了存儲空間。

而采用 X-Paxos 的 AliSQL X-Cluster 直接改造了現(xiàn)有的 binlog 模塊，對接到 X-Paxos 的日志模塊，單節(jié)點僅一份日志，既降低了存儲，又提高了性能。

X-Paxos 的分布式正確性驗證

對于一個分布式強一致協(xié)議來說，正確性是生命線。上文已經(jīng)提及，一個分布式強一致協(xié)議，很難完整的理論證明其正確性，再加上工程實現(xiàn)的問題，困難就更多了。

我們從理論和工程兩方面用了大量的理論和技術(shù)手段來保證 X-Paxos 的正確性和完備性。

Jepsen

Jepsen 是開源社區(qū)比較公認(rèn)的分布式數(shù)據(jù)庫的測試框架。Jepsen 驗證過程包括 VoltDB、CockroachDB、Galera、MongoDB、etcd 在內(nèi)的幾乎所有的主流分布式數(shù)據(jù)庫/系統(tǒng)，檢驗出了不少的問題。

X-Paxos 完成了和 Jepsen 的對接，并驗證了各個分布式數(shù)據(jù)庫已有的 case。

TLA+

TLA+ 是 Paxos 創(chuàng)始人、圖靈獎獲得者 Leslie Lamport 發(fā)明的一種形式化規(guī)約語言。 TLA+ 專用于設(shè)計、建模和驗證分布式并發(fā)系統(tǒng)。Amazon DynamoDB/S3/EBS 和 MicrosoftCosmos DB 都通過 TLA+ 的模型驗證發(fā)現(xiàn)了不少問題。

X-Paxos 目前已經(jīng)通過了 TLA+ 的模型驗證。

隨機異常系統(tǒng)

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

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

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

X-Paxos 的競品分析和對比

XCOM (MySQL Group Replication)

MySQL GroupReplication 是 MySQL 官方借鑒 Galera 的思想，在 MySQL 上構(gòu)建分布式強一致集群的一個插件。

MySQL Group Replication 早期采用的分布式協(xié)議是 CoroSync，它是由 Red Hat 開發(fā)的基于 Totem(The Totem Single-Ring Ordering and MembershipProtocol)[8] 協(xié)議開發(fā)的分布式一致性協(xié)議庫。

由于 Totem 算法本身存在的一些局限性能原因，從 MySQL 5.7.9 版本以后，官方采用了自己研發(fā)的基于類 Paxos(Mencius)[10] 的一致性協(xié)議庫 XCOM。

XCOM 是 MySQL Group Replication 的核心組件，稱為 Group Communication Core[9]。我們分析了 XCOM 的源碼，XCOM 內(nèi)部是一個由純 C 語言編譯的核心模塊以及由 C++ 實現(xiàn)的 proxy 的系統(tǒng)。

純 C 模塊由單線程驅(qū)動，依賴協(xié)程實現(xiàn)任務(wù)調(diào)度。因此 Client(MySQL GroupReplication Plugin)必須用 TCP 連接向 XCOM 發(fā)送請求。

因此 XCOM 存在如下的不足之處：

• 單線程驅(qū)動，無多線程能力。架構(gòu)決定，很難突破。
• 通信流需要額外的一次 TCP 協(xié)議棧。在內(nèi)存拷貝都要精細(xì)計算的應(yīng)用中，線程間多一次網(wǎng)絡(luò)通信很難接受。
• XCOM 雖然實現(xiàn)了 Batching 和 Pipelining，但是其值均為固定值，很難適應(yīng)真實的場景。官方的文檔中也提到了這一點[9]。這也使得 MySQL Group Replication 在跨 Region 場景中性能很不理想(見 AliSQL X-Cluster 對比測試)。

phxpaxos (phxsql)

phxpaxos 是騰訊推出的基于 Paxos 協(xié)議的獨立庫，它和 MySQL 結(jié)合后推出了 phxsql 項目，也是基于 MySQL 實現(xiàn)的分布式強一致 MySQL 集群。

phxpaxos 可獨立用于其他項目，是目前 Github 上 star 最多(1000+)的 Paxos 獨立庫。關(guān)于 phxsql 的細(xì)節(jié)本文不再敘述，可以參考(AliSQL X-Cluster 的競品分析部分)，我們這里主要分析 phxpaxos。

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

因此 phxpaxos 的不足之處，如下：

單 Paxos 對象只支持單線程，可支持多 Paxos 對象，共享網(wǎng)絡(luò)層。

不支持 pipelining，在跨 Region 環(huán)境(高延遲)下，幾乎不可用。

多份日志冗余，基于 LevelDB 的日志系統(tǒng)性能瓶頸。

性能對比

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

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

從上面兩個對比圖中可以看到：

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

X-Paxos的現(xiàn)狀與未來

現(xiàn)狀：目前 X-Paxos 一期已經(jīng)發(fā)布上線?；?X-Paxos 的集團(tuán)數(shù)據(jù)庫團(tuán)隊產(chǎn)品 AliSQL X-Cluster 已在集團(tuán)內(nèi)廣泛使用。X-Paxos 和業(yè)務(wù)系統(tǒng)結(jié)合打造的分布式服務(wù)也相繼落地上線。

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

未來主要的發(fā)展方向如下：

高效率，多分區(qū)支持。基于新的異步框架，實現(xiàn)一個深度底層共享的多分區(qū) Paxos。

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

參考文件：