0

我对提议者选择的价值感到困惑。用一个例子来解释。如果现在一个提议者想要锁定一个文件，那么它将发送 l1 是处理器编号，v1 是“锁定文件”的值，并且接受者接受它。比提议者要解锁文件，并发送（l2 > l1）v2 是“解锁文件”的值，之后，接受者返回最后一个值，提议者选择它并再次发送。

在这个例子中，v2 丢失了吗？或者这个例子中的真实过程是什么？还有，这是两轮还是一轮？怎么处理圆？

4

2 回答 2

1

Paxos 不是一个原子寄存器；一旦 Paxos 选择了一个值，它就不能改变。

首先，请注意您的锁是一个有限状态机：

          on_lock
       .-----------.
       |           |
+------+---+    +--v-----+
| UNLOCKED |    | LOCKED |<--- start
+------^---+    +--+-----+
       |           |
       `-----------'
         on_unlock

Paxos 可用于决定一系列转换；但是每个新的转换都必须在一个新的 Paxos 实例中决定。

我建议看一下有关 StackOverflow 的其他一些 paxos 问题：

于 2013-03-08T22:25:03.933 回答
0

我们需要描述一个可以使用 Paox 运行的锁定协议，以便了解何时有多个值可用并查看选择一个值的结果。

锁是一个以 格式保存锁令牌值的单元格L={T,P}，其中P是持有锁的进程，是进程获取锁T的时间。为了获取锁，客户端发送V={Lc,Ln}它Lc认为是当前锁令牌的位置以及Ln={T',P'}它想要设置的新锁令牌。Nil可以发送一个特殊的令牌来解锁锁。如果消息未声明与当前令牌匹配的正确，则不会设置新Lc令牌。这种比较和交换 (CAS) 可防止错误地应用延迟解锁消息。当客户端可以窃取锁时，它还可以使锁超时；如果两个进程发送两个竞赛消息{L1,L2}并且{L1,L3}只有一个人可以成功。进程通过检查返回值（锁定值）来了解其操作是否成功L。进程可以通过发送{Nil,Nil}“什么都不做”的 CAS 来解锁打开的锁来查询锁值；但如果锁已关闭，则返回谁拥有锁。

写入必须通过领导者。如果一个节点知道它不是领导者，它应该将客户端重定向到领导者。如果节点不知道谁是领导者，它应该抛出一个错误，客户端应该随机选择另一个节点。如果节点认为它是领导者，它只能在确定大多数节点已经接受新值时才响应客户端。这是因为 Paxos 确保大多数人接受的值已被集群持久化。如果一个节点处于领先地位，那么没有听到大多数接受，它就无法响应客户端。它可以与其他节点隔离。其他节点可能有一个新选出的领导者。这也适用于{Nil,Nil}需要大多数接受来确认领导者仍然是领导者的查询，以告诉客户端当前的锁定值。最终节点应该听到是否存在新的领导者，否则超时试图获得多数人接受的值。然后它应该要么将客户端重定向到新的领导者，要么向客户端返回错误。

现在我们可以在领导故障转移期间考虑多个值。客户端 A 发送一个有效的 CAS 更新V1，该更新应该成功到三节点集群的领导节点X。节点X发送accept(N1,V1)给自己和节点Y和Z。它接受自己的值，也接受来自，Y但网络将消息丢弃到Z. 然后节点X变暗并停止发布任何消息一段时间。它可能已经死亡或停滞，但我们还不知道。它曾经见过大部分，X,Y但现在是一只神秘的薛定谔猫，要么死要么活，直到我们看到它发出的另一条信息来了解它的命运。这就是 Paxos 选择使用协作来获得一致且正确的结果的地方，无论接下来发生什么。

一段时间后，节点Z超时，因为它没有收到领导者的消息太久。它propose(N2)发给自己和其他节点。它promise(N2,V1)从节点Y和promise(N2,empty)自身返回。它占多数Y,Z并且可以领导。只有节点X知道该值V1已被大多数人接受，以及客户端是否被告知其 CAS 成功；但它是沉默的。NodeZ不得不做出一个保守的选择。如果假设它X已经死了，那可能是错误的：节点X可能还活着并且可能已经告诉客户端操作成功了。节点Z必须协作完成最后一个领导者的部分工作，以领导V1作为其第一个值。所以它发送accept(N2,V1)到所有三个节点。现在节点是否无关紧要X是死是活，或者已经告诉客户手术成功与否。在所有情况下，锁定协议都不会被违反，如果客户端在错误时重试，最终会发现它有锁；它不看也不关心什么提案或哪个节点提交了工作。

于 2014-10-25T22:01:33.997 回答