PAXOS VS ZAB

paxos協議的核心想法之一就是少數服從多數！其實就是制定一套固定的策略，在各類狀況下都可以選出一個決議。

咱們假定有A,B,C,D,E五臺機器。kv系統須要put一個數據[key=Whisper -> val=3306]到咱們這5臺機器上，要保證只要反饋爲真，任意兩臺機器掛掉都不會丟失數據，而且能夠保證高可用。怎麼作：

1. 首先,客戶端隨機選擇一個節點，進行寫入提交，這裏咱們隨機選擇了C這個節點，這時候C節點就是此次提議的發起人【也叫proposer，在老的2pc協議裏也叫作coodinator】，當C收到這個提議的時候，C首先要作的事情是根據當前節點的最新全局global id，作一次自增操做，咱們假定，在當時全局id,Global ID是0,因此，這個議案就被對應了一個編號，1--->[key=Whisper -> val=3306]。 而後，他會嘗試將這個信息發送給其他的A,B,D,E這幾臺機器。
2. 若是A,B,D,E這幾臺機器的globalID 小於C給出的決議的GID(1--->[key=Whisper -> val=3306])，那麼就告訴C，這個決議被批准了。而若是A,B,D,E這幾臺機器的GlobalID 大於或等於C給出決議的GID.那麼就告知C 這個決議不可以被批准。
3. 咱們假定A,B兩臺機器當時的Max(GID)是0 ，而D,E的Max(GID)是1.那麼，A,B兩臺機器會反饋給C說協議被接受，這時候咱們算算，C的議案有幾票了？A+B+!C!，必定要算本身哦:) 。因此，這個議案有三票，5臺機器的半數是3.超過法定人數，因而決議就被贊成了。

這時候還有一個問題是須要被考慮的，若是在C已經得知決議已經達到法定人數，在告知全部人接受以前，C掛了，應該怎麼辦呢？ 我之因此沒有將這個放到開始的描述裏，主要緣由是以爲這是個獨立因素，不該該影響議案被接受時候的清晰度。 爲了解決這個問題，須要要求全部的accepter在接受某我的提出的議案以後，額外的記錄一個信息：當前accepter接受了哪一個提議者的議案。

爲何要記錄這個？很簡單，咱們看一下上面出現這個狀況時候的判斷標準。 A 機器:角色-accepter 。 批准的議案 1--->[key=Whisper-> val=3306] 。提議人：C B 機器:角色-accepter 。 批准的議案 1--->[key=Whisper-> val=3306] 。提議人：C C機器:角色-proposer 。 掛了。。不知道他的狀況。 D 機器:角色-accepter 。 批准的議案 1--->[key=taobao->val=1234] 。提議人：本身 E 機器:角色-proposer。 「提議的」議案 1--->[key=taobao->val=1234] 。提議人：D。

由於有了提議人這個記錄，因此在超時後很容易能夠判斷，議案1--->[key=Whisper -> val=3306] 是取得了多數派的議案，由於雖然D,E兩臺機器也是能夠達成一致的議案的。但由於有我的自己是提議者，因此能夠算出這個議案是少數派。 在這以後，提議者還須要作一件事，就是告知D,E，被決定的決議已是什麼了。便可。

那麼Paxos有沒有什麼值得改進的地方？有的，很簡單，你會發現，若是在一個決議提議的過程當中，其餘決議會被否決，否決自己意味着更多的網絡io，意味着更多的衝突，這些衝突都是須要額外的開銷的，代價很大很大。

其實，這也是在咱們的現實生活中常常可以發現的，若是每一個議案都要通過議會的討論和表決，那麼這個國家的決策無疑是低效的，怎麼解決這個問題呢？弄個總統就好了。zab協議就是本着這個思路來改進paxos協議的。

zab協議把整個過程分爲兩個部分，第一個部分叫選總統，第二個部分叫進行決議。 選總統的過程比較特殊，這種模式，相對的給人感受思路來源於lamport的麪包房算法，這個咱們後面講。，選擇的主要依據是： 1.若是有gid最大的機器，那麼他是主機。 2.若是好幾臺主機的gid相同，那麼按照序號選擇最小的那個。

因此，在開始的時候，給A,B,C,D,E進行編號，0,1,2,3,4。 第一輪的時候，由於你們的Max(gid)都是0，因此天然而然按照第二個規則，選擇A做爲主機。
     而後，全部人都知道A是主機之後，不管誰收到的請求，都直接轉發給A,由A機器去作後續的分發，這個分發的過程，咱們叫進行決議。

    **具體過程是，A會將決議precommit給B,C,D,E。而後等待，當B,C,D,E裏面的任意兩個返回收到後，就能夠進行doCommit().不然進行doAbort().**