在分佈式算法領域，有個非常重要的算法叫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理論正確性。大部分系統都是靠在實踐中運行很長一段時間才能謹慎的表示，目前系統已經基本沒有發現大的問題了。