【发布时间】：2013-03-05 03:55:41
【问题描述】：
我对提议者选择的值感到困惑。 用一个例子来解释。如果现在一个提议者想要锁定一个文件，那么它将发送 l1 是处理器编号，v1 是“锁定文件”的值，并且接受者接受它。 比提议者要解锁文件，并发送（l2 > l1）v2是“解锁文件”的值，之后，接受者返回最后一个值，提议者选择并再次发送。
在这个例子中，v2 丢失了？或者这个例子中的真实过程是什么？ 还有，这是两轮还是一轮？回合怎么处理？
【问题讨论】：
标签： paxos
【发布时间】：2013-03-05 03:55:41
【问题描述】：
Paxos 不是原子寄存器；一旦 Paxos 选择了一个值，它就不能改变。
首先，请注意您的锁是一个有限状态机：
on_lock
.-----------.
| |
+------+---+ +--v-----+
| UNLOCKED | | LOCKED |<--- start
+------^---+ +--+-----+
| |
`-----------'
on_unlock
Paxos 可以用来决定一个转换序列；但是每个新的转换必须在一个新的 Paxos 实例中决定。
我建议看一下有关 StackOverflow 的其他一些 paxos 问题：
【讨论】：
我们需要描述一个可以使用 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；但如果锁已关闭，则返回谁拥有锁。
写入必须通过领导者。如果一个节点知道它不是领导者，它应该将客户端重定向到领导者。如果节点不知道谁是领导者，它应该抛出一个错误，客户端应该随机选择另一个节点。如果节点认为它是领导者，它只能在确定大多数节点已经接受新值时才响应客户端。这是因为 Paxos 确保大多数人接受的值已被集群持久化。如果一个节点处于领先地位，那么没有听到大多数接受，它就无法响应客户端。它可以与其他节点隔离。其他节点可能有一个新选出的领导者。这也适用于{Nil,Nil} 查询，这些查询需要大多数接受以确认领导者仍然是领导者以告诉客户端当前锁定值。最终节点应该听到是否存在新的领导者，否则超时试图获得多数人接受的值。然后它应该要么将客户端重定向到新的领导者，要么向客户端返回错误。
现在我们可以在领导故障转移期间考虑多个值。客户端 A 发送一个有效的 CAS 更新 V1，它应该成功到三节点集群的领导节点 X。节点X 发送accept(N1,V1) 给它自己和节点Y 和Z。它接受自己的值，也得到Y 的接受，但网络将消息丢弃到Z。然后节点X 变暗并停止发布任何消息一段时间。它可能已经死亡或停滞，但我们还不知道。它看到了X,Y 的大部分，但现在是一只神秘的薛定谔猫，要么死要么活，直到我们看到它发出的另一条消息来了解它的命运。这就是 Paxos 选择使用协作来获得一致且正确的结果的地方，无论接下来发生什么。
一段时间后，节点Z 超时，因为它已经太长时间没有收到领导者的消息了。它向自己和其他节点发出propose(N2)。它从节点Y 和promise(N2,empty) 自身返回promise(N2,V1)。它拥有多数 Y,Z 并且可以领先。只有节点X 知道值V1 已被大多数人接受，以及客户端是否被告知其CAS 成功；但它是沉默的。节点Z 必须做出保守的选择。如果假设X 已经死了，那可能是错误的：节点X 可能还活着并且可能已经告诉客户端操作成功了。节点Z 必须协作并通过以V1 作为其第一个值领导来完成最后一个领导者的部分工作。因此它将accept(N2,V1) 发送到所有三个节点。现在，节点X 是死是活还是告诉客户端操作成功与否都无关紧要。在所有情况下，锁定协议都不会被违反，如果客户端在错误时重试，最终会发现它有锁；它不看也不关心什么提案或哪个节点提交了工作。
【讨论】：