提议chosen的优化建议

[zhengsunf]

在3台机器的时候，发送accept之前，proposer自己先accept，成功后发送，acceptor接受到后，只要自己accept，就认为这个proposal被chosen。

[lynncui00]

这个“优化”看似减少了chosen的耗时，但实则对耗时降低没有任何帮助，反而会降低吞吐，且无法进行成员变更。这里解释一下为什么，假设A是Proposer，B是acceptor。 几个耗时的假设：

1. 写磁盘耗时 1ms
2. rtt 2ms

我们来看看加了这个”优化“后的情况是怎样的。

1. A 自己先 accept， 写磁盘消耗 1ms，网络发送 accept 请求给 B 消耗 1ms
2. B 收到 accept 请求写磁盘消耗 1ms， ”优化”之后 B chosen。然而 B chosen 实际并没有任何作用，因为A 不知道也无法发出下一个请求， 所以还是得然后发送 accept reply 给 A 消耗 1ms。
3. A 在 4ms 后收到 accept reply， 然后发起下一个请求，如此循环。

而“优化之前” accept 写磁盘和发请求给 B 是并行的，一次请求只需要 3ms。在 Instance 串行运作的情况下，明显吞吐是下降了。

[piboye]

这样的实现由问题， 破坏了paxos 的协议，因为accept 也是有可能被拒绝的。 因为 acceptor 接受了更高的 propsal_id, 就会拒绝这个老的propsal的 accept请求。