从魔兽争霸看Paxos算法（二）

Paxos算法需要解决的问题

解决分布式一致性问题。具体来说是：

有一个问题X，假设有一组提案进程，这些进程集合都可以独立提出解决问题X的方案（提案）。这时，需要某种分布式一致性算法保证如下几点：

1、这些针对问题X的提案，只有一个会被选定（得到整个分布式系统的认可）。

2、如果没有针对问题X的提案，那么就不会有被选定的提案。

3、当一个提案被选定后，所有关注问题X的进程都可以获得这个提案。

这个算法在分布式环境中面临这如下挑战：

1、算法的所有参与者都不可靠。（执行速度有快有慢、可能停机和重启）

2、消息传递不可靠。（消息可能出现延迟、重复、丢失）

但是要注意，这个分布式一致性算法不考虑“拜占庭问题”，即假设消息不会被篡改（包括损坏）。

算法中的4个角色

Proposer ：提议者
Acceptor：决策者
Client：产生议题者
Learner：决议学习者

在这四个角色中，Proposer和Acceptor是核心角色。Client是算法的输入，Learner是问题的输出。

Client负责产生各种各样的问题和问题的提案，并将这些交给Proposer；

经过Paxos算法达成一致后，Learner负责接受各个问题及其决议。

回顾上文场景

各个侦察小分队就是Proposer（其实也是Client），来回往返与侦察分队和各大部队之间传递消息的侦察单位就是不可靠的信道。各大部队就是Acceptor。

算法运行过程

正对给定的问题X，Paxos算法分两个阶段得到关于X的决议。这两个阶段Proposer将会向Acceptor发送两种类型的请求。

Prepare请求，主要是Proposer向Acceptor申请批准提案编号

Accept请求，主要是Proposer向Acceptor申请批准提案<,>

第一阶段（Prepare）

1、Proposer选择了一个提案编号，然后向Acceptor集中超过半数的成员发送编号为的Prepare请求。

2、如果Acceptor收到一个Proposer提出的编号为的Prepare请求，

如果大于该Acceptor已批准的所有Prepare请求的编号，Acceptor将批准这个编号，并把自己已批准过的最大编号的提案反馈给这个Proposer。同时这个Acceptor将不再批准任何编号小于的提案。

如果小于该Acceptor已批准的所有Prepare请求的编号，Acceptor将拒绝这个编号。

第二阶段（Accept）

1、如果Proposer收到了半数以上的Acceptor对其发出的编号为的Prepare请求的批准响应，那么这个Proposer将向半数以上的Acceptor节点发送一个编号为，为（即<,>提案）的Accept请求。

注意，如果这个Proposer在以往的Prepare阶段收到过来自Acceptor的包含了已批准提案的Prepare响应，那么这个将是收到的所有提案中编号最大的那个提案的Value部分。

如果没有收到过这样的Prepare响应，那么中这个就可以是新值。

2、如果Acceptor收到了一个<,>的Accept请求，如果这个Acceptor尚未批准比编号更大的编号请求（Prepare请求），这个Acceptor就批准这个提案