算法包含proposer(提案者)、acceptor(决议者)、leaner(学习者)三种角色，分成两个阶段：prepare阶段和accept阶段。
acceptor维持3个数据，maxN、acceptN、acceptV，maxN为接收到的prepare请求中最大的编号，acceptN为accept的编号，acceptV为accept的值。
1.prepare阶段
- 对于proposer，当proposer想要提出方案V1，首先发起prepare请求到过半数的acceptor，请求内容为<SN1>，是一个唯一且递增的序号。
- 对于acceptor，当接收到proposer的prepare请求<SN1>时：
- 如果没有收到过任何prepare请求，回复<OK>；
- 如果maxN>SN1，则不回复；
- 如果maxN<=SN1，设置maxN=SN1，检查是否accept过某个提案(acceptN、acceptV是否为null)，如果有的话，回复<acceptN，acceptV>，否则回复<OK>；
2.accept阶段
该阶段可以分为两个子阶段，分别为发起accept请求阶段(2.1)和确认accept阶段(2.2)。
2.1:发起accept请求阶段
-
对于proposer，在prepare阶段会收到acceptor的回复：
- 如果收到过半数acceptor的回复，且回复都是<OK>，则proposer发起accept请求给过半数的acceptor，请求内容为<SN1,V1>，V1为自己设定的值；
- 如果收到过半数acceptor的回复，且回复中包含<SN2,V2>、<SN3,V3>、...，则选出编号最大的，假设为<SNx,Vx>，则发起accept请求给过半数的acceptor，请求内容为<SN1,Vx>；
- 如果收到的回复数量没超过全部acceptor的半数，则增加序号为SN1+1，转到prepare阶段重新开始。
-
对于acceptor，在prepare阶段收到proposer的accept请求：
-
如果SN<maxN，则不回复；
-
如果SN>=maxN，接受该提案，假设proposer的accept请求为请求内容为<SN1,Vx>，则设置acceptN＝SN1，acceptV=Vx，并回复proposer接受此提案；
2.2:确认accept阶段
- 对于proposer，在发出accept请求后会收到acceptor的回复：
- 如果收到过半数acceptor的回复，则确认V1被接受，提案就被确定不会更改了；
- 如果没收到过半数acceptor的回复，则增加序号为SN1+1，转到prepare阶段重新开始；
下面简单证明下该算法如何保证最终决议值的一致性：
- 注意：只有proposer在accept阶段收到过半数acceptor的回复，那么其提出的提案值才算作最终的决议值，某个acceptor在某一时刻accept的提案值不一定是最终的决议值；
- 假设算法在运行过程中第一个收到过半数acceptor的accept请求的为proposer1，其提案编号为SN1，提案值为V1，那么说明过半数的acceptor的acceptN＝SN1，acceptV=V1，那么对于后续的第一个proposer，假设为proposer2，那么其请求编号为SN1+1：
- 如果proposer2完成了prepare阶段正要进入accept阶段，那么他收到的过半数acceptor请求的回复中，回复内容里的acceptN最大的肯定为SN1，(因为目前只有proposer2的请求编号比SN1大，但是acceptor还没accept过proposer2的任何提案，所以acceptor的acceptN还没有被proposer2的accept请求所覆盖，所以最大只能为SN1)，又因为过半数acceptor的acceptN＝SN1，acceptV=V1，根据算法，那么proposer2发起accept请求的提案值一定为V1，所以如果proposer2在发起accept请求后收到过半数acceptor的回复完成了accept阶段，那么最终的提案值还是V1，而不可能变为其他值。
- 对于接下来请求编号为SN1+2的proposer，最终在accept阶段发起accept请求之前拿到acceptor的回复中请求编号最大的是SN1+1(如果SN1+1编号的proposer也完成了accept阶段)，提案值为V1，所以最终提案值没有被更改，后面编号为SN1+3、SN1+4、...的proposer以此类推。
网友评论