Paxos算法細節詳解(一)--經過現實世界描述算法

Paxos分析

最近研究paxos算法，看了許多相關的文章，概念仍是很模糊，以爲仍是沒有掌握paxos算法的精髓，因此花了3天時間分析了libpaxos3的全部代碼，此代碼能夠從https://bitbucket.org/sciascid/libpaxos 下載。對paxos算法有初步瞭解以後，再看此文的效果會更好；若是你也想分析libpaxos3的話，此文應該會對你有不小幫助；關於paxos的歷史這裏很少作介紹，關於描述paxos算法寫的最好的一篇文章應該就是維基百科了，地址戳這裏：http://zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95

 

在paxos算法中，分爲4種角色：

  Proposer ：提議者

  Acceptor：決策者

  Client：產生議題者

  Learner：最終決策學習者

上面4種角色中，提議者和決策者是很重要的，其餘的2個角色在整個算法中應該算作打醬油的，Proposer就像Client的使者，由Proposer使者拿着Client的議題去向Acceptor提議，讓Acceptor來決策。這裏上面出現了個新名詞：最終決策。如今來系統的介紹一下paxos算法中全部的行爲：

1. Proposer提出議題
2. Acceptor初步接受 或者 Acceptor初步不接受
3. 若是上一步Acceptor初步接受則Proposer再次向Acceptor確認是否最終接受
4. Acceptor 最終接受 或者Acceptor 最終不接受

上面Learner最終學習的目標是Acceptor們最終接受了什麼議題？注意，這裏是向全部Acceptor學習，若是有多數派個Acceptor最終接受了某提議，那就獲得了最終的結果，算法的目的就達到了。畫一幅圖來更加直觀：

 

爲何須要3個Acceptor？由於Acceptor必須是最少大於等於3個，而且必須是奇數個，由於要造成多數派嘛，若是是偶數個，好比4個，2個接受2個不接受，互不相讓，無法搞下去了。

爲何是3個Proposer？ 其實無所謂是多少個了，1~n 均可以的；若是是1個proposer，毫無競爭壓力，很順利的完成2階段提交，Acceptor們最終批准了事。若是是多個proposer就比較複雜了，請繼續看。

 

上面的圖中是畫了不少節點的，每一個節點須要一臺機器麼？答案是不須要的，上面的圖是邏輯圖，物理中，能夠將Acceptor和Proposer以及Client放到一臺機器上，只是使用了不一樣的端口號罷了，Acceptor們啓動不一樣端口的TCP監聽，Proposer來主動鏈接便可；徹底能夠將Client、Proposer、Acceptor、Learner合併到一個程序裏面；這裏舉一個例子：好比開發一個JOB程序，JOB程序部署在多臺服務器上(數量爲奇數)，這些JOB有可能同時處理一項任務，如今使用paxos算法讓這些JOB本身來商量由誰(哪臺機器)來處理這項任務，這樣JOB程序裏就須要包含Client、Proposer、Acceptor、Learner這4大功能，而且須要配置其餘JOB服務器的IP地址。

再舉一個例子，zookeeper經常用來作分佈式事務鎖。Zookeeper所使用的zad協議也是相似paxos協議的。全部分佈式自協商一致性算法都是paxos算法的簡化或者變種。Client是使用zookeeper服務的機器，Zookeeper自身包含了Acceptor, Proposer, Learner。Zookeeper領導選舉就是paxos過程，還有Client對Zookeeper寫Znode時，也是要進行Paxos過程的，由於不一樣Client可能鏈接不一樣的Zookeeper服務器來寫Znode，到底哪一個Client才能寫成功？須要依靠Zookeeper的paxos保證一致性，寫成功Znode的Client天然就是被最終接受了，Znode包含了寫入Client的IP與端口，其餘的Client也能夠讀取到這個Znode來進行Learner。也就是說在Zookeeper自身包含了Learner(由於Zookeeper爲了保證自身的一致性而會進行領導選舉，因此須要有Learner的內部機制，多個Zookeeper服務器之間須要知道如今誰是領導了)，Client端也能夠Learner，Learner是廣義的。

 

