为什么使用接下来的两个命令来填补 paxos 事件之间的空白是合法的？
Why is it legit to take the next two commands to fill gaps between paxos events?
Paxos算法(http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf)中有一点我没看懂。关于如何处理间隙，本文描述了以下两种方法：
The leader, as well as any other server that learns all the commands the leader knows, can now execute commands 1–135. However, it can’t execute commands 138–140, which it also knows, because commands 136 and 137 have yet to be chosen. The leader could take the next two commands requested by clients to be commands 136 and 137. Instead, we let it fill the gap immediately by proposing, as commands 136 and 137, a special “no- op” command that leaves the state unchanged. (It does this by executing phase 2 of instances 136 and 137 of the consensus algorithm.) Once these no-op commands have been chosen, commands 138–140 can be executed.
- 接受客户请求的下两个命令
- 特殊的“no-op”命令
第二个选项已经提到。
我的问题是关于第一个问题。在我看来，采取接下来的两个命令将违反一致性，因为稍后发生的实例可能具有较小的序列号。那为什么它仍然是合法的？
由于所有客户端都看到相同的一致结果，因此不违反一致性。所以没有违反算法不变量。
如果您考虑所有命令都来自单个客户端的场景，那么与客户端发送值的顺序相比，这将是重新排序。如果单个客户端是多线程的，并且如果它流式传输多个并发请求，则重新排序可能是无害的（或无害，取决于应用程序语义）。如果您认为领导者使用 noop，那么它实际上只是丢弃一些消息，这些消息可能对客户端无害，这取决于它流式传输的值的顺序。这取决于应用程序。
如果您考虑所有值都来自不同客户端的情况，那么情况就自然得多。在不利条件下，会发生一些重新排序。然而在正常情况下 运行 不会发生。重新排序看起来就像一些值 "took longer than normal" 由领导者修复，而后来的值由其他客户端发布 "ran faster"。
第一个选项和第二个选项相同。
比如在这个例子中，客户端要写4条命令，
a = 1
b = 2
c = 3
d = 4
第一个选项，结果可能是
a = 1
e = 5
f = 6
d = 4
而在第二个选项中，结果是
a = 1
noop
noop
d = 4
所以，这两个结果都是非法的。这个问题跟丢失数据和违单没有区别
那么正如@simbo1905所说，multi-Paxos不承诺FIFO顺序。
如果136、137、138有顺序关系，比如它们是一个TCP连接发送的，客户端用管道发送这三个命令。客户有责任按照先进先出的顺序进行这些操作。如果客户端有很多发出的命令，并且客户端想要FIFO客户端顺序，客户端需要从第一个失败的命令开始重试命令。
另一种情况是它们是通过不同的连接发送的。由于是通过不同的连接发送的，服务器无法保证 FIFO 客户端顺序。 136、137操作失败，任何场景都可以，这两个操作可以成功也可以失败。如果客户端想知道结果，客户端应该重试操作。
在这两种情况下，承诺订单的责任是客户端，而不是服务器。
所以我觉得你误解了一致性的意思，一致性和顺序没有关系。这是关于安全和活跃度
Paxos算法(http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf)中有一点我没看懂。关于如何处理间隙，本文描述了以下两种方法：
The leader, as well as any other server that learns all the commands the leader knows, can now execute commands 1–135. However, it can’t execute commands 138–140, which it also knows, because commands 136 and 137 have yet to be chosen. The leader could take the next two commands requested by clients to be commands 136 and 137. Instead, we let it fill the gap immediately by proposing, as commands 136 and 137, a special “no- op” command that leaves the state unchanged. (It does this by executing phase 2 of instances 136 and 137 of the consensus algorithm.) Once these no-op commands have been chosen, commands 138–140 can be executed.
- 接受客户请求的下两个命令
- 特殊的“no-op”命令
第二个选项已经提到
我的问题是关于第一个问题。在我看来，采取接下来的两个命令将违反一致性，因为稍后发生的实例可能具有较小的序列号。那为什么它仍然是合法的？
由于所有客户端都看到相同的一致结果，因此不违反一致性。所以没有违反算法不变量。
如果您考虑所有命令都来自单个客户端的场景，那么与客户端发送值的顺序相比，这将是重新排序。如果单个客户端是多线程的，并且如果它流式传输多个并发请求，则重新排序可能是无害的（或无害，取决于应用程序语义）。如果您认为领导者使用 noop，那么它实际上只是丢弃一些消息，这些消息可能对客户端无害，这取决于它流式传输的值的顺序。这取决于应用程序。
如果您考虑所有值都来自不同客户端的情况，那么情况就自然得多。在不利条件下，会发生一些重新排序。然而在正常情况下 运行 不会发生。重新排序看起来就像一些值 "took longer than normal" 由领导者修复，而后来的值由其他客户端发布 "ran faster"。
第一个选项和第二个选项相同。
比如在这个例子中，客户端要写4条命令，
a = 1
b = 2
c = 3
d = 4
第一个选项，结果可能是
a = 1
e = 5
f = 6
d = 4
而在第二个选项中，结果是
a = 1
noop
noop
d = 4
所以，这两个结果都是非法的。这个问题跟丢失数据和违单没有区别
那么正如@simbo1905所说，multi-Paxos不承诺FIFO顺序。
如果136、137、138有顺序关系，比如它们是一个TCP连接发送的，客户端用管道发送这三个命令。客户有责任按照先进先出的顺序进行这些操作。如果客户端有很多发出的命令，并且客户端想要FIFO客户端顺序，客户端需要从第一个失败的命令开始重试命令。
另一种情况是它们是通过不同的连接发送的。由于是通过不同的连接发送的，服务器无法保证 FIFO 客户端顺序。 136、137操作失败，任何场景都可以，这两个操作可以成功也可以失败。如果客户端想知道结果，客户端应该重试操作。
在这两种情况下，承诺订单的责任是客户端，而不是服务器。
所以我觉得你误解了一致性的意思，一致性和顺序没有关系。这是关于安全和活跃度