一、背景
Paxos由Lamport于1998年在《The Part-Time Parliament》論文中首次公開，最初的描述使用希臘的一個小島Paxos作為比喻，描述了Paxos小島中通過決議的流程，并以此命名這個算法，但是這個描述了解起來比較有挑戰性。後來在2001年，Lamport覺得同行不能了解他的幽默感，于是重新發表了樸實的算法描述版本《Paxos MadeSimple》。
自Paxos問世以來就持續壟斷了分布式一緻性算法，Paxos這個名詞幾乎等同于分布式一緻性。Google的很多大型分布式系統都采用了Paxos算法來解決分布式一緻性問題，如Chubby、Megastore以及Spanner等。開源的ZooKeeper，以及MySQL 5.7推出的用來取代傳統的主從複制的MySQL Group Replication等紛紛采用Paxos算法解決分布式一緻性問題。然而，Paxos的最大特點就是難，不僅難以了解，更難以實作。
二、Paxos解決了什麼問題
答：解決了分布式系統一緻性問題。
分布式系統采用多副本進行存儲資料 , 如果對多個副本執行序列不控制, 那多個副本執行更新操作,由于網絡延遲，逾時等故障導緻各個副本的資料不一緻。
我們希望每個副本的執行序列是 [ op1 op2 op3 .... opn ] 不變的, 相同的。
Paxos 以此來确定不可變變量 opi的取值 , 每次确定完Opi之後,各個副本執行opi操作,以此類推。
結論： Paxos算法需要解決的問題就是如何在一個可能發生上述異常的分布式系統中，快速且正确地在叢集内部對某個資料的值達成一緻.
注：這裡某個資料的值并不隻是狹義上的某個數，它可以是一條日志，也可以是一條指令（command）。。。根據應用場景不同，某個資料的值有不同的含義。
我們假設一種情況，在一個叢集環境中，要求所有機器上的狀态是一緻的，其中有2台機器想修改某個狀态，機器A 想把狀态改為 A，機器 B 想把狀态改為 B，那麼到底聽誰的呢？有的同學會想到，可以像 2PC，3PC 一樣引入一個協調者，誰先到，聽誰的
但是如果，協調者當機了呢？是以需要對協調者也做備份，也要做叢集。這時候，問題來了，這麼多協調者，聽誰的呢？
但是如果，協調者當機了呢？是以需要對協調者也做備份，也要做叢集。這時候，問題來了，這麼多協調者，聽誰的呢？
Paxos 算法就是為了解決這個問題而生的。