一、背景
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 算法就是为了解决这个问题而生的。