paxos算法如何保证acceptor挂掉一半以下也能正常决议?

发布于 2022-09-01 19:16:09 字数 220 浏览 33 评论 0

最近在学习paxos算法,看到paxos的整个过程中acceptor之间并没有做一致性的处理,各acceptor存储的数据可能是不同的,完全靠少数服从多数来产生决议。

比如有一个键值存储系统,使用paxos做一致性,现在有五台acceptor,其中三台储存的是1,一台储存2,一台储存3,然后挂掉了两台储存1的acceptor,现在1、2、3均不能获得多数,那么在learner进行get操作时如何产生结果?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

嘿看小鸭子会跑 2022-09-08 19:16:09

我刚学习ceph中的paxos,虽然可能有点不一样,但是尝试解释一下。

不是你认为的这种“少数服从多数”。

在有leader的情况下,值由leader决定。

你说的情况应该是5台acceptor同时承担proposer的角色,leader宕掉了,那么产生一个确定值(例如leader)的过程应该是这样的。5个proposer发起投票信息送向其他acceptor,其他的acceptor根据受到的投票的编号的值来判断是否“答应”。这里一个acceptor可能会先后收到多个proposer的投票信息,acceptor在该阶段会判断收到的编号与自己已经“答应”的编号比大小,若更大则“答应”更新的,否则无视掉。然后被答应的proposer会判断答应自己的acceptor有多少,如果超过一半则认为第一轮号召成功,就向答应的acceptor发送“协议”来“签订”。acceptor收到协议后判断附带的投票编号与自己保存的是否一致,是则返回“签订”信息。当proposer统计到签订自己协议的人够一半以上,则宣布自己是leader,将与自己签订的拉入quorum(这个才是少数服从多数的那个“多数”),于是该轮选举完毕。

实际上由于各种原因每个proposer送达信息的速度各不相同(如宕机),所以会出现更多的情况,如proposer向某个已经“答应”自己的acceptor请求“签订”时,acceptor已经完成了和某更大编号的“答应”与“签订”过程;或更大的来之前,acceptor与较小的签订好了,则后来的proposer只能将自己建议的值改为已经签订好的中编号最大的那个确定的值,保持一致性。等等。

建议再好好看看原文,虽然我也是一知半解。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文