paxos出身
paxos出身名門，它爹是沒多久前獲得圖靈獎的在分布式領域大名鼎鼎的leslie
lamport。
paxos為何而生
那麼lamport
他老人家為什麼要搞這個東東呢
，不是吃飽了撐的，而是為了解決分布式系統的大難題。分布式系統一
般要求具有高可用性，高可用性一般又是通過冗餘也就是多副本來解決，多副本接著又帶來了一致性問題，所以分布
式系統要解決的問題可簡單歸結為多副本的一致性問題。怎麼解決一致性問題呢？搶答：用事務。何為事務？搶答：
多個操作序列的原子性。何為原子性？搶答：還需要
您自己去多看書吧。實現事務的方案有兩階段提交協議，和在這
個基礎上進行了增強的三階段提交協議。 這兩個方案都涉及到兩個角色，即協調者(coordinator)和參與者(cohort)，協
調者要保證操作序列的原子性來實現事務，但它們都存在一些 問題，因此一些著名的系統如google的chubby和yahoo
的apache zookeeper都使用了paxos演算法。
兩階段提交協議的訊息流程：
coordinator cohort兩階段提交協議包含投票(vote)和提交(commit)兩個階段，它是乙個阻塞的協議，如果參與者給協調者傳送yes訊息後協調者query to commit
-------------------------------->
vote yes/no prepare*/abort*
commit*/abort* commit/rollback
-------------------------------->
acknowledgment commit*/abort*
end
永久性地掛了，那麼參與者將陷入無限等待中，並且會帶來資料不一致的問題。
三階段提交協議的訊息流程：
三階段提交協議在二階段提交協議的基礎上增加了準備提交(prepared to commit)階段，解決了協調者掛掉後參與者
無限阻塞和資料可能不一致的問題，但仍然無法解決網路分割槽的問題。
相對於上面兩個協議，由於多數派的特性，paxos可以在節點失效、網路分割槽、網路延遲等各種異常情況下保證所有
節點都處於同一狀態，它的結構圖大致如下：
basic paxos architecure. a picutre from:paxos-by-example
乙個典型的paxos應用場景
分布式系統中有多個節點，一般每個節點都是參與者，而其中乙個節點既是參與者又是協調者。但是這樣還會有單點
故障的問題，即如果協調者節點掛了，那麼將無法進行任何事務，系統也就停止了正常運轉。
如何在還存活的其它節
點中選擇乙個來擔當協調者的角色，使系統可以照常執行，達到山不轉水轉的目標呢？真的好難，但是有了paxos算
法，我們可以解決這個難題。
如果還覺得這個問題抽象，那麼可以換一種表述方式，即：如何在分布式系統中確定某
乙個變數的值。在這個具體的場景中，這個變數的值指定了哪個節點將被選出來擔當新協調者的角色。
paxos角色和規則
從上面的結構圖中，我們看到paxos主要涉及三個角色，分別為acceptor、proposer和learner，在實踐中，往往每個節
點都具備這三個角色，這裡為了讓我們大腦少些迷糊，暫且以每個節點只具備一種角色來討論。
paxos演算法主要分為兩個階段：
1. prepare:
proposer
該acceptor
已經接受的值和對應的提案號。如果proposer獲得超過半數acceptor的訪問權，那麼會進入第二階段；
2. accept:
1) 如果所有的acceptor返回值都為空，則proposer將攜帶自己預設的值v和自己的epoch號向獲取到訪問權的acceptor傳送請求;
2)如果proposer第一階段獲得某些acceptor的返回值不為空，則將epoch號最大的提案號對應的值f作為自己的預設值，和自己的
提案號一起向acceptor傳送請求(如果第一階段返回f的acceptor已經超過了半數，則表示已經形成確定性取值，此時直接返回成
功，不需要進行accept請求了)；
對於acceptor來說，當它接收到proposer請求時，需要應用一系列規則來決定如何響應，我們對這些規則可以進行如下概括：
1)喜新厭舊
當acceptor接收到prepare請求時，它將當前自己發放了訪問權的epoch號和該prepare請求攜帶的epoch進行比較，如果前者小
於後者，則將訪問權賦予新請求的這個proposer，否則拒絕發放訪問權。這裡我們認為epoch值越大的越新。
2)一視同仁
當acceptor接收到accept請求時，它
將當前自己發放了訪問權的epoch號和該prepare請求攜帶的epoch進行比較，如果前者大於
後者，則拒絕該請求。如果這兩個epoch號相等，
並且acceptor當前接受的取值為空，則接受該acceptor請求，同時將該accept
請求的值設定為接受值。如果之後又更大的epoch號申請
到訪問權，並發出accept請求，該值也不會改變，即acceptor在確定了
值之後不再改變，誰先設定就用誰的值。雖然在發放訪問權時是喜新厭舊，但
在取值這個問題上一視同仁，不會因為新epoch號
大而改變取值。這就像某些人，其他女人可以訪問他，但老婆只要定了就不會變。
paxos正確性
假設有n個acceptor，多數派個數至少為n/2+1。如果有乙個以上的proposer獲取到超過半數acceptor的訪問權，那麼至少有乙個
acceptor是相同的。具體來說，假設proposer a在prepare階段獲取到j個acceptor的訪問權，proposer
b在prepare階段獲取到k個acceptor的訪問權，j>=n/2+1，k>=n/2+1，那麼必然有這樣乙個acceptor
c，c既屬於j又屬於k，這種情況就是在c給某個proposer發放訪問權後，接著被另乙個proposer搶占到了訪問權時發生。
我們假設proposer a的取值為v1，proposer b的取值為v2。在accept階段，對於acceptor
c來說，它根據訪問權來決定接受誰的accept請求，如果當前是b獲得了訪問權，則接受b的取值v2，這樣a在accept階段將失敗，失敗之後它可能
會繼續生成新的epoch值重新進入prepare階段，但是這回它拿到了返回值v2，這樣它之後進入accept階段時，會將v2作為它的取值向
acceptor傳送申請，最終proposer a和proposer b都達成了一致，即v2為最終取值。
以上是本人目前對paxos演算法的一點理解，還將繼續深入和不斷糾正.......
感覺不錯的資料，推薦參考：
paxos演算法之粗淺理解
理解Paxos演算法的推導過程
paxos作為分布式系統的基石，一直都是cs領域的熱門話題，paxos號稱是最難理解的演算法。最近幾天一直在看paxos相關資料，發現paxos演算法執行過程很簡單，但如何推導出paxos演算法確實令人費解。網上有大量關於paxos的基本概念 演算法描述 推導過程等文章，所以關於paxos的基本概念...
XML XML粗淺理解
xml 作為乙個應用比較廣泛的標記語言，xml是乙個龐大的家族。絕大多數的xml檔案都是從宣告開始的。xml的宣告由版本號和字元編碼方案組成 xml在檔案結構上採用單根樹狀結構。所有的屬性都是從根開始，逐步擴充套件到葉子。在xml中，所有的內容必須在乙個單一元素的子集中，這個單一元素被稱為根元素。需...
深入淺出理解Paxos演算法
paxos演算法是萊斯利 蘭伯特 英語 leslie lamport latex中的 la 於1990年提出的一種基於訊息傳遞且具有高度容錯特性的一致性演算法。paxos演算法一開始非常難以理解，但是一旦理解其實也並不難，之所以難理解其實是因為作者講的故事難理解。paxos演算法維基百科 本人是在看...