如今經過一則故事來學習paxos的算法的流程(2階段提交)，有2個Client(老闆，老闆之間是競爭關係)和3個Acceptor(政府官員)：

1. 如今須要對一項議題來進行paxos過程，議題是「A項目我要中標！」，這裏的「我」指每一個帶着他的祕書Proposer的Client老闆。
2. Proposer固然聽老闆的話了，趕忙帶着議題和現金去找Acceptor政府官員。
3. 做爲政府官員，固然想誰給的錢多就把項目給誰。
4. Proposer-1小姐帶着現金同時找到了Acceptor-1~Acceptor-3官員，1與2號官員分別收取了10比特幣，找到第3號官員時，沒想到遭到了3號官員的鄙視，3號官員告訴她，Proposer-2給了11比特幣。不過不要緊，Proposer-1已經獲得了1,2兩個官員的承認，造成了多數派(若是沒有造成多數派，Proposer-1會去銀行提款在來找官員們給每人20比特幣，這個過程一直重複每次+10比特幣，直到多數派的造成)，滿意的找老闆覆命去了，可是此時Proposer-2保鏢找到了1,2號官員，分別給了他們11比特幣，1,2號官員的態度馬上轉變，都說Proposer-2的老闆懂事，這下子Proposer-2放心了，搞定了3個官員，找老闆覆命去了，固然這個過程是第一階段提交，只是官員們初步接受賄賂而已。故事中的比特幣是編號，議題是value。

　　　　這個過程保證了在某一時刻，某一個proposer的議題會造成一個多數派進行初步支持；

 ===============華麗的分割線，第一階段結束================

　　5.　如今進入第二階段提交，如今proposer-1小姐使用分身術(多線程併發)分了3個本身分別去找3位官員，最早找到了1號官員籤合同，遭到了1號官員的鄙視，1號官員告訴他proposer-2先生給了他11比特幣，由於上一條規則的性質proposer-1小姐知道proposer-2第一階段在她以後又造成了多數派(至少有2位官員的贓款被更新了);此時她趕忙去提款準備從新賄賂這3個官員(從新進入第一階段)，每人20比特幣。剛給1號官員20比特幣， 1號官員很高興初步接受了議題，還沒來得及見到2,3號官員的時候

這時proposer-2先生也使用分身術分別找3位官員(注意這裏是proposer-2的第二階段)，被第1號官員拒絕了告訴他收到了20比特幣，第2,3號官員順利簽了合同，這時2，3號官員記錄client-2老闆用了11比特幣中標，由於造成了多數派，因此最終接受了Client2老闆中標這個議題，對於proposer-2先生已經出色的完成了工做；

這時proposer-1小姐找到了2號官員，官員告訴她合同已經簽了，將合同給她看，proposer-1小姐是一個沒有什麼職業操守的聰明人，以爲跟Client1老闆混沒什麼前途，因此將本身的議題修改成「Client2老闆中標」，而且給了2號官員20比特幣，這樣造成了一個多數派。順利的再次進入第二階段。因爲此時沒有人競爭了，順利的找3位官員籤合同，3位官員看到議題與上次一次的合同是一致的，因此最終接受了，造成了多數派，proposer-1小姐跳槽到Client2老闆的公司去了。

===============華麗的分割線，第二階段結束===============

　　Paxos過程結束了，這樣，一致性獲得了保證，算法運行到最後全部的proposer都投「client2中標」全部的acceptor都接受這個議題，也就是說在最初的第二階段，議題是先入爲主的，誰先佔了先機，後面的proposer在第一階段就會學習到這個議題而修改本身自己的議題，由於這樣沒職業操守，才能讓一致性獲得保證，這就是paxos算法的一個過程。原來paxos算法裏的角色都是這樣的不靠譜，不過不要緊，結果靠譜就能夠了。該算法就是爲了追求結果的一致性。