如何評價阿里最近推出的paxos基礎庫？

01-14

目前沒有看到代碼，只有文章：
X-Paxos――阿里巴巴的高性能分散式強一致Paxos獨立基礎庫-IT168 技術開發專區
與微信之前開源的paxos庫對比，有何區別？

本人phxpaxos作者受邀強答一波。

首先聲明我看了這篇文章之後，從某些字眼，比如「100倍」，更像是一個公關文而不是技術討論，所以我不會對這個文章做任何評論，本樓也不會對評論做任何回復。接下來我想說說phxpaxos.

1. phxpaxos去年開源之時就沒以世界上首個生產級paxos類庫進行宣傳，不過現在我想說，它當然是世界上首個生產級的類庫。（如果您認為微信幾千台伺服器的部署規模算生產級的話）

2. phxpaxos早已開源，大家都看得到代碼，除了高性能，也要照顧到其易用性，開放性以及代碼可閱讀性，我們開源的初衷不是要顯示自己多厲害，更多是抱著推廣分散式一致性演算法的目的。代碼就在那，有心人一看便知。

3. 據了解微信正在籌備開源一套在微信後台大規模使用的分散式隊列組件，而其底層一致性保證就是基於phxpaxos的。

一個工業級PAXOS的實現需要滿足三點

1. 完善的基礎協議實現

2. 靈活的調用API

3. 工業級的代碼質量

PAXOS是典型的「魔鬼在於細節」的東西，目前從這個文章說

X-Paxos當前的演算法基於unique proposer的multi-paxos[3]

算是選了一個公認性能比較好的基礎協議來實現。其他的方面？no code no love.

騰訊的PhxPaxos，目前是開源的Paxos獨立庫中start最多的（1000+），其和MySQL結合後推出了PhxSQL項目，但是其在功能和性能上並不能滿足阿里的需求。X-Paxos是阿里巴巴資料庫團隊面向高性能、全球部署以及阿里業務特徵等需求，實現的高性能分散式強一致的 Paxos 獨立基礎庫，並和AliSQL結合後推出了AliSQL X-Cluster項目。

X-Paxos和PhxPaxos都是基於Multi-Paxos實現的Paxos獨立庫，二者主要的區別如下：

PhxPaxos可支持多Paxos實例，共享網路層，但是每個Paxos實例只支持單線程；X-Paxos目前僅支持單Paxos實例，但完全基於多線程實現，可以在單個Paxos實例中完全使用多線程的能力，所有的任務都有通用的woker線程來運行，消除了CPU的瓶頸。
PhxPaxos不支持Pipelining，在跨地域環境（高延遲）下，效率很低，幾乎不可用；而X-Paxos完美支持Batching和Pipelining，而且通過內置探測，針對不同節點的部署延遲，自適應的調整每個節點的Batching和Pipeling參數，達到整體的最大吞吐。
PhxPaxos內置日誌模塊，日誌直接基於LevelDB實現，多份日誌冗餘；而X-Paxos實現可插拔的日誌，應用程序可根據需求實現自己的日誌模塊，消除日誌冗餘。採用PhxPaxos的PhxSQL單節點需要既保存MySQL的binlog，又保存Paxos log，單次commit本地需要sync 2次，既影響性能，又浪費了存儲空間。而採用X-Paxos的AliSQL X-Cluster直接改造了現有的binlog模塊，對接到X-Paxos的日誌模塊，單節點僅一份日誌，即降低了存儲，又提高了性能。
X-Paxos做了很多附加功能，比如在線添加/刪除節點，在線轉讓Leader，策略化多數派和權重化選主，節點角色定製化（Proposer/Accepter/Learner的獨立配置）等。
PhxPaxos去年已經開源，X-Paxos目前沒有開源，但是其設計和工程實踐心得已公布，對於業界非常有參考意義，相信熟悉Paxos演算法的人應該能夠自己實現出來。

X-Paxos和PhxPaxos性能對比如下：

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

X-Paxos的同地域內性能是PhxPaxos的100倍以上。
跨地域場景下PhxPaxos幾乎不可用，而X-Paxos在444Byte（sysbench insert場景單請求大小），性能只有3.5%的下降，幾乎不影響吞吐。

利益相關：X-Paxos的鏍絲釘

以阿里的德性，大概又會在網上大肆吹噓一波？

# 利益相關: X-Paxos作者，我就說2點

1. 文章說的很細，相信分散式領域的同學看完全文後，會有自己的判斷這是技術文還是PR文

2. 關於開源：目前沒開源，我們在努力

利益相關，曾經在phx系列搬磚過。

我對這個比較感興趣，直覺上這個是未經過工程實踐證明(演練)過的特性。希望有更多的細節一起學習下:

1. 如果被設置為必須擁有最新數據的機器宕機，xpaxos如何處理failover?

2. 這個特性在最簡單的三機模型上肯定是沒法用的，如果是多機，那麼又涉及到具體的region分布，只有2region是沒法做region級容災的。就假設只有三個region，每個region有三機吧。最壞情況下保持擁有最新數據的機器在三個region的數量是3+1+1，此時擁有3的region斷網，paxos要求至少需要5機最新，如果按樸素的工程實現就是讓剩餘6機通過learner對齊多數派後繼續工作。xpaxos的優化應該就是針對這個場景，但問題在與他們需要在平時就保持至少5機同步才有效果，這5機在策略上應該怎麼配置呢？

3. 這種策略會放大單機的波動對整個集群的影響，xpaxos又是怎麼處理這裡的細節的？

希望早日見到代碼一睹真相。

不要再指望阿里能為開源再做些什麼了，技術號基本都轉型成阿里雲的營銷號了，各種演講都是阿里雲產品的宣講，問一些技術性的問題也不怎麼正面回答了。而且現在基本都是售前技術出來演講。

一個不開源的去對比一個開源的，開源的沒法回應啊？就算不開源，發個版本出來大家驗證一下唄，畢竟快100倍。

認真讀了阿里的報告，看到他們的測試似乎是在64核的伺服器上的測試，x-paxos開多線程的話應該能充分利用CPU~

想知道，在4核，8核，16核的場景下，多線程x-paxos能充分發揮多線程的威力嗎？多線程實現的x-paxos和mysql由duff-device實現的單線程協程實現的paxos有多大的性能差，寫程序的都知道，多線程不代表性能就高啊~

因為使用場景主要還是mysql，生產中mysql本身還是小實例比較好用，所以一台物理機常常用cgroup分割成若干個，那麼在8核，16核這樣的場景下，x-paxos的性能到底是如何的呢？

以前看阿里的報告，提到aliSQL似乎改過優化器了，拿sysbench測試似乎不能直接反映出mysql的GR的paxos實現和x-paxos在paxos實現上的性能差距啊~至少應該是優化器一樣的前提下，只更換paxos狀態機實現，這樣的測試結果比較有說服力~

虛心學習中，拭目以待x-paxos開源~

X-Paxos 理論和實現都經過了 TLA+、Jepsen 等分散式測試框架的驗證

驗證充分的話，相當牛逼啊！