【课程报告五】精度Paxos Made Simple（4）

        文章2.5简要地描述Paxos的实现：将进程分为proposer, acceptor,learner三种角色，并选出leader担任杰出的proposer和learner。任何提案都由数字标记且只有最高编号的提案才会被接受。

看了好多文章都在说的Multi-Paxos，大致是这种模式的Paxos了。

        文章的第三大节中，作者提出在分布式系统中多个并发的Paxos进程如何实现状态机。多次的Paxos的值按照相同的顺序进入系统，则所有节点同步的状态必然相同。但是多个客户端向系统发送请求，而处理请求又是由多个服务器组合分布式系统，想要每个客户端由Paxos返回的值都按固定的顺序同步不是件容易的事。

        文章提出假设:

        （1）假设系统将处理1-142号来自客户端的请求（文章其实是无限的命令编号，后面只提到141、142，为方便叙述直接选定1-142）

        （2）1-134、138和139通过Paxos且获取了对应的值，135-137、139后的因为各种原因才进入了Paxos第一阶段，由于顺序记录的原因，系统只能同步1-134的状态

        （3）之后135和140完成了Paxos且获取了对应的值，但现在仍只能同步1-135的状态，138-140不能同步，因为136、137并未完成Paxos

        （4）136、137由于还未确定值，所以可以填入特殊的不改变状态的no-op命令，从而使138-140可以同步

        （5）完成Paxos一阶段的141在二阶段值被指定接收142号命令的算法实例，则142号命令作为下一条命令被接收，142号之后命令则以此类推

        一般来说，假设一个领导者可以提前α项命令——也就是说，在第1至i项命令被选定后，它可以提案第i+1至i+α项命令——可能产生最多α−1条命令的空隙。

        在leader为无限多的命令回复一阶段的请求的要求下，服务器（作为接受者）也可以用一条比较短的消息响应所有实例。在上面的场景中，包括实例 135-137 和所有 139 之后的实例。对所有实例使用相同的提案编号，它可以通过向其它服务器发送一条比较短的消息完成这一阶段。对第一阶段，只有已经收到来自某个提案者第二阶段消息的情况下，接受者才会完整地响应消息，否则只简单地回复的OK即可（上面的场景中，只有实例 135 和 140 需要完整响应）。

        failure of the current leader （leader失败）、the election of a new one（new leader 选举）的事件发生概率很小，且Paxos二阶段成本很低，因此，Paxos算法本质上是最优的。