我正在使用Wikipedia中提供的文档在集群模拟器应用程序中实现Paxos。不幸的是，它留下了几个可以解释的门，并没有提供关于关键实施问题的大量信息。它不清楚且不完整。
Paxos不会进入无限循环吗？我想如果一个人不能与至少一个法定数量的节点通信，就不应该发起Paxos。
'接受的最后一个价值'是什么？来自提议者的任何先前提案编号是什么？ 在这种情况下，'实例'究竟是指什么？
在阶段1a：是否包含与准备消息达成一致的值，或者是否延迟到接受！信息？或者它确实重要？
在阶段2a：'如果任何接受者已经接受了值，则领导者必须选择值且最大提案号为'。
这里有什么价值？是提案编号吗？我不相信，但这句话不清楚。
在阶段2a：'否则，投标人可以自由选择任何价值'。这是什么意思？什么价值？对于提案号码？
Paxos似乎依赖于增加的N（提案号）值来运作？这是对的吗？
维基百科条目不讨论节点在开始参与Paxos之前应该设置的初始值。这些是什么？
P.S。：我没有足够的声誉来创建'Paxos'标签（任何志愿者？）
答案 0 :(得分：18)
什么是实例？
Paxos的命名法有点不直观。
假设一个集群分为3个区域，每个区域包含3个节点（总共= 9个节点）。如果地区之间的沟通中断，会发生什么？任何领导者都无法达到法定人数（即5）。
Paxos要求您至少可以达到法定人数（在您的情况下为5个节点）。选择三个区域的解决方案;在这三个地区之间有两个网络分区是非常坏的消息。我还使用了一个版本的Paxos，可以将节点成员资格从一个实例更改为下一个实例。这对分区和节点故障很有用。
不是Paxos会进入无限循环吗？
Paxos的天真实现无法保证终止，因为多个节点可以跳跃准备阶段。有两种方法来解决这个问题。一种是在开始新的准备阶段之前进行随机退避。第二种是将所有请求路由到指定的领导者，该领导者充当提议者（领导者由Paxos实例选择。参见多篇论文）
在阶段1b：＆＃39;如果提案编号N大于任何先前的提案，则每个＆gt;＆gt; Acceptor承诺不接受小于N的提案，并发送它最后接受的值＆gt;＆gt; ;这个实例是Proposer＆＃39;。
它接受的最后一个值＆＃39 ;?是否是提议者提出的任何提议编号？
当节点收到来自Proposer 和的Accept！（roundId，value）消息时，它没有承诺不接受该值（由于Prepare！（higherRoundId）消息） ，它存储值和roundId（我称之为acceptedValue和acceptedRoundId）。由于后续的Accept！（...）消息，它可能会覆盖这些消息。
当节点从Proposer收到Prepare！（roundId）消息时，它将roundId存储为promiseRoundId = max(roundId, promiseRoundId)。然后它会将Promise!(acceptedRoundId, acceptedValue)发送回Proposer。注意：如果某个节点没有收到Accept！（...）消息，则会回复Promise!(null, null)。
在阶段1a：是否包含与准备消息达成一致的值，或者是否延迟到接受！信息？或者它确实重要？
无需发送。我没有。
在阶段2a中：＆＃39;如果任何接受者已经接受了值，则领导者必须选择最大提议编号为N＆＃39;的值。
这里有什么价值？是提案编号吗？我不相信，但这句话不清楚。
该值是算法达成共识的实际数据。我将此改为
要开始接受阶段，提议者必须根据准备阶段的结果选择要接受的值。如果任何Acceptor回复Promise（roundId，value），则Proposer必须使用与最高roundId关联的值。否则，Proposer只收到Promise（null，null），并可以选择任何值发送给接受者。
注意：这里的提案号与roundId相同。
在阶段2a：＆＃39;否则，投标人可以自由选择任何值＆＃39;。这是什么意思？什么价值？对于提案编号？
这是您希望达成共识的价值。这通常是跨分布式系统的状态更改，可能由客户端请求触发。
Paxos似乎依赖于增加的N（提案号）值来运作？这是对的吗？
维基百科条目不讨论节点在开始参与Paxos之前应该设置的初始值。这些是什么？
圆形ID（也就是提议编号）应该增加，必须在所有节点上每个实例都是唯一的。 Paxos论文假设您可以这样做，因为实现它是微不足道的。这是一种在所有节点上产生相同结果的方案：
roundId = i*M + index[node]其中i是第i个循环，此节点正在启动（即每个paxos实例的每个节点i是唯一的，并且单调递增）。或伪代码（显然缺少一些主要的优化）：
define runPaxos( allNodesThisPaxosInstance, myValue ) {
allNodesThisPaxosInstance.sort()
offset = allNodesThisPaxosInstance.indexOf( thisNode )
for (i = 0; true; i++) {
roundId = offset + i * allNodesThisPaxosInstance.size()
prepareResult = doPreparePhase( roundId )
if (!prepareResult.shouldContinue?)
return
if (prepareResult.hasAnyValue?)
chosenValue = prepareResult.valueWithHighestRoundId
else
chosenValue = myValue
acceptResult = doAcceptPhase( roundId, chosenValue )
if (!acceptResult.shouldContinue?)
return
}
}
答案 1 :(得分：2)
我发现以下document更详细地解释了Paxos。我已相应更新了维基百科条目。
我能找到的问题的答案是：
Paxos不会进入无限 循环？
只有至少法定数量的节点可以相互通信（在我们的例子中为5），Paxos才有效。因此，如果节点无法与至少一个法定数量的节点通信，则不应尝试Paxos。
'接受的最后一个价值'是什么？
这是最后接受的命题编号和相应的值。
在这种情况下，'实例'究竟是指什么？
指的是接受者。
是否包含值得商定的价值 与准备消息或是这样 推迟到接受！信息？或者它 重要吗？
该值不包含在Prepare消息中，它留给Accept Request消息。
这里有什么价值？是提案吗？ 数？我不相信，但这句话 目前还不清楚。
'否则，提议者可以自由选择 选择任何价值'。这是什么 意思？什么价值？为了 提案号？
如果接受者已经接受了提议者的提议，他们可以返回相应的提案号和值，否则没有。
第二个问题出现了，因为维基百科条目具有误导性。可以为给定提案选择任意值，也可以从与之前接受的提案相对应的值中推导出该值。
Paxos似乎依赖于增加的N（提案号）值来运作？这是对的吗？
是。提议者需要越来越多地对其提案进行编号。
维基百科条目不讨论节点在开始参与Paxos之前应该设置的初始值。这些是什么？
节点应保留其最后接受的提议编号，并最终保留相应的值。他们应该坚持下去。第一次连接时，给定提议者的初始提议编号应为null（或任何等效文件）。
答案 2 :(得分：0)
Paxos seems to rely on an increasing value of N (proposal number) to work? Is this correct?
每个提议者都有稳定的存储空间。每个提议者都会记住（在稳定存储中）它尝试发布的编号最高的提案，并开始第1阶段的提案编号高于其已使用的提案编号。