大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全家桶1年46,售后保障稳定
Paxos
- Paxos 这个算法是Leslie Lamport在1990年提出的一种基于消息传递的一致性算法 Paxos 算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。
- part-time parliament Paxos Made Simple里这样描述Paxos算法执行过程:
- prepare 阶段:
- proposer【申请人】 选择一个提案编号 n 并将 prepare 请求发送给 acceptors【接收者】 中的一个多数派;
- acceptor 收到 prepare 消息后,如果提案的编号大于它已经回复的所有 prepare 消息,则 acceptor 将自己上次接受的提案回复给 proposer,并承诺不再回复小于 n 的提案;
- 批准阶段:
- 当一个 proposer 收到了多数 acceptors 对 prepare 的回复后,就进入批准阶段。它要向回复 prepare 请求的 acceptors 发送 accept 请求,包括编号 n 和根据 P2c 决定的 value(如果根据 P2c 没有已经接受的 value,那么它可以自由决定 value)。
- 在不违背自己向其他 proposer 的承诺的前提下,acceptor 收到 accept 请求后即接受这个请求。
- Learn 阶段:
- 当各个Acceptor达到一致之后,需要将达到一致的结果通知给所有的Learner;
故事的形式举例
- 有一个叫做Paxos的小岛(Island)上面住了一批居民,岛上面所有的事情由一些特殊的人决定,他们叫做议员(Senator)。
- 议员的总数(SenatorCount)是确定的,不能更改。
- 岛上每次环境事务的变更都需要通过一个提议(Proposal),每个提议都有一个编号(PID),这个编号是一直增长的,不能倒退。
- 每个提议都需要超过半数((SenatorCount)/2+1)的议员同意才能生效。
- 每个议员只会同意大于当前编号的提议,包括已生效的和未生效的。
- 如果议员收到小于等于当前编号的提议,他会拒绝,并告知对方:你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号,他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。
- ————————————————————————————————————
- 现在议会有一个目标:保证所有的议员对于提议都能达成一致的看法。
- 好,现在议会开始运作,所有议员一开始记事本上面记录的编号都是0。
- 有一个议员发了一个提议:
- 将电费设定为1元/度。他首先看了一下记事本,嗯,当前提议编号是0,那么我的这个提议的编号就是1,于是他给所有议员发消息:1号提议,设定电费1元/度。其他议员收到消息以后查了一下记事本,哦,当前提议编号是0,这个提议可接受,于是他记录下这个提议并回复:我接受你的1号提议,同时他在记事本上记录:当前提议编号为1。发起提议的议员收到了超过半数的回复,立即给所有人发通知:1号提议生效!收到的议员会修改他的记事本,将1好提议由记录改成正式的法令,当有人问他电费为多少时,他会查看法令并告诉对方:1元/度。
- ————————————————————————————————————
- 现在看冲突的解决:
- 假设总共有三个议员S1-S3,S1和S2同时发起了一个提议:1号提议,设定电费。S1想设为1元/度,S2想设为2元/度。结果S3先收到了S1的提议,于是他做了和前面同样的操作。紧接着他又收到了S2的提议,结果他一查记事本,咦,这个提议的编号小于等于我的当前编号1,于是他拒绝了这个提议:对不起,这个提议先前提过了。于是S2的提议被拒绝,S1正式发布了提议:1号提议生效。S2向S1或者S3打听并更新了1号法令的内容,然后他可以选择继续发起2号提议。
- 好,我觉得Paxos的精华就这么多内容。现在让我们来对号入座,看看在ZKServer里面Paxos是如何得以贯彻实施的。
- 小岛(Island)——ZKServerCluster
- 议员(Senator)——ZKServer
- 提议(Proposal)——ZNodeChange(Create/Delete/SetData…)
- 提议编号(PID)——Zxid(ZooKeeperTransactionId)
- 正式法令——所有ZNode及其数据:
- 貌似关键的概念都能一一对应上,但是等一下,Paxos岛上的议员应该是人人平等的吧,而ZKServer好像有一个Leader的概念。没错,其实Leader的概念也应该属于Paxos范畴的。如果议员人人平等,在某种情况下会由于提议的冲突而产生一个“活锁”(所谓活锁我的理解是大家都没有死,都在动,但是一直解决不了冲突问题)。Paxos的作者Lamport在他的文章”ThePart-TimeParliament“中阐述了这个问题并给出了解决方案——在所有议员中设立一个总统,只有总统有权发出提议,如果议员有自己的提议,必须发给总统并由总统来提出。好,我们又多了一个角色:总统。
- 总统——ZKServerLeader
- 现在我们假设总统已经选好了,下面看看ZKServer是怎么实施的。
- 情况一:
屁民甲(Client)到某个议员(ZKServer)那里询问(Get)某条法令的情况(ZNode的数据),议员毫不犹豫的拿出他的记事本(localstorage),查阅法令并告诉他结果,同时声明:我的数据不一定是最新的。你想要最新的数据?没问题,等着,等我找总统Sync一下再告诉你。
情况二:
屁民乙(Client)到某个议员(ZKServer)那里要求政府归还欠他的一万元钱,议员让他在办公室等着,自己将问题反映给了总统,总统询问所有议员的意见,多数议员表示欠屁民的钱一定要还,于是总统发表声明,从国库中拿出一万元还债,国库总资产由100万变成99万。屁民乙拿到钱回去了(Client函数返回)。
情况三:
总统突然挂了,议员接二连三的发现联系不上总统,于是各自发表声明,推选新的总统,总统大选期间政府停业,拒绝屁民的请求。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/222954.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...