Paxos算法在大型系統中常見的應用場景

在分佈式算法領域，有個很是重要的算法叫Paxos, 它的重要性有多高呢，Google的Chubby [1]中提到

all working protocols for asynchronous consensus we have so far encountered have Paxos at their core.

關於Paxos算法的詳述在維基百科中有更多介紹，中文版介紹的是choose value的規則[2]，英文版介紹的是Paxos 3 phase commit的流程[3]，中文版不是從英文版翻譯而是獨立寫的，因此很是具備互補性。Paxos算法是由Leslie Lamport提出的，他在Paxos Made Simple[4]中寫道

The Paxos algorithm, when presented in plain English, is very simple.

當你研究了很長一段時間Paxos算法仍是有點迷糊的時候，看到上面這句話可能會有點沮喪。可是公認的它的算法仍是比較繁瑣的，尤爲是要用程序員嚴謹的思惟將全部細節理清的時候，你的腦殼裏更是會充滿了問號。Leslie Lamport也是用了長達9年的時間來完善這個算法的理論。

實際上對於通常的開發人員，咱們並不須要瞭解Paxos全部細節及如何實現，只須要知道Paxos是一個分佈式選舉算法就夠了。本文主要介紹一下Paxos經常使用的應用場合，或許有一天當你的系統增大到必定規模，你知道有這樣一個技術，能夠幫助你正確及優雅的解決技術架構上一些難題。

1. database replication, log replication等， 如bdb的數據複製就是使用paxos兼容的算法。Paxos最大的用途就是保持多個節點數據的一致性。

2. naming service, 如大型系統內部一般存在多個接口服務相互調用。
1) 一般的實現是將服務的ip/hostname寫死在配置中，當service發生故障時候，經過手工更改配置文件或者修改DNS指向的方法來解決。缺點是可維護性差，內部的單元越多，故障率越大。
2) LVS雙機冗餘的方式，缺點是全部單元須要雙倍的資源投入。
經過Paxos算法來管理全部的naming服務，則可保證high available分配可用的service給client。象ZooKeeper還提供watch功能，即watch的對象發生了改變會自動發notification, 這樣全部的client就可使用一致的，高可用的接口。

3.config配置管理
1) 一般手工修改配置文件的方法，這樣容易出錯，也須要人工干預才能生效，因此節點的狀態沒法同時達到一致。
2) 大規模的應用都會實現本身的配置服務，好比用http web服務來實現配置中心化。它的缺點是更新後全部client沒法當即得知，各節點加載的順序沒法保證，形成系統中的配置不是同一狀態。

4.membership用戶角色/access control list, 好比在權限設置中，用戶一旦設置某項權限好比由管理員變成普通身份，這時應在全部的服務器上全部遠程CDN當即生效，不然就會致使不能接受的後果。

5. 號碼分配。一般簡單的解決方法是用數據庫自增ID, 這致使數據庫切分困難，或程序生成GUID, 這一般致使ID過長。更優雅的作法是利用paxos算法在多臺replicas之間選擇一個做爲master, 經過master來分配號碼。當master發生故障時，再用paxos選擇另一個master。

這裏列舉了一些常見的Paxos應用場合，對於相似上述的場合，若是用其它解決方案，一方面不能提供自動的高可用性方案，同時也遠遠沒有Paxos實現簡單及優雅。

Yahoo!開源的ZooKeeper [5]是一個開源的類Paxos實現。它的編程接口看起來很像一個可提供強一致性保證的分佈式小文件系統。對上面全部的場合均可以適用。但惋惜的是，ZooKeeper並非遵循Paxos協議，而是基於自身設計並優化的一個2 phase commit的協議，所以它的理論[6]並未通過徹底證實。但因爲ZooKeeper在Yahoo!內部已經成功應用在HBase, Yahoo! Message Broker, Fetch Service of Yahoo! crawler等系統上，所以徹底能夠放心採用。

另外選擇Paxos made live [7]中一段實現體會做爲結尾。

*  There are significant gaps between the description of the Paxos algorithm and the needs of a real-world system. In order to build a real-world system, an expert needs to use numerous ideas scattered in the literature and make several relatively small protocol extensions. The cumulative effort will be substantial and the final system will be based on an unproven protocol.
* 因爲chubby填補了Paxos論文中未說起的一些細節，因此最終的實現系統不是一個理論上徹底通過驗證的系統

* The fault-tolerance computing community has not developed the tools to make it easy to implement their algorithms.
* 分佈式容錯算法領域缺少幫助算法實現的的配套工具, 好比編譯領域儘管複雜，可是yacc, ANTLR等工具已經將這個領域的難度降到最低。

* The fault-tolerance computing community has not paid enough attention to testing, a key ingredient for building fault-tolerant systems.
* 分佈式容錯算法領域缺少測試手段

這裏要補充一個背景，就是要證實分佈式容錯算法的正確性一般比實現算法還困難，Google無法證實Chubby是可靠的，Yahoo!也不敢保證它的ZooKeeper理論正確性。大部分系統都是靠在實踐中運行很長一段時間才能謹慎的表示，目前系統已經基本沒有發現大的問題了。

Resources
[1] The Chubby lock service for loosely-coupled distributed systems (PDF)
[2] http://zh.wikipedia.org/wiki/Paxos算法
[3] http://en.wikipedia.org/wiki/Paxos_algorithm
[4] Paxos Made Simple (PDF)
[5] ZooKeeper
[6] The life and times of a zookeeper
[7] Paxos Made Live - An Engineering Perspective (PDF)