paxos之Multi-Paxos

paxos之Multi-Paxos

朴素Paxos算法的Latency很高，Multi-Paxos通过改变Promised的生效范围至全局的Instance（收到来自其他节点的Accept，则进行一段时间的拒绝提交请求），从而使得一些唯一节点的连续提交获得去Prepare的效果。这将原来2-Phase过程简化为了1-Phase，从而加快了提交速度。

basic paxos是由client发起的同步过程，在两阶段返回前，client不能得到成功的返回。

• 第一阶段a（发送prepare），proposer向acceptor提出一个协议，这里的协议可以理解为client发送过来期望多节点一起保存的一致性内容，举例：一句日志，某个配置等
• 第一阶段b（计算协议vn），根据半数以上acceptor的返回，选择 max{va,vb,vc} = vn，这里的vx理解为这个acceptor已知的最大协议号，acceptor一旦返回了vx后，则表明：
  • acceptor在接下来的prepare请求中，会返回的vx自增1
  • acceptor不会accept任何小于vx的协议请求，只会accept大于vx的协议请求
• 第二阶段a（发送决议好的vn），把vn发送给acceptor
• 第二阶段b，在半数acceptor返回了成功后，再返回client成功通过协议

Multi Paxos一边先运行一次完整的paxos算法选举出leader，有leader处理所有的读写请求，然后省略掉prepare过程.

Multi Paxos要求在各个Proposer中有唯一的Leader，并由这个Leader唯一地提交value给各Acceptor进行表决，在系统中仅有一个Leader进行value提交的情况下，Prepare的过程就可以被跳过：

  如上图：

1. 流程图中没有了basic paxos的两阶段，变成了一个一阶段的递交协议：

• 一阶段a：发起者（leader）直接告诉Acceptor，准备递交协议号为I+1的协议
• 一阶段b：收到了大部分acceptor的回复后（图中是全部），acceptor就直接回复client协议成功写入
• wiki中写的Accept方法，我更愿意把它当做prepare，因为如果没有半数返回，该协议在超时后会返回失败，这种情况下，I+1这个协议号并没有通过，在下个请求是仍是使用I+1这个协议号