Paxos算法在大型系統(tǒng)中常見的應用場景是什么

本篇文章為大家展示了Paxos算法在大型系統(tǒng)中常見的應用場景是什么，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

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

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

關于Paxos算法的詳述在維基百科中有更多介紹，中文版介紹的是choose value的規(guī)則[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算法還是有點迷糊的時候，看到上面這句話可能會有點沮喪。但是公認的它的算法還是比較繁瑣的，尤其是要用程序員嚴謹?shù)乃季S將所有細節(jié)理清的時候，你的腦袋里更是會充滿了問號。Leslie Lamport也是用了長達9年的時間來完善這個算法的理論。

實際上對于一般的開發(fā)人員，我們并不需要了解Paxos所有細節(jié)及如何實現(xiàn)，只需要知道Paxos是一個分布式選舉算法就夠了。本文主要介紹一下Paxos常用的應用場合，或許有一天當你的系統(tǒng)增大到一定規(guī)模，你知道有這樣一個技術，可以幫助你正確及優(yōu)雅的解決技術架構上一些難題。

1. database replication, log replication等， 如bdb的數(shù)據(jù)復制就是使用paxos兼容的算法。Paxos最大的用途就是保持多個節(jié)點數(shù)據(jù)的一致性。

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

3.config配置管理
1) 通常手工修改配置文件的方法，這樣容易出錯，也需要人工干預才能生效，所以節(jié)點的狀態(tài)無法同時達到一致。
2) 大規(guī)模的應用都會實現(xiàn)自己的配置服務，比如用http web服務來實現(xiàn)配置中心化。它的缺點是更新后所有client無法立即得知，各節(jié)點加載的順序無法保證，造成系統(tǒng)中的配置不是同一狀態(tài)。

4.membership用戶角色/access control list, 比如在權限設置中，用戶一旦設置某項權限比如由管理員變成普通身份，這時應在所有的服務器上所有遠程CDN立即生效，否則就會導致不能接受的后果。

5. 號碼分配。通常簡單的解決方法是用數(shù)據(jù)庫自增ID, 這導致數(shù)據(jù)庫切分困難，或程序生成GUID, 這通常導致ID過長。更優(yōu)雅的做法是利用paxos算法在多臺replicas之間選擇一個作為master, 通過master來分配號碼。當master發(fā)生故障時，再用paxos選擇另外一個master。

這里列舉了一些常見的Paxos應用場合，對于類似上述的場合，如果用其它解決方案，一方面不能提供自動的高可用性方案，同時也遠遠沒有Paxos實現(xiàn)簡單及優(yōu)雅。

Yahoo!開源的ZooKeeper [5]是一個開源的類Paxos實現(xiàn)。它的編程接口看起來很像一個可提供強一致性保證的分布式小文件系統(tǒng)。對上面所有的場合都可以適用。但可惜的是，ZooKeeper并不是遵循Paxos協(xié)議，而是基于自身設計并優(yōu)化的一個2 phase commit的協(xié)議，因此它的理論[6]并未經(jīng)過完全證明。但由于ZooKeeper在Yahoo!內(nèi)部已經(jīng)成功應用在HBase, Yahoo! Message Broker, Fetch Service of Yahoo! crawler等系統(tǒng)上，因此完全可以放心采用。

另外選擇Paxos made live [7]中一段實現(xiàn)體會作為結(jié)尾。

*  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論文中未提及的一些細節(jié)，所以最終的實現(xiàn)系統(tǒng)不是一個理論上完全經(jīng)過驗證的系統(tǒng)

* The fault-tolerance computing community has not developed the tools to make it easy to implement their algorithms.
* 分布式容錯算法領域缺乏幫助算法實現(xiàn)的的配套工具, 比如編譯領域盡管復雜，但是yacc, ANTLR等工具已經(jīng)將這個領域的難度降到最低。

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

這里要補充一個背景，就是要證明分布式容錯算法的正確性通常比實現(xiàn)算法還困難，Google沒法證明Chubby是可靠的，Yahoo!也不敢保證它的ZooKeeper理論正確性。大部分系統(tǒng)都是靠在實踐中運行很長一段時間才能謹慎的表示，目前系統(tǒng)已經(jīng)基本沒有發(fā)現(xiàn)大的問題了。

上述內(nèi)容就是Paxos算法在大型系統(tǒng)中常見的應用場景是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業(yè)資訊頻道。