我对paxos有些困惑,特别是在数据库事务的上下文中：

在文章“paxos简单”中,它在第二阶段说,提议者需要选择一个具有最高序列号的值,其中一个接受者之前已接受(如果不存在这样的值,则提议者可以自由地选择建议的原始值).

问题：

>一方面,我理解维持共识是这样做的.
但另一方面,我对实际价值的含义感到困惑 – “必须向接受者发送之前接受的价值”是什么意思？
>在数据库事务的上下文中,如果需要提交新值,该怎么办？是否需要启动Paxos的新实例？
>如果上述问题的答案为“是”,那么接受者如何重置状态？ (根据我的理解,如果它没有重置状态,提议者将被迫发送之前已被接受的旧值之一,而不是随意提交任何新值.)

最佳答案 我将尝试解释如何使用Paxos实现数据库事务,而不是直接回答您的问题,这可能有助于清理问题.

首先要注意的是,这里有两个“值”.首先是数据库值,即正在修改的应用程序级数据.其次是“提交”/“中止”决定.对于基于Paxos的交易,共识“价值”是“提交”/“中止”决策.

关于Paxos共识的数据库交易需要牢记的一点是,Paxos并不保证交易中涉及的所有对等方都能真正看到共识决策.当需要这样做时,通常是数据库,它留给应用程序以确保发生这种情况.这意味着某些对等体存储的状态可能落后于其他状态,并且构建在Paxos之上的任何数据库应用程序都需要一些机制来处理它.这可能非常复杂,并且都是特定于应用程序的,所以我将完全忽略所有这些,并专注于确保所有数据库副本的简单大多数同意数据库密钥FOO的修订版2的值,当然,最初设置为BAR.

第一步是发送FOO的新值,让我们说是BAZ,它是预期的当前版本1,以及Paxos Prepare消息.当数据库副本收到此消息时,他们将首先查找其FOO的本地副本,并检查当前修订是否与Prepare消息中包含的预期修订一致.如果它们匹配,则数据库副本将捆绑“投票提交”标志以及响应准备发送的Promise消息.如果它们不匹配将发送“Vote Abort”(修订检查可以防止自上次应用程序读取后修改了值的情况.在这种情况下允许覆盖可能会破坏应用程序状态).

一旦事务驱动程序收到法定数量的Promise消息及其关联的“投票提交”/“投票中止”值,它必须选择建议“提交”或“中止”.选择此值的第一步是遵循Paxos检查Prepare消息的要求,以查看是否有任何数据库副本(Paxos术语中的Acceptor)已接受“Commit”/“Abort”决策.如果它们中的任何一个具有,则事务驱动程序必须选择与先前接受的最高提议ID相关联的“提交”/“中止”值.如果他们没有,它必须自己决定.这是通过查看与Promises捆绑在一起的“投票提交”/“投票中止”值来完成的.如果存在“Vote Commmit”的法定人数,则交易驱动程序可以建议“提交”,否则它必须提出“中止”.

从那时起,所有标准的Paxos消息都会来回交换,直到就“提交”/“中止”决定达成共识.假设选择“提交”,数据库复制者将分别将与FOO关联的值和修订更新为BAZ和2.