如果更新值与接受者发送的最高提案编号不同步，paxos 是否会“忽略”更新值的请求？

这里的标题可能会产生误导。我将尽力通过一个例子来解释我的疑问。

我正在从 wiki 和其他来源阅读有关 paxos 算法的内容。

1) 想象一下客户端请求更新值的情况（X在下面的示例中）已被处理。 经过一轮 Paxos 后，得到一个值Vb之所以被选择，是因为接受者对提案者的回复包含他们之前接受的提案编号和相应的值。在下面的情况下，三个接受者发送(8,Va),(9,Vb),(7,Vc)给目前拥有的提案者(10,X)。它拾起(9,Vb)因为它是收到的最高提案编号并广播该值(10,Vb)给所有接受者接受。所以初始值X这整轮 Paxos 的处理从未得到更新。那么在这种情况下更新到X的客户端事务是否失败了呢？

之后Acceptors的最终状态是什么？他们都有吗(10,Vb)作为他们接受的最高提案数量和价值，从而保持同步？

Client   Proposer      Acceptor     Learner
   |         |          |  |  |       |  | --- First Request ---
   X-------->|          |  |  |       |  |  Request
   |         X--------->|->|->|       |  |  Prepare(10)
   |         |<---------X--X--X       |  |  Promise(10,{(8,Va),(9,Vb),(7,Vc)}
   |         X--------->|->|->|       |  |  Accept!(10,9,Vb)
   |         |<---------X--X--X------>|->|  Accepted(10,9,Vb)
   |<---------------------------------X--X  Response
   |         |          |  |  |       |  |
  

2）现在是一个更复杂的情况，在试图达成共识的过程中，在不同的时间点提出了两个提案。想象一下区域 A 中的客户端 C1 正在修改一些数据的情况X当Region B的客户端C2正在修改相同的数据时，尚未达成共识X。客户的其中一项请求是否被拒绝？请注意，C2 发生晚于 C1，但尚未达成共识。如果遵循排序，则必须完成C1请求，接受共识，然后处理C2请求。从我的理解来看这个博客 http://angus.nyc/writing/paxos-by-example/，本例中选择C1请求值。

那么C2请求是否被放弃了呢？这可能不是一个好的选择。

示例（版权所有this http://angus.nyc/writing/paxos-by-example/ blog):

在这种情况下，v=8最终选择了，尽管要求V=5是客户要求的最新更新。为什么会这样呢？这可能会产生严重影响

感谢您的帮助，祝新年快乐！

为了解释这一点，我将给出一些背景——OSI 协议栈的解释：

+------------------------+
|100. Your Application   |
#========================#
|8. Some state machine   |
|   or key/value store   |
+------------------------+
|7. Transaction log      |
+------------------------+
|6. Paxos                |
+------------------------+
|5. Some framing protocol|
+------------------------+
|4. TCP                  |
+------------------------+
|...                     |
+------------------------+

我见过的每一个认真的 paxos 实现都使用类似的模型（并且我见过许多认真的实现）。也就是说，Paxos用于选择事务日志中的下一个条目对于状态机（因为没有事务日志，数据库只是一个昂贵、缓慢、有缺陷的缓存）。事务日志中的每个条目都有一个不同的 Paxos 实例；他们是完全独立的；如果系统的设计者非常聪明，Paxos 实例甚至可以并行运行。

现在回答你的问题。

是的，第一个示例中的 X 失败了；它没有被选择。失败应返回给上层。这可能并不一定意味着客户端（上述模型中的“您的应用程序”）失败。上层可能决定重试事务日志中稍后条目中的值；或者他们可能只是向客户端返回失败信息。

在第二个示例中，其中一个请求最终必须被拒绝——Paxos 最多选择一个值。一旦选择了该值，它就会保持选择状态。就好像查克·诺里斯选择了它一样。

但第二个例子似乎有一点误解。哪个请求先启动并不重要。由于网络延迟和行星排列，第二个请求可能会取代第一个请求。

尝试一下！以X、Y为值； P1、P2作为提议者；和 A1,A2,A3 作为受体：

1. P1有X并发送Prepare(1)
2. A1 承诺 1 并返回 Accepted(0,_)
3. A2 承诺 1 并返回 Accepted(0,_)
4. A3 承诺 1 并返回 Accepted(0,_)
5. P1 仍然有 X 并发送 Accept(X,1)
6. A1 接受(X,1)
7. P2有Y并发送Prepare(2)
8. A2 promises for 2 and returns Accepted(1,_)
   • 如您所见，A2 已转为不接受任何小于 2 的回合
9. A2 拒绝 Accept(X,1)
10. A3 承诺 2 并返回 Accepted(1,_)
11. P2 仍然有 Y 并发送 Accept(Y,2)
12. A2 接受(Y,2)
13. A3 accepts(Y,2)
    • 由于简单多数的接受，Y 被选中。从现在开始，无论任何提议者做什么，Y 的值都将始终被选择。

这实际上开始有点像你在第二个例子中的图片，但在这个例子中，网络支持第二个提议者。