Paxos算法解析

看了几天的paxos算法，终于有了一点点理解，记录下来。

Paxos的两个组件

Proposer

提议发起者，处理客户端请求，将客户端的请求发送到集群中，以便决定这个值是否可以被批准。

Acceptor

提议批准者，负责处理接收到的提议，他们的回复就是一次投票。会存储一些状态来决定是否接收一个值

有以下原则

1 一个Acceptor必须接受它收到的第一个提案

2 一个提案被选定需要被半数以上的Acceptor接受

3 如果某个value为v的提案被选定了，那么每个编号更高的被选定提案的value必须也是v

一个提案被选定要经过第一阶段（prepare），如果一半Acceptor同意提案，Proposer才能第二阶段(Accept)。如果一半Acceptor同意提案，提案才能被选定。

第一阶段（prepare）

1)提议者获取一个提案号（proposal number）n;
2)提议者向所有节点广播prepare(n)请求；
3)接收者接收消息此时要分几种情况处理
   a.如果接收者还没有收到任何提议，记录minProposal.并返回提议者OK,认可该提案。
   b.如果接收者已有minProposal,比较n,和minProposal,如果n>minPno,表示有更新的提案,更新minProposal=n。
   c.如果此时已经有一个认定值（accptedValue），返回提议者已确定的(acceptedProposal,acceptedValue).
   d.如果接收者已有minProposal,比较n,和minProposal,如果n<minProposal.拒绝并且返回minProposal。
4)提议者根据请求返回的响应做处理。只有收到超过一半接收者响应才能发起第二阶段请求。同样也分为以下几种情况
   a.超过一半接收者返回已确定的提案(acceptedProposal,acceptedValue)，表示有认可的提议，保存最高acceptedProposal编号的acceptedValue到本地
   b.超过一半接收者同意提议者的提案。
   c.未得到一半接收者同意提案，这种请求跳转1，对n进行累加，重新prepare。
   
   
   
第二阶段（Accept）
5）提议者广播accept(n,value)到所有提议者节点；
6) 接收者比较n和minProposal，如果n>=minProposal,则acceptedProposal=minProposal=n，acceptedValue=value，本地持久化后，返回；
   否则，拒绝并且返回minProposal。
7) 提议者接收到过半数请求后，如果发现有返回值>n，表示有更新的提议，跳转1（重新发起提议）；否则value达成一致，提案被选定

以下通过实例说明

假设P1,P2  Proposer，A1,A2,A3 Acceptor

 

场景1

  P1发送提议【1，a】至A1,A2 , A1,A2因为此时是第一个提议，所以接收提议，返回OK

  因为P1收到一半Acceptor的响应，所以发送第二阶段请求

A1,A2 比较本地的minProposal 发现n=minProposal 选定【1，a】并返回给P1,P1发现有一半接受者同意提案，选定【1，a】

 

P2发送提案【2，b】给A1,A2 因为此时有选定值【1，a】,返回【1,a】，P2发现有一半接收者返回选定值，更新本地提案

场景2

  P1发送提议【1，a】至A1,A2 , A1,A2因为此时是第一个提议，所以接收提议，返回OK

P2发送提议【2，b】至A1,A2 , 因为【2，b】大， A1,A2更新本地minProposal 返回OK

因为一半接收者同意P1的提案，所以发送accept请求【1，a】,A1,A2比较本地minProposal 发现本地minProposal为【2，b】

所以拒绝提案，并返回【2.,b】给P1,表示有更新提案。P1更新提案【3，a】继续第一阶段prepare请求后，

如果此时P2在进行accept请求【2，b】发现又有更新请求，如此反复就会出现活锁的情况，解决的方法就是提出主Proposer。

参考文章

https://www.cnblogs.com/linbingdong/p/6253479.html

https://blog.csdn.net/cnh294141800/article/details/53768464/