细读经典第二期——从Paxos到Zookeeper 分布式一致性原理与实践（2）
作者：互联网
目录
第二章：
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请求做出过响应，它就接受该提案。
到此你可能会疑惑，Learner去哪了？别着急，当提案选定以后，Learner就上场了
Learner获取提案有三种方案，这里我盗用一张图，这样会讲的更清楚
算法大致已经讲完了，但是这里再提出一种情况：
说白了就是没有主Proposer导致Proposer提案无法保证按照合理的顺序提出，当然这里的解决也很简单，只选定一个主Proposer提出提案即可。
以上就是2.2节对于Paxos算法的核心内容
加油！
标签：Zookeeper,细读,Proposer,算法,编号,提案,Paxos,Acceptor1,Acceptor 来源： https://blog.csdn.net/u014783007/article/details/120112974