内容简介：Paxos 论文提到, 发起 proposal(即 accept 类型的消息)时, 用的"值" v 是之前 prepare 时收集到的, 否则就是 any value.这个说法其实非常具有迷惑性, 并导致了大量奇怪的说法. 如果用的是收集到的旧值, 那我(用户)要更新数据怎么更新?所以, 大家实现 Paxos 时, 这里就变成了用的是用户请求的值回复自己发出的 prepare. 这其实违反了论文, 因为论文提到, 收集到的值必须是曾经 accepted 的值, 但是, 用户的请求还没有开始呢, 何来已接受?
1. 值的选择
Paxos 论文提到, 发起 proposal(即 accept 类型的消息)时, 用的"值" v 是之前 prepare 时收集到的, 否则就是 any value.
这个说法其实非常具有迷惑性, 并导致了大量奇怪的说法. 如果用的是收集到的旧值, 那我(用户)要更新数据怎么更新?
所以, 大家实现 Paxos 时, 这里就变成了用的是用户请求的值回复自己发出的 prepare. 这其实违反了论文, 因为论文提到, 收集到的值必须是曾经 accepted 的值, 但是, 用户的请求还没有开始呢, 何来已接受?
另一个迷惑的地方是"any value", 很多人都翻译成"随机/随意选取一个值". 这属于不严谨. 怎么能随意呢? 选择哪个值的依据(算法或者逻辑)是确定的, 两个集群做了同样的操作, 一个选择 a, 另一个选择 b? 当然, 实际的意思并不是"随机", 而是"决定", 实践上, 就是决定使用客户端所请求的那个值(如果进度相同的话).
2. Proposal number
Paxos 要求每个节点使用不同的 number 来 prepare, 但是, 即使使用相同的 number 来 prepare 似乎也没有问题? 因为只有唯一的一个能 prepare 成功.
所以, 如果有人知道, 请告诉我, 两个 proposer 使用同一个 number 来 prepare 会导致什么问题? prepare 不就是要解决 number 分配的问题(同时交换最新值)的吗?
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
RGB转16进制工具
RGB HEX 互转工具
HTML 编码/解码
HTML 编码/解码