直接舉例：
以我們常用的火車票訂購系統爲例，每當過年的時候，全國有多少人搶票這裏不做統計，但是一個購票系統服務器是絕對無法滿足需求的，大量的訪問和請求會直接導致服務器宕機。
所以爲了滿足這種需求，鐵路局決定採用分佈式集羣的方式解決大量用戶同時訪問的問題。這樣購票系統被同時部署在多個服務器上，通過負載均衡的方式來響應客戶端的購票請求。我們這裏假定有5個分佈式服務器，流程如下：
這樣的話就不用擔心服務器不夠用了，如果用戶量持續增加，我們也可以隨時擴充服務器數量，通過負載均衡，保證多個服務器之間工作量均衡。負載均衡雖然解決了大量訪問的問題，但同時引發了一個更加亟待解決的問題，那就是分佈式下的數據一致性。
如果只有一臺服務器，所有對數據操作都是在同一臺服務器上，數據肯定是一致的。
現在沒一臺服務器都有相同的數據拷貝，怎麼保證數據的一致性？
Paxos算法解決了這一問題，舉例如下：
繼續上面的流程圖，A、B、C、D、E服務器分別存儲着當前車票信息，包括車票車票買入情況等，假定這時候每臺服務器記錄着從北京到鄭州的火車票數量爲1，無論哪個客戶從哪太服務器購買了從北京到鄭州的車票，其他的服務器必須能同時更新車票信息，確保不會出現多個人買同一個座位票的情況。
我們假定客戶1、客戶2同時購買從北京到鄭州的車票，但是由於計算機性能或者網絡原因，客戶1的請求率先通過負載均衡器的分配到達服務器A，服務器A接收到請求，得知客戶1想購買一張從北京到鄭州的車票，然後檢查自己的車票信息，數量爲1，確認自己可以滿足購買要求，但是這時候還不能確定服務器B、C、D、E的情況，萬一有人捷足先登從B、C、D、E購買了票，自己這邊再賣出去豈不是出問題，所以需要確認一下其他服務器的情況。服務器A向B、C、D、E發出確認請求，B、C、D、E只要有2個答覆說可以購買，就算超過半數達成了一致，服務器A接收到確認，然後會再發一條指令告訴B、C、D、E，“我從我庫裏減少一張票，當前爲0”，B、C、D、E接到指令，只要有2個給出答覆“我已經減少了一張票，當前爲0”，到此，就達成了一致。服務器A告訴客戶A，你買票成功了，這張票已經到了你的賬號裏。
如果在服務器A處理客戶1請求的時候，這時候服務器E接到了客戶2的請求，這時候服務器E的狀態存在以下幾種可能：
1、服務器E由於網絡原因沒有收到任何確認消息，包括服務器A的消息。這時候服務器E會重新發送確認消息給A、C、D、E，第一輪先確認購票前的數據一致性，第二輪確認購票後的數據一致性。如果任何一個環節不能確認數據一致，服務器E就不能處理客戶B的請求。比如在確認過程中有超過半數的服務器告訴E，“我們的餘票是0”，服務器E將告訴客戶2沒票了，同時將自己的餘票改爲0。
2、服務器E已經接收服務器A的第一輪諮詢，服務器E也已經告訴服務器A，自己餘票是1,可以購買。但是這時候服務器E還不能確認服務區A有沒有賣票成功，所以服務器E同樣可以賣票，這時候同樣需要兩輪的確認。
3、服務器E已經接收服務器A的第二輪確認，並且同意且餘票狀態已經修改爲0，這時候會反饋給客戶2已經沒票了。
有了以上的業務需求場景，我們再回過頭理解一下Paxos算法中的角色和概念：
1、Proposal Value： 提議的值
2、Proposal Number： 提議編號，要求提議編號不能衝突
3、Proposal： 提議 = 提議的值 + 提議編號
4、Proposer： 提議發起者
5、Acceptor： 提議接受者
6、Learner： 提議學習者
這裏面服務器充當Paxos算法中的所有角色，服務器A根據客戶端請求發起提議，服務器A爲提議發起者。BCDE接收提議，爲接收者。