Paxos Made Practical
當一個組中一臺機器提出一個值時，其它成員機器通過PAXOS算法在這個值上達成一致。
Paxos分三個階段。
第一階段：
提出者會選出一個提議編號n（n>0，n的低位應當包括提出者的唯一標識。這樣兩臺機器就不會產生同樣的編號），然後會向組內其它成員發送信息PREPARE（n）。成員假設已經見到過PREPARE信息大於n，就會拒絕它；假設已經見到的PREPARE信息n‘ < n（這個提議n’的值假設為v‘），就會回復信息PREPARE-RESULT(n’, v’)。假設這個成員還沒有見過不論什麽提議。就會回復信息PREPARE-RESULT(0, nil)。假設組內大多數成員（majority）都接受了這個PREPARE（n）信息，就進入PAXOS算法的第二階段。

第二階段：
It sets v to the value in the highest-numbered prepare-result it received. If v is nil, it selects any value it wishes for v.（沒看懂）
接下來提議者會向其它成員廣播消息PROPOSE（n。v）。相同，假設成員已經見過的PREPARE（n‘’）（確定是PREPARE而不是PROPOSE）。n‘’ > n。就會拒絕這個消息；否則，就會接受這個消息，並給提議者一個回復。

假設組內多數（包含提議者自己）都接受了這個PROPOSE消息，提議者會廣播消息DECIDE（n，v），這就表示這個組在提議的值v上已經達成一致了。

第三階段哪裏去了？

以下是PAXOS算法在實際中是怎樣實現的。

先來了解一下什麽是狀態機（state machine）：是一個能接收請求產生回復的可確定性服務（deterministic service），可確定性服務意思是假設兩個狀態機擁有同樣的初始狀態。那麽當它們接收到同樣序列的請求時會產生同樣的回復。

首先。我們要清楚一個復制系統（replication system），如Columbia University的M-SMR。會提供兩套庫，服務器端（server-side）庫和client（client-side）庫。前者負責狀態機的實現，後者是讓client發送請求給狀態機然後得到回復。

讓我們詳細看看服務器端（server-side）庫提供的三個函數：

這裏說一下run函數的第三個參數
buf execute (buf request);
這是狀態機裏一個非常重要的組成函數。它負責將請求帶給狀態機並返回回復。
之前我們說過client庫負責用戶請求的提交和得到回復（這怎麽和server端函數run的參數execute函數的功能一致呢？），假如這時有多個用戶請求同一時候到來。client庫就須要對這些請求達成一個統一的運行順序讓組內成員去運行，來保證一致性。這裏就涉及與組內成員的通信問題。client庫是怎樣來聯系組內各個成員的？也許是RPC。
不幸的是並非全部的RPCserver都是確定性的（deterministic）。舉個樣例，一個文件server會在一個文件發生寫操作後將改動時間記錄在文件的inode中。這樣即使兩個成員機器運行同樣的文件server程序並運行同樣的寫請求，可是它們在運行寫操作的時間卻無法保證同樣，比方都是2014／11／14 23：06。

這樣就會在成員之間出現分歧狀態。為什麽你記錄的改動時間比我早十分鐘？解決方法是讓一個機器記錄下自己的改動時間，然後廣播給大家。告訴大家都來記錄這個時間。

事實上這裏改動時間就是一個不確定性值（non-deterministic value）。還是那個問題client庫是通過什麽手段來聯系組內各個成員的？
看來這個問題是無法解答了。解析來切入正題： Normal-case operation

Normal-case Operation
在一個組裏，有一個primary。其它的稱作backups，這裏有一個術語：view，表示一個擁有primary機器的處於活動狀態的機器集合。每個view會有一個view-id來唯一標識，並且view-id是單調遞增的，隨著每一次view的改變。

上圖展示了在正常情況（沒有機器增加，沒有機器故障）下信息的流動。

這裏再引入一個術語：viewstamp，由view-id和timestamp結合而來，primary會給每個到來的請求一個timestamp。這個timestamp就指明了請求被運行的順序。

相同加強版的viewstamp也表示請求的運行順序。

理解Paxos Made Practical