號稱史上最晦澀的算法Paxos，如何變得平易近人？
背景
分布式一致性算法(Consensus Algorithm)是一個分布式計算領(lǐng)域的基礎(chǔ)性問題，其最基本的功能是為了在多個進(jìn)程之間對某個(某些)值達(dá)成一致(強一致);進(jìn)而解決分布式系統(tǒng)的可用性問題(高可用)。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年了，從***個Paxos的工業(yè)實現(xiàn)到現(xiàn)在也已經(jīng)11年了，但是直到近幾年，無論是***會議，還是業(yè)內(nèi)，Paxos相關(guān)的文章和項目還是層出不窮。
轉(zhuǎn)向業(yè)內(nèi)，雖然使用了Paxos及各種變種的產(chǎn)品已經(jīng)層出不窮;但是真正工業(yè)級的，獨立的，Paxos基礎(chǔ)庫還是相當(dāng)?shù)纳僖姡篏oogle并沒有開源其任何Paxos基礎(chǔ)庫(連包含Paxos的項目都沒有開源過); Facebook也沒有公布過包含Paxos的產(chǎn)品; Apache有Zookeeper，但是其協(xié)議并不能支持一個高吞吐的狀態(tài)機復(fù)制，且并沒有提供獨立的第三方庫，可供快速接入。
在Github上能找到的Paxos的獨立庫，star***的是騰訊于去年開源的phxpaxos(后文會作為競品進(jìn)行詳細(xì)對比)。
因此到目前為止業(yè)內(nèi)還鮮有成熟可靠的，可供快速使用的獨立第三方Paxos庫，開源的Paxos生態(tài)也尚未成熟。
X-Paxos
愿景
我們的初衷并不是要做一個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)隊團(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，變得平易近人，帶入千萬家。
架構(gòu)
?? 
X-Paxos的整體架構(gòu)如上圖所示，主要可分為網(wǎng)絡(luò)層、服務(wù)層、算法模塊、日志模塊4個部分
網(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ù)的代碼
以上一行程序，包含了定時器的創(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，功能變的更加豐富，在多種部署場景下性能都有明顯的提升。下一章中，將對這些優(yōu)化進(jìn)行詳細(xì)的介紹。
日志模塊
日志模塊本是算法模塊的一部分，但是出于對***性能要求的考慮，我們把日志模塊獨立出來，并實現(xiàn)了一個默認(rèn)的高性能的日志模塊;有***性能以及成本需求的用戶，可以結(jié)合已有的日志系統(tǒng)，對接日志模塊接口，以獲取更高的性能和更低的成本。這也是X-Paxos作為高性能獨立庫特有的優(yōu)勢，下一章會進(jìn)行詳細(xì)的介紹。
功能增強
結(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 PointObjective)為 Tb
- SDK方案
? X-Paxos支持由SDK訂閱增量日志，備份系統(tǒng)只需要簡單的實現(xiàn)從SDK流到OSS流的對接，即可實現(xiàn)流式備份
? RPO (Recovery PointObjective)為 0除備份以外，Witness SDK在下游流式訂閱(DRC)、自封閉高可用系統(tǒng)(X-Driver)、異步只讀備庫等方面都有實戰(zhàn)案例，更多的應(yīng)用案例在不斷的添加中。
性能優(yōu)化
我們一直堅信網(wǎng)絡(luò)延遲不應(yīng)該影響吞吐
1. 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(消息大小: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é)合以上理論，通過內(nèi)置探測，針對不同節(jié)點的部署延遲，自適應(yīng)的調(diào)整針對每個節(jié)點的Batching和Pipeling參數(shù)，達(dá)到整體的***吞吐。
Pipeling的引入，需要解決日志的亂序問題，特別是在異地場景下，window加大，加大了亂序的概率。X-Paxos實現(xiàn)了一個高效的亂序處理模塊，可以對底層日志實現(xiàn)屏蔽亂序問題，實現(xiàn)高效的亂序日志存儲。
?? 
2. 多線程，全異步的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ū)分區(qū)性能。
3. Locality Aware ContentDistribution
基于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ù)洌ＷC各個存活節(jié)點間的同行的正常進(jìn)行。同時X-Paxos支持有業(yè)務(wù)來設(shè)定重組拓?fù)涞囊?guī)則，業(yè)務(wù)可以根據(jù)自己APP的部署架構(gòu)和延遲特性來針對性的設(shè)置拓?fù)渲亟M規(guī)則。
?? 
4. 可插拔日志
X-Paxos和現(xiàn)有的大部分paxos庫很大的不同點就是X-Paxos支持可插拔的日志模塊。日志模塊是Paxos中一個重要的模塊，它的持久化關(guān)系到數(shù)據(jù)的一致性，它的讀寫性能很大程度上會影響協(xié)議整體的讀寫性能。當(dāng)前大部分獨立Paxos庫都是內(nèi)置日志模塊，并且不支持插拔的。這會帶來2個弊端：
- 默認(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é)點僅一份日志，即降低了存儲，又提高了性能。
分布式正確性驗證
對于一個分布式強一致協(xié)議來說，正確性是生命線。上文已經(jīng)提及，一個分布式強一致協(xié)議，很難完整的理論證明其正確性，再加上工程實現(xiàn)的問題，困難就更多了。我們從理論和工程2方面用了大量的理論和技術(shù)手段來保證X-Paxos的正確性和完備性。
1. 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。
2. TLA+
- TLA+是Paxos創(chuàng)始人、圖靈獎獲得者Leslie Lamport老爺子發(fā)明的一種形式化規(guī)約語言。TLA+專用于設(shè)計、建模和驗證分布式并發(fā)系統(tǒng)。Amazon DynamoDB/S3/EBSMicrosoftCosmos DB都通過TLA+的模型驗證發(fā)現(xiàn)了不少問題
- X-Paxos目前已經(jīng)通過了TLA+的模型驗證。
3. 隨機異常系統(tǒng)
- 我們搭建了一套自動隨機異常驗證系統(tǒng)，可以自動化驗證各種異常場景下的協(xié)議正確性和穩(wěn)定性。驗證X-Paxos在模擬網(wǎng)絡(luò)丟包、閃斷、隔離，磁盤故障等情況下的功能正確和數(shù)據(jù)一致。
4. 異?；貧w系統(tǒng)
- X-Paxos擁有一套異常case回歸系統(tǒng)，對于曾經(jīng)出現(xiàn)過或者預(yù)期的并發(fā)異常case，都會加到異常case庫中，進(jìn)行日?；貧w驗證。同時異常case庫也在不斷的豐富中。
競品分析和對比
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實現(xiàn)的系統(tǒng)。純C模塊由單線程驅(qū)動，依賴協(xié)程實現(xiàn)任務(wù)調(diào)度。因此Client(MySQL GroupReplication Plugin)必須用tcp連接向XCOM發(fā)送請求。因此XCOM存在如下的不足之處:
1. 單線程驅(qū)動，無多線程能力
- 架構(gòu)決定，很難突破
2. 通信流需要額外的一次TCP協(xié)議棧
- 在內(nèi)存拷貝都要精細(xì)計算的應(yīng)用中，線程間多一次網(wǎng)絡(luò)通信很難接受
3. 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)行壓測。
?? 
?? 
從上面2個對比圖中可以看到：
- X-Paxos的同Region性能是phxpaxos的100倍以上
- 跨Region場景下phxpaxos幾乎不可用，而X-Paxos在444Byte(sysbench insert場景單請求大小)，性能只有3.5%的下降，幾乎不影響吞吐。
現(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é)點上提供強一致讀的方案，但還是有比較明顯的缺陷。
【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
