细读经典第一期——从Paxos到Zookeeper 分布式一致性原理与实践（2）-CSDN博客

本文链接：https://blog.csdn.net/u014783007/article/details/120112974

本文详细解读了Paxos协议的2.2节，介绍了Proposer、Acceptor和Learner的角色，关键定理P1-P2b的推导，以及算法的两阶段流程。重点讲解了如何解决提案顺序问题和Learner的角色。

摘要由CSDN通过智能技术生成

第二章：

2.2 PAXOS

算法可以讲简单，也可以讲复杂，更可以讲专业，我希望你能用专业的话讲简单的事情，所以名词是需要记住的，因为抽象类才是你应该做的事情，PAXOS就是一个新手很容易糊弄的不专业的算法。这里我加入了一些个人的东西，毕竟直接看书是一头雾水的

2.2.1基本定理的引出和推导

我略过了书中算法诞生过程的部分，直接进入正题，算法包含几个角色：

Proposer ：提议者 Acceptor：决策者 Learner：最终决策学习者

提案的编号M，提案的内容V，M是递增且唯一的

对于以上模型有几个必须阐明的类似定理的场景：

你可能会迷惑于上面的字母，不要急，我们先往下走，记住一个前提，我们要达到的是所有Acceptor对于提案内容的一致性状态，这是我们的目标

对P1很容易想到的一点是，如果多个Proposer持有不同的提案内容V，那么多个Acceptor的状态会产生不一致，这里会引申出一个问题，就是如果提案没有编号M（代表提案顺序），只有提案内容V，那么当V被Acceptor接受，提案V就固定了，你没法辨别提案的顺序，对Acceptor而言，成了无视顺序的盲人，这显然是有问题的。

继续，我们虽然允许Acceptor接受多个编号提案，但是只要提案的内容V一直，那么Acceptor整体表现出来就是一致性，所以才有了P2，P2a实计上是P2的强化，本质上是一个内容

但我们考虑一种情况：

假设总的有5个Acceptor。Proposer2提出[M1,V1]的提案，Acceptor2~5（半数以上）均接受了该提案，于是对于Acceptor2~5和Proposer2来讲，它们都认为V1被选定。Acceptor1刚刚从宕机状态恢复过来（之前Acceptor1没有收到过任何提案），此时Proposer1向Acceptor1发送了[M2,V2]的提案（V2≠V1且M2>M1），对于Acceptor1来讲，这是它收到的第一个提案。根据P1（一个Acceptor必须接受它收到的第一个提案）,Acceptor1必须接受该提案！同时Acceptor1认为V2被选定。这就出现了两个问题：

1：Acceptor1认为V2被选定，Acceptor2~5和Proposer2认为V1被选定。出现了不一致。
2：V1被选定了，但是编号更高的被Acceptor1接受的提案[M2,V2]的value为V2，且V2≠V1。这就跟P2a（如果某个value为v的提案被选定了，那么每个编号更高的被Acceptor接受的提案的value必须也是v）矛盾了

这就出现了P2b去加强P2a的约束

至于定理的证明，书里是采用数学归纳法，这里我就不再展开了

2.2.2算法的内容

这里我不再阐述算法的初始和优化，直接给出结果，

经过上面的推导，我们总结下Paxos算法的流程。

Paxos算法分为两个阶段。具体如下：

阶段一：

(a) Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求。

(b) 如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（如果有的话）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案。
阶段二：

(a) 如果Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对[N,V]提案的Accept请求给半数以上的Acceptor。注意：V就是收到的响应中编号最大的提案的value，如果响应中不包含任何提案，那么V就由Proposer自己决定。

(b) 如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求做出过响应，它就接受该提案。