Tencent / phxpaxos

The Paxos library implemented in C++ that has been used in the WeChat production environment.
Other
3.36k stars 863 forks source link

提议chosen的优化建议 #165

Open zhengsunf opened 5 years ago

zhengsunf commented 5 years ago

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

lynncui00 commented 5 years ago

这个“优化”看似减少了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 commented 4 years ago

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