Paxos有2种含义，广义上来讲，是指一系列协议的统称，比如cheap Paxos <Cheap Paxos>(2004), fast paxos <Fast Paxos >(2005)，Disk Paxos 和Byzantine Paxos<The ABCD’s of Paxos> (2001)；狭义上来讲，是指Leslie Lamport在其论文<The Part-Time Parliament >(1989)中提出的协议。
那Paxos协议是什么那？可以看到很多文章在介绍Paxos时，都将其介绍为“是一种强一致性协议”，我觉得这么说不够准确。那么Paxos究竟是什么那？我们来看看几篇Paxos经典的论文是如何定义Paxos的。Leslie Lamport在自己另外一篇论文<Paxos Made Simple> （2001）里这么说的：The Paxos algorithm for implementing a fault-tolerant distributed system
has been regarded as difficult to understand, perhaps because the original
presentation was Greek to many readers. 我们的重点在前半句，至于要理解后半句，需要了解Paxos的产生历史，Paxos的历史是计算机历史中最有趣的历史之一，这里就不八卦了，有兴趣的同学可以自行google.
另外一篇论文<Paxos made code>这样描述Paxos：
The PAXOS algorithm for solving consensus is used to implement a fault-tolerant
Atomic Broadcast.
这篇论文中<Paxos Made Live - An Engineering Perspective>这样描述：
We used the Paxos algorithm (“Paxos”) as the base for a framework that implements a fault-tolerant
log.
从这3句描述Paxos的句子中可以发现，都共同提到了一个词：fault-tolerant。Fault-tolerant就是Paxos的核心。通常Paxos被用在数据写入多个副本的场景，Paxos可以保证在容忍少量节点（n/2）挂掉的情况下仍然可以保证数据最终被成功写入所有副本。假设我们不用Paxos，自己来实现副本写入的逻辑，我们同步写所有的副本，当所有副本都返回成功后，再通知用户这条数据写入成功，这种实现可以达到写入多个副本的目的，但是这种方式无法容忍节点挂掉。Paxos的核心就是在容忍节点挂掉的情况下，保证数据最终写入所有副本。所以说Paxos的核心是fault-tolerant，在任何一个Paxos的定义中都没有提到一致性，所以说一致性不是Paxos关注的点。（Paxos是否保证强一致性这里就不讨论了）
从上面的3句话中我们还能看出2个点，第一个点是Paxos解决什么问题：consensus。什么是consensus，有人把它翻译成一致性（也许这就是为什么Paxos被有些人误解为"是一种强一致性协议"的原因吧，错误的翻译了这个词），其实不准确，应该翻译成共识。共识也就是说多个进程在分布式的条件下，针对一个值达成共识。后面会再解释consensus。
第二个点就是Paxos可以用来实现Atomic Broadcast，或者log（也可以说状态机）。后面也会再解释Atomic Broadcast和状态机。
总结一下Paxos是什么：
核心：fault-tolerant
解决的问题：consensus
应用在：Atomic Broadcast和状态机
场景：数据写入多个副本
接下来，说一下Paxos具体是什么？Leslie Lamport的论文中的Paxos协议由2个部分组成，一个是basic Paxos，一个是multi Paxos。协议中定义了4中角色：client, proposer, acceptor, learner 。这里要特别指出的是learner。了解Zookeeper的人都知道，Zookeeper所使用的Zab协议和Paxos类似（有人说Zab是Paxos的变种，个人觉得2者差别很大)。Zookeeper中有3种角色，leader，follower，observer，在Zookeeper中observer角色其实是可用可无，但是在Paxos中learner角色是必须的。个人曾经受上面说法的影响，认为learner类似oberserver的所起的功能，导致很长时间无法正确理解Paxos协议的细节。
Basic Paxos是一种consensus算法。consensus像上面所说的是用来让多个进程针对一个值达成共识的，而且这个共识一旦达成就不可更改。这里我们先不展开说明达成共识是怎样的一个过程。我们这里假设你已经理解了这个过程。这个过程可以单独再写篇文章来分析。这个达成共识过程就是Atomic Broadcast要完成功能。Zab其实就是从这个角度出发，将自己叫作原子广播协议（Zookeeper Atomic Broadcast)。
那么我们针对一个值达成共识有什么用？这就要来说multi Paxos。我们把独立的一个这样达成共识的过程成之为一个实例(instance)。那么我们反复运行这个过程，就可以形成一系列的共识，也就是一系列的实例。那么这个反复运行的过程就是multi Paxos。一系列的实例，就是一系列确定下来的值，这一系列的值可以看做一个日志流，而且是复制到所有节点上的日志流。Raft就是从这个角度出发，这样定义自己"Raft is a consensus algorithm for managing a replicated log"<In Search of an Understandable Consensus Algorithm>。（个人觉得Raft和Paxos的细节差别也很大)。接下来我们就可以基于这个日志实现状态机(state machine）。这个状态机可以用来实现可靠的存储系统，在存储系统中的一个节点写入一个值或者修改一个值，我们将这个变更写入日志，做为日志的一条记录，也就是一个Paxos的一个实例，日志被复制到其他节点，其他节点按照相同的顺序重做日志，那么就会得到和主节点完全相同的状态。从而实现了一个fault-tolerant的存储系统。所以说存储系统引入类似Paxos这样的协议是提高了系统的可靠性。
最后再总结一下Paxos是什么：
核心：fault-tolerant
解决的问题：consensus
应用在：Atomic Broadcast和状态机
场景：数据写入多个副本