paxos是什么？

一致性算法，google稱其為唯一的一致性算法，其他的算法都是paxos的簡化。

我們知道一般數據庫的主從同步，實際上在極端情況下，依然會產生不一致的現象，這就造成了master的損壞，需要手動的切換備機，而在paxos中，由于一致性算法，我們可

以做到自動的進行master的切換，而不會產生不一致的現象，當然這個要在一個大前提下，就是n臺機器，僅有小于 n/2的機器損壞，但這樣依然提供了我們一種更高的容災標準。

jbpaxos是什么？

jbpaxos = java  basic paxos , java語言實現的paxos編程框架，提供高可用，強一致，基于paxos構建分布式程序的框架。

適用的場景？

對于一般的應用而言，沒有數據的保存，僅僅是提供服務，那么我們可以說這些server對于數據而言是無狀態的，比如說，我們多數的java web應用，這些應用所需要的數據，

要么在緩存里，要么在 db里，那這些server僅僅需要提供一個更穩定的負載器來進行故障轉移即可了，實際上整套系統的一致性和容災全部交由另外的系統來解決（db,緩存，

穩定的負載均衡），這些server 是不適用paxos算法的。

對于另外一些應用，我們需要自己維護數據副本，不依賴于第3方服務的，比較適合paxos，自動選主，主故障時，15s恢復期，可提供強一致性，誘人的特性，但這些特性，也

不是沒有代價，更高的網絡負載，更高的寫入延時,如果你能忍受這些，那么請選擇paxos吧。

構建高可用的分布式程序，不是有zookeeper嗎?

zookeeper提供了類似chubby的功能，可以說zookeeper提供的是一種服務，jbpaxos提供的是更底層的算法實現，基于接口的編程，就可以實現類似與zookeeper的功能

通過jbpaxos，可以自由的實現副本間的同步，zookeeper提供服務的形式，是無法提供副本間同步的功能，副本間同步的功能，請參見下面的demo,實際上，每個config server 就是一份副本

jbpaxos 0.0.1beta提供了什么？

一個classic paxos的實現，應對磁盤損壞，主機宕機，可以做到15s恢復，提供了paxos的底層實現，提供了網絡層的接口，二次開發不需要考慮網絡層上的開發，基于此項目的二次開發，可以實現高可用的配置中心，分布式鎖，基于paxos的副本同步機制等等。

根據網絡情況，和設定的最大 rt 容忍時間，自動運行時調整封包大小，最大化網絡利用率。

0.0.1beta暫時沒有提供fellower的實現，僅僅有senator的實現

jbpaxos 0.0.1beta中的概念

senators,用于寫入時投票的節點，fellowers（下個版本實現，對于配置中心類似的多讀少寫的應用比較有用）,僅僅學習的節點，不參與投票過程

master , 從senators中選舉出的法官，它來發起一項法案的投票

jbpaxos 的基本性能

3個節點時，寫入大小128bytes, 單線程單tcp連接非阻塞同步寫入3w+ tps , 1000線程單tcp連接阻塞同步寫入2.5w+ , 3線程3個 tcp連接非阻塞同步寫入4w+ ，單線程同步寫入200tps

寫入大小512bytes ,3線程3個 tcp連接非阻塞同步寫入3w+

寫入大小1024bytes,3線程3個 tcp連接非阻塞同步寫入1.6w+ 

512及1024bytes的時候，基本上將千兆網卡頂滿了

如果說節點上升到5個的時候，吞吐會下降，寫入的大小影響系統性能非常多，所以建議在開發的時候寫入數據需要經過壓縮，建議使用snappy或lzo這種高吞吐的壓縮算法

讀取性能，要看二次開發的實現如何，及服務端口，是否和內部系統端口，走同一塊網卡

當前的總體架構圖

\

架構解說：5個config server 為互備節點，當2個節點（包含2個）以下損壞，不會影響服務，client連接上任一節點即可，對于跨機房部署，要優先連接最近的節點

后續架構：jbpaxos下個版本，預計支持fellower,當下個版本發布后，config server不做代碼修改，即可將架構變為下圖：

后續架構解說：相比兩種架構區別,后一種，在擴展更高連接量時，有非常大的優勢，fellower的數量決定了可以支撐的client 的數量，但對寫入沒有幫助，反而會加大寫入的延時，適合于像配置中心這類多監視變化，少修改的類型

程序架構圖： 紅框的部分，是我們需要做的