我对paxos有些困惑，特别是在数据库事务的上下文中：
在文章“简单的paxos”中，它在第二阶段说，提议者需要选择一个具有最高序列号的值，其中一个接受者之前已接受（如果不存在这样的值，则提议者可以自由选择建议的原始值。
问题：
一方面，我理解维持共识是这样做的。 但另一方面，我对这个价值究竟是什么感到困惑 - “必须向接受者发送之前接受过的价值”是什么意思？
在数据库事务的上下文中，如果需要提交新值，该怎么办？是否需要启动Paxos的新实例？
如果上述问题的答案为“是”，那么接受者如何重置状态？ （根据我的理解，如果它没有重置状态，提议者将被迫发送之前已被接受的旧值之一，而不是随意提交任何新值。）
答案 0 :(得分：1)
我不会直接回答您的问题，而是会尝试解释如何使用Paxos实现数据库事务，这可能有助于清理问题。
首先要注意的是，这里有两个“价值”问题。首先是数据库值，即正在修改的应用程序级数据。其次是“提交”/“中止”决定。对于基于Paxos的交易，共识“价值”是“提交”/“中止”决策。
关于Paxos共识的数据库事务要记住的重要一点是，Paxos 不保证交易中涉及的所有对等方实际上都会看到共识决策。当需要这样做时，通常是数据库，它留给应用程序以确保发生这种情况。这意味着某些对等体存储的状态可能落后于其他状态，并且构建在Paxos之上的任何数据库应用程序都需要一些机制来处理它。这可能非常复杂，并且都是特定于应用程序的，所以我将完全忽略所有这些，并专注于确保所有数据库副本的简单大多数同意数据库密钥FOO的修订版2的值，当然，最初设置为BAR。
第一步是发送FOO的新值，让我们说是BAZ，它是预期的当前版本1，以及Paxos Prepare 消息。当数据库副本收到此消息时，他们将首先查找其FOO的本地副本，并检查当前修订是否与 Prepare 消息中包含的预期修订一致。如果它们匹配，则数据库副本将捆绑“投票提交”标志以及为响应准备而发送的 Promise 消息。如果它们不匹配将发送“Vote Abort”（修订检查可以防止自上次应用程序读取后修改了值的情况。在这种情况下允许覆盖可能会破坏应用程序状态）。
一旦事务驱动程序收到法定数量的 Promise 消息及其关联的“投票提交”/“投票中止”值，它必须选择建议“提交”或“中止”。选择此值的第一步是遵循Paxos检查准备消息的要求，以查看是否有任何数据库副本（Paxos术语中的 Acceptor ）已接受“提交“/”中止“决定。如果其中任何一个具有，则事务驱动程序必须选择与先前接受的最高提议ID相关联的“提交”/“中止”值。如果他们没有，它必须自己决定。这是通过查看与 Promise 捆绑在一起的“投票提交”/“投票中止”值来完成的。如果存在“Vote Commmit”的法定人数，交易驱动程序可以提出“提交”，否则必须提出“中止”。
从那时起，这是所有标准的Paxos消息，在“提交”/“中止”决定达成共识之前来回交换。假设选择了“提交”，数据库复制者将分别将与FOO关联的值和修订更新为BAZ和2。
答案 1 :(得分：1)
Paxos中有不同类型的paxos简单＆＃34;纸。一个是Paxos（普通paxos，单度paxos，synod），另一个是Multi-Paxos。从工程师的角度来看，第一个是分布式一次写入寄存器，第二个是分布式追加日志。
数目：
在Paxos的上下文中，实际值是成功写入一次写入寄存器的值，它发生在大多数接受器接受同一轮的值时。在论文中，它表明新选择的值总是与之前相同（如果选择的话）。因此，要获得实际值，我们应该启动新一轮并返回新的成功写入值。
在Multi-Paxos的上下文中，实际值是添加到日志中的最新值。
使用Multi-Paxos，我们只需在日志中添加一个新值。要读取当前值，我们读取日志并返回最新版本。 在低级别上，Multi-Paxos是一个Paxos寄存器阵列。要写一个新值，我们将它的当前值的位置放在一个空闲寄存器中，然后我们用no-op填充以前的空闲寄存器。当两个寄存器包含相同前一个值的两个不同的下一个值时，我们选择阵列中位置最低的寄存器。
使用Multi-Paxos是可能的，也是微不足道的：我们只是通过免费注册开始新一轮的Paxos。虽然简单的Paxos不能覆盖它，但我们可以延伸＆＃34;然后变成分布式变量而不是dist。寄存器。我在"A memo on how Paxos works"帖子中描述了这个想法和证据。
答案 2 :(得分：0)
我在long blog with links to sourcecode论文中描述的使用paxos进行事务日志复制的主题上写了Paxos Made Simple。在这里，我简要回答你的问题。博客文章和源代码显示了完整的图片。
一方面，我理解这样做是为了保持共识。但是 另一方面，我对实际价值的含义感到困惑 - 什么是“必须向接受者发送已经存在的价值” 在“？
之前接受
该值是客户端尝试在群集上运行的命令。在中断期间，由最后一个领导者发送到所有节点的客户端值可能仅到达幸存多数中的一个节点。新领导者可能不是该节点。新领导者从至少一个幸存节点发现客户端值，然后将其发送到幸存多数节点中的所有节点。通过这种方式，新领导者与死去的领导者合作，完成其可能正在进行的任何客户工作。
在数据库事务的上下文中，如果需要提交一个，那该怎么办？ 新价值？是否需要启动Paxos的新实例？
在重建上一个领导者选择的所选值的历史记录之前，它无法从客户端选择任何新命令。博客文章称这是一个“领导者接管阶段”，在旧领导人崩溃之后，新领导人正在努力使所有节点完全更新。
实际上，无论最后一个领导者传输到大多数节点，都会选择;新领导人无法改变这段历史。在接管阶段，它只是同步节点以使它们都是最新的。只有当新领导者完成这一阶段时，才知道所有选定的值都是最新的，它可以处理任何新的客户命令（即处理任何新的工作）。
如果上述问题的答案是“是”，那么接受者如何 重置状态？
他们没有。选择的值与任何节点学习选择该值之间存在差距。在数据库的上下文中，您无法“提交”该值（将其应用于数据存储），直到您“了解”所选值。 Paxos确保所选择的值永远不会被撤消。因此，在您了解已选择该值之前，请不要提交该值。博客文章提供了更多细节。
答案 3 :(得分：0)
这是我实施木筏和阅读ZAB论文的经验。这是PAXOS的两个流行的化身。我还没有真正进入简单的paxos或multipaxos。
当客户端向集群中的任何节点发送提交时，它会将该提交重定向到领导者，然后领导者将提交消息发送到仲裁中的每个节点，当所有节点确认它将提交的提交时它是自己的日志。