Question

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

在这个例子中，v2丢失了吗？或者这个例子中的真实过程是什么？还有，这两轮或一轮？如何应对这轮？

Answer 1

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

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

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

Paxos可用于决定转换序列; 但必须在新的Paxos实例中确定每个新转换。

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

Answer 2

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

锁是一个单元格，其中包含L={T,P}格式的锁定标记值，其中P是持有锁的进程，T是进程锁定的时间。要获取锁定，客户端会发送V={Lc,Ln}，其中Lc是其认为的当前锁定令牌，Ln={T',P'}是要设置的新锁定令牌。可以发送特殊令牌Nil来解锁锁。如果消息未声明与当前令牌匹配的正确Lc，则不设置新令牌。此比较和交换（CAS）可防止错误地应用延迟解锁消息。它还可以在客户端窃取锁时超时锁定;如果两个进程发送两个赛车消息{L1,L2}和{L1,L3}，则只有一个可以成功。进程通过检查返回值（锁定值L）来获知操作是否成功。进程可以通过发送{Nil,Nil}来查询锁定值，{Nil,Nil}是解除打开锁定的“无所事事”CAS;但如果锁定关闭，谁返回谁拥有锁。

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

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

经过一段时间节点propose(N2)超时，因为它太长时间没有从领导者那里听到。它向自己和其他节点发出promise(N2,V1)。它从节点Y和promise(N2,empty)返回Y,Z。它有多数X并且可以领先。只有节点V1知道多数人已接受了值Z，并且客户端是否已被告知CAS已成功;但它是沉默的。节点X必须做出保守的选择。如果假设X已经死亡，则可能是错误的：节点Z可能存在，并且可能已告知客户端操作成功。节点V1必须通过引导accept(N2,V1)作为其第一个值来协作并完成最后一个领导者的部分工作。因此它将X发送到所有三个节点。现在，无论节点{{1}}是死还是活，或者告诉客户端操作是否成功，都无关紧要。在所有情况下，锁定协议都不会被违反，如果错误重试，客户端会发现它最终会锁定;它没有看到或关心什么提案或哪个节点承诺工作。

关于paxos的一些问题

2 个答案: