建站
咨詢
售后
建站咨詢
新聞中心
Paxos(分布式一致性算法)作為分布式系統(tǒng)的基石，一直都是計(jì)算機(jī)系統(tǒng)工程領(lǐng)域的熱門(mén)話題。Paxos 號(hào)稱是最難理解的算法，其實(shí)當(dāng)真這么困難么?
成都創(chuàng)新互聯(lián)公司專注于北辰網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供北辰營(yíng)銷型網(wǎng)站建設(shè)，北辰網(wǎng)站制作、北辰網(wǎng)頁(yè)設(shè)計(jì)、北辰網(wǎng)站官網(wǎng)定制、成都微信小程序服務(wù)，打造北辰網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供北辰網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。
X-Paxos 是阿里巴巴數(shù)據(jù)庫(kù)團(tuán)隊(duì)面向高性能、全球部署以及阿里業(yè)務(wù)特征等需求，實(shí)現(xiàn)的一個(gè)高性能分布式強(qiáng)一致的 Paxos 獨(dú)立基礎(chǔ)庫(kù)。X-Paxos 具體有哪些優(yōu)勢(shì)，能給現(xiàn)有的系統(tǒng)帶來(lái)什么樣的收益呢?
X-Paxos 的愿景：將 Paxos 帶入千萬(wàn)家
雖然 Paxos 的理論提出已經(jīng) 17 年了，從***個(gè) Paxos 的工業(yè)實(shí)現(xiàn)到現(xiàn)在也已經(jīng) 11 年了，但是直到近幾年，無(wú)論是***會(huì)議，還是業(yè)內(nèi)會(huì)議，與 Paxos 相關(guān)的文章和項(xiàng)目還是層出不窮。
轉(zhuǎn)向業(yè)內(nèi)，真正工業(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。
因此到目前為止，業(yè)內(nèi)還鮮有成熟可靠的，可供快速使用的獨(dú)立第三方的 Paxos 庫(kù)，開(kāi)源的 Paxos 生態(tài)也尚未成熟。
我們的初衷并不是要做一個(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ì)把 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)都是基于一個(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)家。
阿里巴巴 X-Paxos 應(yīng)用實(shí)踐
X-Paxos 的整體架構(gòu)
X-Paxos 的整體架構(gòu)如下圖所示，主要可分為網(wǎng)絡(luò)層、服務(wù)層、算法模塊、日志模塊四個(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ì)***性能要求的考慮，我們把日志模塊獨(dú)立出來(lái)，并實(shí)現(xiàn)了一個(gè)默認(rèn)的高性能的日志模塊。
有***性能以及成本需求的用戶，可以結(jié)合已有的日志系統(tǒng)，對(duì)接日志模塊接口，以獲取更高的性能和更低的成本。這也是 X-Paxos 作為高性能獨(dú)立庫(kù)特有的優(yōu)勢(shì)。
X-Paxos 的功能增強(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í)候，需要將主節(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)都擁有全部的功能。例如：
在經(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 功能。
我們希望可以有若干個(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 Point Objective)為 Tb。
- SDK 方案。X-Paxos 支持由 SDK 訂閱增量日志，備份系統(tǒng)只需要簡(jiǎn)單的實(shí)現(xiàn)從 SDK 流到 OSS 流的對(duì)接，即可實(shí)現(xiàn)流式備份。RPO (Recovery Point Objective)為 0。
除備份以外，Witness SDK 在下游流式訂閱(DRC)、自封閉高可用系統(tǒng)(X-Driver)、異步只讀備庫(kù)等方面都有實(shí)戰(zhàn)案例，更多的應(yīng)用案例在不斷的添加中。
X-Paxos 的性能優(yōu)化
我們一直堅(jiān)信網(wǎng)絡(luò)延遲不應(yīng)該影響吞吐。
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(消息大?。篗)和 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 通過(guò)一個(gè)高效的亂序處理模塊，可以對(duì)底層日志實(shí)現(xiàn)屏蔽亂序，實(shí)現(xiàn)高效的亂序日志存儲(chǔ)。
多線程，全異步的 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ū)性能。
Locality Aware Content Distribution
基于 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ù)?，保證各個(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ī)則。
可插拔日志
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)兩個(gè)弊端：
默認(rèn)的日志模塊提供通用的功能，很難結(jié)合具體的系統(tǒng)做針對(duì)性的優(yōu)化。
現(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ǔ)，又提高了性能。
X-Paxos 的分布式正確性驗(yàn)證
對(duì)于一個(gè)分布式強(qiáng)一致協(xié)議來(lái)說(shuō)，正確性是生命線。上文已經(jīng)提及，一個(gè)分布式強(qiáng)一致協(xié)議，很難完整的理論證明其正確性，再加上工程實(shí)現(xiàn)的問(wèn)題，困難就更多了。
我們從理論和工程兩方面用了大量的理論和技術(shù)手段來(lái)保證 X-Paxos 的正確性和完備性。
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。
TLA+
TLA+ 是 Paxos 創(chuàng)始人、圖靈獎(jiǎng)獲得者 Leslie Lamport 發(fā)明的一種形式化規(guī)約語(yǔ)言。 TLA+ 專用于設(shè)計(jì)、建模和驗(yàn)證分布式并發(fā)系統(tǒng)。Amazon DynamoDB/S3/EBS 和 MicrosoftCosmos DB 都通過(guò) TLA+ 的模型驗(yàn)證發(fā)現(xiàn)了不少問(wèn)題。
X-Paxos 目前已經(jīng)通過(guò)了 TLA+ 的模型驗(yàn)證。
隨機(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ù)一致。
異常回歸系統(tǒng)
X-Paxos 擁有一套異常 case 回歸系統(tǒng)，對(duì)于曾經(jīng)出現(xiàn)過(guò)或者預(yù)期的并發(fā)異常 case，都會(huì)加到異常 case 庫(kù)中，進(jìn)行日常回歸驗(yàn)證。同時(shí)異常 case 庫(kù)也在不斷的豐富中。
X-Paxos 的競(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 的系統(tǒng)。
純 C 模塊由單線程驅(qū)動(dòng)，依賴協(xié)程實(shí)現(xiàn)任務(wù)調(diào)度。因此 Client(MySQL GroupReplication Plugin)必須用 TCP 連接向 XCOM 發(fā)送請(qǐng)求。
因此 XCOM 存在如下的不足之處：
- 單線程驅(qū)動(dòng)，無(wú)多線程能力。架構(gòu)決定，很難突破。
- 通信流需要額外的一次 TCP 協(xié)議棧。在內(nèi)存拷貝都要精細(xì)計(jì)算的應(yīng)用中，線程間多一次網(wǎng)絡(luò)通信很難接受。
- 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 的不足之處，如下：
單 Paxos 對(duì)象只支持單線程，可支持多 Paxos 對(duì)象，共享網(wǎng)絡(luò)層。
不支持 pipelining，在跨 Region 環(huán)境(高延遲)下，幾乎不可用。
多份日志冗余，基于 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è)。
從上面兩個(gè)對(duì)比圖中可以看到：
- X-Paxos 的同 Region 性能是 phxpaxos 的 100 倍以上。
- 跨 Region 場(chǎng)景下 phxpaxos 幾乎不可用，而 X-Paxos 在 444Byte(sysbench insert 場(chǎng)景單請(qǐng)求大小)，性能只有 3.5% 的下降，幾乎不影響吞吐。
X-Paxos的現(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)一致讀的方案，但還是有比較明顯的缺陷。
參考文件：
|
[1]The part-time parliament [2]The Chubby lock service for loosely-coupled distributed systems [3]Paxos Made Simple [4]Paxos Made Live - An Engineering Perspective [5]Everything You Ever Wanted to Know About Message Latency [6]Adaptive Batching for Replicated Servers [7]Tuning Paxos for high-throughput with batching and pipelining [8]The Totem single-ring ordering and membership protocol [9]Group Replication: A Journey to the Group Communication Core [10]Mencius: Building Efficient Replicated State Machines for WANs |
當(dāng)前文章：強(qiáng)一致、高可用、自動(dòng)容災(zāi)能力背后，阿里X-Paxos的應(yīng)用實(shí)踐
文章轉(zhuǎn)載：http://www.5511xx.com/article/ccdccsh.html
