multipaxos协议
不知道有没有人和一样，看完paxos协议之后，再看zab协议，感觉两个实际上并木有什么关系。如果有，那是因为你漏掉了multi paxos协议，它实际上才是能真正将paxos协议用于生产中的。
先说活锁，如果有n个proposer，他们要发起提案就难免这样的场景。acceptor先应答prepare proposer的1版本，当proposer美滋滋发起accept的时候，acceptor告诉它。抱歉，我又prepare了别的proposer的3版本。卧槽，我裤子都脱了，你又答应别人了，不行，不争馒头还要争口气，那我把我的版本号加高，这样，就进入了一个恶性循环中去，大家都在拼命地加高版本号，就像。。。今年双十一淘宝的盖楼活动一样。所以，这样的paxos协议是没法用于生产的。
当然，我们的Lamport大佬不会整这么一个没用的东西。其实问题很好解决，只有一个proposer就行了，其它的在旁边看着。这个就是multi paxos算法了。那么接下来的问题就是，谁来当这个唯一的proposer，也就是leader。
multi-paxos并没有一个显式的选主的过程，其实只是在basic paxos过程中稍加改动而已，分为以下阶段：
一、proposer进行prepare，获得半数以上支持的，就自认为leader
二、这个阶段，会有多个自以为是的leader，但是真leader只能有一个。所以所有的伪leader要进行accept操作，那么在这个过程中，实际上只有版本号最大的proposer才能accept成功，这个才是真正的leader。当然这个阶段也会产生活锁，无可避免。
三、accept阶段写入的便是根据ProposalID生成的日志（称为StartWorking日志），
完成此阶段以后，leader已经产生，从这之后，它直接accept即可，因为他的leader 身份已经得到了多数派的支持。而其他的acceptor也要做好自己应该做的事情，既拒绝除leader意外的accept请求。而其他proposer收到来自instance的提案，交给leader即可。
以上，便是multi-paxos的基本情况，有效避免了活锁问题，提高效率。
以上是 multipaxos协议 的全部内容， 来源链接： utcz.com/z/510729.html
