paxos

Proposer带ProposalID发起prepare请求    promise.     只接受ProposalID> 的prepare消息 和ProposalID>=的Propose

Proposer收到多数promise中选ProposalID发起propose   Acceptor accept。 

Proposer收到多数accept形成决议发给learner

 

这里注意有2个步骤，acceptor在处理prepare消息和proposal消息时的规则容易混淆：

在处理prepare消息的时候acceptor的规则是这样：

1.向proposer承诺，保证不再批准任何编号小于Mn的提案

2.如果Acceptor已经批准过任何提案，那么其就向proposer反馈当前该acceptor已经批准的编号小于Mn但为最大编号的那个提案的值。

然后，Acceptor可以在任何时候响应一个prepare请求。

 

 

我是这么理解的，超过半数的accept成功即可断定，当前被accept的提案在accept的那一刻是最新的，且已被更新成功，因为如果不是最新的 任意一个大于半数的集合都不会一致accept这个提案，至少有一个promise最新提案的acceptor拒绝并返回最新提案，导致新一轮的prepare发起

 

然后是propose请求的规则：

在不违背我们之前在prepare请求中做的承诺的前提下，可以任意响应Accept请求。

跟进一步的我们可以说：

一个Acceptor只要尚未响应过任何编号大于Mn的Prepare请求，那么它就可以接受这个编号为Mn的提案。

所以会出现Acceptor不响应某些proposal的。

 

再来看一下我们为什么要p1,p2,p2a,p2b,p2c,p1a?这样做到底是为了什么，不忘初心：

一个一致性算法需要保证以下几点：

1.这些被提出的提案中，只有一个会被选定

2.如果没有提案被提出，那么就不会有被选定的提案。

3.当一个提案被选定后，进程应该可以获取被选定的提案信息。

对于一致性来说，安全性需求如下：

1.只有被提出的提案才能被选定。

2.只能有一个值被选定

3.如果某个进程认为某个被选定了，那么这个提案必须是真的被选定的那个。