Paxos算法
Paxos主要解决在一个可能发生异常的分布式系统中快速明确的在集群内部对某个数据达成一致，并且保证不论系统发生什么异常，都不会破坏整个系统的一致性。
在该一致性算法中，主要有Proposer、Acceptor和Learner三种角色。在具体的实现中，一个进程可能充当多个角色。Paxos算法的目标是保证最终有一个提案被选定，当提案被选定后，最终进程也能获取到被选定提案。Proposer负责生成提案，Acceptor负责批准提案，Learner负责学习提案。
Proposer对于每一个产生的[Mn,Vn]的提案，需要满足一下条件：存在一个超过半数的的Acceptor组成的集合S：
- 要么集合S中没有Acceptor批准过编号比Mn小的提案
- 要么集合S中所有Acceptor批准过的所有编号比Mn小的提案中，编号最大的那个提案的值为Vn。
Paxos算法主要分为两个步骤：Proposer生成提案和Acceptor批准提案
阶段一：Proposer生成提案
Proposer在发送编号为Mn的Prepare请求时，要求Acceptor作出以下保证：
- 向Proposer保证不再批准任何编号小于Mn的提案
- 如果Acceptor已经批准过提案，那么就向Proposer返回当前Acceptor已经批准过得编号最大且小于Mn的提案的值。
- Proposer选择一个提案编号为Mn，然后向大多数的Acceptor发送编号为Mn的Prepare请求
- 如果一个Acceptor收到一个编号为Mn的Prepare请求，且编号Mn大于该Acceptor已经响应的Prepare请求的编号，那么Acceptor就会将它已经批准过的最大编号提案 响应给Proposer，同时向Proposer承诺不再批准任何编号小于Mn的提案。
阶段二：Acceptor批准提案
- 如果Proposer收到超过半数的Acceptor的响应，那么就会发送一个[Mn, Vn]提案的accept请求给Acceptor，Vn的值就是阶段一种收到的响应中编号最大的提案的值， 如果响应中不包含任何提案，那么它就是任意值
- 如果Acceptor收到[Mn, Vn]的accept请求，只要该Acceptor尚未对编号大于Mn的Prepare请求作出响应，它就可以通过这个提案。
上述方案在极端情况下会产生问题，举个例子如下：
Proposer1发起了编号为M0的Prepare请求并得到了正确的反馈，但此时还没有进入阶段二(也就是说Acceptor还没有批准该提案)，假设此时另一个Proposer2发起了编号为M1的Prepare请求，Acceptor向Proposer2保证不再批准任何编号小于M1的提案。此时假设Proposer1的MO提案进入第二阶段，此时由于Acceptor已经不允许批准比M1编号小的提案，因此批准M0失败。然后Proposer1又发起M2的Prepare请求，Acceptor保证不再批准比M2编号小的提案，这就导致M1的提案也无法批准通过。最终提案一致在循环生成，却无法被批准。
为了解决上述问题，就必选选择一个主Proposer，并规定只有主Proposer可以生成提案，这样就避免了多个Proposer同时生成提案的问题。
上面主要讲述了如何选定提案，那么Learner如何获取选定的提案呢？主要有以下几种方案：
方案一
Acceptor一批准提案就将该提案发送给Learner，这种虽然能够让Learner尽快的获取提案，但是这种方法需要让Learner和其他的Acceptor进行通信以确保该提案是被大部分Acceptor批准的提案，通信的次数至少是Learner数量和Acceptor数量的乘积
方案二
Acceptor批准提案后向一个主Learner发送该提案，然后由该主Learner通知其他的Learner，这种方案的优点是减少了与Acceptor的通信次数，但同时也引入了主Learner的单点故障问题
方案三
为了解决主Learner的单点故障问题，这里讲主Learner替换为一个Learner的子集。Acceptor将批准的提案发送给Learner的子集，然后由这个子集发送给其他的Learner。子集中的Learner越多，系统越可靠，但通信也会越复杂。
Paxos主要有以下两个实现：
- Chubby：Google的向松耦合分布式系统的锁服务，通常用于为一个由大量小型计算机构成的松耦合分布式系统提供高可用的锁服务。GFS和BigTable等大型系统使用它来解决 分布式协作、元数据存储和Master选举等一系列与分布式锁服务相关的问题。
- Hypertable：使用C++开发的开源、高性能和可伸缩的海量分布式数据库，采用和HBase非常相似的分布式模型。