通俗易懂的Paxos算法-基於消息傳遞的一致性算法

通俗易懂Paxos算法（屁民）講解：

  先說Paxos，它是一個基於消息傳遞的一致性算法，Leslie Lamport在1990年提出，近幾年被普遍應用於分佈式計算中，Google的Chubby，Apache的Zookeeper都是基於它的理論來實現的，Paxos還被認爲是到目前爲止惟一的分佈式一致性算法，其它的算法都是Paxos的改進或簡化。有個問題要提一下，Paxos有一個前提：沒有拜占庭將軍問題。就是說Paxos只有在一個可信的計算環境中才能成立，這個環境是不會被入侵所破壞的。

  關於Paxos的具體描述能夠在Wiki中找到：zh.wikipedia.org/zh-cn/Paxos… Server的對應關係。

  Paxos描述了這樣一個場景，有一個叫作Paxos的小島(Island)上面住了一批居民，島上面全部的事情由一些特殊的人決定，他們叫作議員(Senator)。議員的總數(Senator Count)是肯定的，不能更改。島上每次環境事務的變動都須要經過一個提議(Proposal)，每一個提議都有一個編號(PID)，這個編號是一直增加的，不能倒退。每一個提議都須要超過半數((Senator Count)/2 +1)的議員贊成才能生效。每一個議員只會贊成大於當前編號的提議，包括已生效的和未生效的。若是議員收到小於等於當前編號的提議，他會拒絕，並告知對方：你的提議已經有人提過了。這裏的當前編號是每一個議員在本身記事本上面記錄的編號，他不斷更新這個編號。整個議會不能保證全部議員記事本上的編號老是相同的。如今議會有一個目標：保證全部的議員對於提議都能達成一致的見解。

  好，如今議會開始運做，全部議員一開始記事本上面記錄的編號都是0。有一個議員發了一個提議：將電費設定爲1元/度。他首先看了一下記事本，嗯，當前提議編號是0，那麼個人這個提議的編號就是1，因而他給全部議員發消息：1號提議，設定電費1元/度。其餘議員收到消息之後查了一下記事本，哦，當前提議編號是0，這個提議可接受，因而他記錄下這個提議並回復：我接受你的1號提議，同時他在記事本上記錄：當前提議編號爲1。發起提議的議員收到了超過半數的回覆，當即給全部人發通知：1號提議生效！收到的議員會修改他的記事本，將1好提議由記錄改爲正式的法令，當有人問他電費爲多少時，他會查見解令並告訴對方：1元/度。

  如今看衝突的解決：假設總共有三個議員S1-S3，S1和S2同時發起了一個提議:1號提議，設定電費。S1想設爲1元/度, S2想設爲2元/度。結果S3先收到了S1的提議，因而他作了和前面一樣的操做。緊接着他又收到了S2的提議，結果他一查記事本，咦，這個提議的編號小於等於個人當前編號1，因而他拒絕了這個提議：對不起，這個提議先前提過了。因而S2的提議被拒絕，S1正式發佈了提議: 1號提議生效。S2向S1或者S3打聽並更新了1號法令的內容，而後他能夠選擇繼續發起2號提議。

  好，我以爲Paxos的精華就這麼多內容。如今讓咱們來對號入座，看看在ZK Server裏面Paxos是如何得以貫徹實施的。

ZK Server與ZK Server映射關係：

1. 小島(Island)——ZK Server Cluster

2. 議員(Senator)——ZK Server

3. 提議(Proposal)——ZNode Change(Create/Delete/SetData…)

4. 提議編號(PID)——Zxid(ZooKeeper Transaction Id)

5. 正式法令——全部ZNode及其數據

貌似關鍵的概念都能一一對應上，可是等一下，Paxos島上的議員應該是人人平等的吧，而ZK Server好像有一個Leader的概念。沒錯，其實Leader的概念也應該屬於Paxos範疇的。若是議員人人平等，在某種狀況下會因爲提議的衝突而產生一個「活鎖」（所謂活鎖個人理解是你們都沒有死，都在動，可是一直解決不了衝突問題）。Paxos的做者Lamport在他的文章」The Part-Time Parliament「中闡述了這個問題並給出瞭解決方案——在全部議員中設立一個總統，只有總統有權發出提議，若是議員有本身的提議，必須發給總統並由總統來提出。好，咱們又多了一個角色：總統。

總統——ZK Server Leader

又一個問題產生了，總統怎麼選出來的？oh, my god! It’s a long story. 在淘寶核心系統團隊的Blog上面有一篇文章是介紹如何選出總統的，有興趣的能夠去看看：rdc.taobao.com/blog/cs/?p=…

如今咱們假設總統已經選好了，下面看看ZK Server是怎麼實施的。

狀況一：

屁民甲(Client)到某個議員(ZK Server)那裏詢問(Get)某條法令的狀況(ZNode的數據)，議員堅決果斷的拿出他的記事本(local storage)，查閱法令並告訴他結果，同時聲明：個人數據不必定是最新的。你想要最新的數據？沒問題，等着，等我找總統Sync一下再告訴你。

狀況二：

屁民乙(Client)到某個議員(ZK Server)那裏要求政府歸還欠他的一萬元錢，議員讓他在辦公室等着，本身將問題反映給了總統，總統詢問全部議員的意見，多數議員表示欠屁民的錢必定要還，因而總統發表聲明，從國庫中拿出一萬元還債，國庫總資產由100萬變成99萬。屁民乙拿到錢回去了(Client函數返回)。

狀況三：

總統忽然掛了，議員連續不斷的發現聯繫不上總統，因而各自發表聲明，推選新的總統，總統大選期間政府停業，拒絕屁民的請求。

呵呵，到此爲止吧，固然還有不少其餘的狀況，但這些狀況老是能在Paxos的算法中找到原型並加以解決。這也正是咱們認爲Paxos是Zookeeper的靈魂的緣由。固然ZK Server還有不少屬於本身特性的東西：Session, Watcher，Version等等等等，須要咱們花更多的時間去研究和學習。

轉載於文章《Zookeeper全解析——Paxos做爲靈魂》 連接：www.douban.com/note/208430…