paxos是去中心化协议，较难理解。
proposer, accepter是其中的主要角色。前者发起投票，后者批准投票。
核心思想是，一旦超过半数的accepter同意某个投票，整个流程结束，批准的那个结果则是最终结果。
learner是另一个角色，从各accepter获取到最终的值。实际中，这些角色可能是同一个节点。
不同的proposer去争抢一半以上的accepter，直观上会遇到的问题就是死锁。为了解决这个问题，paxos引入轮次的概念来避免死锁。
引入轮次后，需要确保的隐含条件就是：如果其中一轮已经选举出了一个结果，则后续所有轮次不能再推翻此结果，而必须接受此结果。
paxos过程与两阶段提交类似，也分两个阶段。
第一阶段是proposer告诉acceptor，准备提交第n轮，需要保证不接受小于n轮的其他proposer的提案。
第二阶段，则是根据第一阶段acceptor的返回结果，通知acceptor提交某个值。
流程如下：
轮次n：
可见，轮次是个全局的概念，如何保证轮次在整个过程中不同节点轮次不重叠。
只需要定一个保证递增性与唯一性的规则。如： 时间戳 + 提出提案的次数 + 机器 IP/机器ID
活锁：
虽然paxos以轮次概念的引入解决了死锁，但因为存在着prepare、accept两阶段，有可能出现活锁问题：
如proposer A以prepare 1发起一轮paxos过程，所有acceptor返回null，A准备发送accept(1, Va)；
此时proposer B以prepare 2发起又一轮paxos，所有acceptor依然返回null，B准备发送accept(2, Vb)；
这时，proposer A以prepare 3继续发起新一轮prepare。。。，循环往复。
这就是活锁。
活锁可使用随机改变轮次n的增长幅度来解决。