ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

细读经典第二期——从Paxos到Zookeeper 分布式一致性原理与实践(2)

2021-09-05 13:34:00  阅读:176  来源: 互联网

标签:Zookeeper 细读 Proposer 算法 编号 提案 Paxos Acceptor1 Acceptor


目录

第二章:

2.2 PAXOS

2.2.1基本定理的引出和推导

2.2.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没有对编号大于NPrepare请求做出过响应,它就接受该提案。

到此你可能会疑惑,Learner去哪了?别着急,当提案选定以后,Learner就上场了

Learner获取提案有三种方案,这里我盗用一张图,这样会讲的更清楚

算法大致已经讲完了,但是这里再提出一种情况: 

说白了就是没有主Proposer导致Proposer提案无法保证按照合理的顺序提出,当然这里的解决也很简单,只选定一个主Proposer提出提案即可。

以上就是2.2节对于Paxos算法的核心内容

加油!

标签:Zookeeper,细读,Proposer,算法,编号,提案,Paxos,Acceptor1,Acceptor
来源: https://blog.csdn.net/u014783007/article/details/120112974

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有