講一個關於paxos的故事...

先講一個故事。

從前，在國王Leslie Lamport的統治下，有個黑暗的希臘城邦叫paxos。城邦裏有3類人，

• 決策者
• 提議者
• 羣衆

雖然這是一個黑暗的城邦可是很民主，按照議會民主制的政治模式制訂法律，羣衆有什麼建議和意見均可以寫提案交給提議者，提議者會把提案交給決策者來決策，決策者有奇數個，爲何要奇數個？很簡單由於決策的方式很無腦，少數服從多數。最後決策者把剛出爐的決策昭告天下，羣衆得知決策結果。

等一下，那哪裏黑暗呢？問題就出在「提議者會把提案交給決策者來決策」，那麼多提案決策者先決策誰的？誰給的錢多就決策誰的。

那這樣會有幾個問題，決策者那麼多，怎麼保證最後決策的是同一個提案，以及怎麼保證拿到全部提議者中最高的報價。

聰明又貪婪的決策者想到了一個辦法：分兩階段報價

第一階段

1. 決策者接受全部比他當前持有報價高的報價，且不會通知以前報價的人
2. 提議者給全部決策者報價，如有人比本身報價高就加價，有半數以上決策者接受本身報價就中止報價。

第一階段結束的狀態

每一個提議者都以爲有半數以上的大佬接受了本身的提案，很開心。而決策者集團此刻的狀態是一致的，半數以上贊成的提案只有一個，這個就是報價最高的（由於高的老是能夠覆蓋低的），具體是誰提的who care，一致就行。

第二階段

提議者去找收過本身錢的大佬籤合同，這裏有3種狀況：

1. 大佬都收了別人更高的價，回去拿錢繼續賄賂，回到第一階段從新升級;
2. 大佬收到的最高報價是本身的，美滋滋，半數以上成功籤合同，提案成功;
3. 提議者回去拿錢回來繼續賄賂的時候發現合同已經被簽了且半數以上都簽了這個提案，不幹了，趕快把本身的提案換成已經簽了的提案，再去提給全部大佬，看看能不能分一杯羹碰見還沒簽的大佬。

第二階段結束的狀態

全部提議者手頭的提案都是同樣的，由於有「趕快把本身的提案換成已經簽了的提案」這一步;決策者集團全部成員最終接受的提案是同樣的。

好的目的已經達到了，把這個提案昭告天下，讓全部羣衆知道這件事。

故事說完了，用正確的姿式再簡單介紹下paxos

分佈式系統中的節點通訊存在兩種模型：共享內存（Shared memory）和消息傳遞（Messages passing）。

paxos做爲基於消息傳遞通訊模型的分佈式系統，不可避免的會發生如下錯誤：進程可能會慢、被殺死或者重啓，消息可能會延遲、丟失、重複，在基礎 Paxos 場景中，先不考慮可能出現消息篡改即拜占庭錯誤的狀況。

Paxos算法解決的問題是在一個可能發生上述異常的分佈式系統中如何就某個值達成一致，保證不論發生以上任何異常，都不會破壞決議的一致性。一個典型的場景是，在一個分佈式數據庫系統中，若是各節點的初始狀態一致，每一個節點都執行相同的操做序列，那麼他們最後能獲得一個一致的狀態。

爲保證每一個節點執行相同的命令序列，須要在每一條指令上執行一個「一致性算法」以保證每一個節點看到的指令一致。一個通用的一致性算法能夠應用在許多場景中，是分佈式計算中的重要問題。

Paxos用於解決分佈式系統中一致性問題，在一個Paxos過程只批准一個value，只有被prepare的value且被多數Acceptor接受才能被批准，被批准的value才能被learner。在paxos算法中，分爲4種角色：

• Acceptor：決策者
• Proposer ：提議者
• Client：產生議題者（羣衆）
• Learner：最終決策學習者（羣衆）

階段一：

1. Proposer向半數以上的Acceptor發送Prepare請求並附上編號N。
2. 若Acceptor收到一個編號爲N的Prepare請求，且N大於該Acceptor已經響應過的全部Prepare請求的編號，那麼它就會將它已經接受過的編號最大的提案（若是有的話）做爲響應反饋給Proposer，同時該Acceptor承諾再也不接受任何編號小於N的提案。
3. Proposer若沒有獲得半數以上Acceptor的響應，則編號+1繼續發起請求。

階段二：

1. 若是Proposer收到半數以上Acceptor對其發出的編號爲N的Prepare請求的響應，那麼它就會發送一個[N,提案]Accept請求給半數以上的Acceptor。
2. 若是Acceptor收到一個針對編號爲N的提案的Accept請求，只要該Acceptor沒有對編號大於N的Prepare請求作出過響應，它就接受該提案

看故事的時候不知道你們有沒有疑問，我是有的。

決策者Acceptor爲何要多個？

若只有一個acceptor多個proposer，acceptor能夠選任意一個提案，很美好，可是有單點問題。

爲何要用「半數以上經過」這個辦法來決策？

一個集合不可能同時存在兩個半數以上的子集，過半的思想保證提交的value在同一時刻在分佈式系統中是惟一的一致的。這種提交方式無論proposer接受到的消息是接受了誰的提議過半，只保證是有提議過半了的。而後再在第二階段肯定這個過半了的提議，讓全部節點知道這件事。所以算法若是能保證value被半數acceptor接受，則意味這此時被認定的value是惟一的。

爲何acceptor要接受多個提案？

若是acceptor只可以接受一個提案，則可能發生全部proposer提出的提案都沒法達到多數，決策者接收一個就結束了，狀態沒法一致。

當Proposer有不少個的時候，會有什麼問題？

很難有一個proposer收到半數以上的回覆，進而不斷地執行第一階段的協議，決策收斂速度慢，好久都不能作出一個決策。

提案爲何要帶上編號（即故事中用來賄賂的錢）？

帶上編號是爲了決策者能夠在自身接受到的提案的對比中作出最終的惟一決策。

試想若是按照提案到達時間對比提案，且不說這樣就變成了只接收一個第一到達的提案，還可能由於網絡緣由每一個決策者接受到的提案的前後順序不同，涼涼。

接着上面的問題，那若是把全部決策者收到的提案聚集起來選出個時間最先的呢？

把提案聚集，這時候確定須要一個master來作判斷，你們有沒發現這個master好像就變成了propser，它拿到最先的提案，交給決策者...
其實，這就演變成了paxos的變種協議。

後記

爲了不競爭，加快收斂的速度，有人在算法中加入leader來代替propser，且leader在集羣中只有一位，也就是說只有leader有權提議。這時leader會有單點問題，因而又加入了leader選舉機制保證健壯性，到目前爲止paxos演變的愈來愈像我下一篇要講的zab協議了。

爲了能講得更通俗，不少地方講得不夠嚴謹，見諒，有問題能夠提出交流。

其實這篇和zookeeper的關係不太大算是講zab以前作的一個鋪墊吧。