lynn

SIGPIPE如果不处理的话，在出现一些网络错误的时候，会导致进程被杀。 具体可以看一下SIGPIPE的触发机制。

pipeline和batching都是解决节点之间高延时下的吞吐问题。 这里要看不同IDC之间的延时如何，在同城多IDC下，batching几乎可以达到高吞吐要求。 至于你的情况可能是异地多IDC， 由于phxpaxos不支持pipeline，唯一可以调整的就是batching参数（通过node.h的SetBatchCount和SetBatchDelayTimeMs），通过期望吞吐与节点间延时的关系，来调整。 增加pipeline后代码可理解性，维护成本都会大幅提高，这也算是一个权衡。

We learn 《The Part-Time Parliament》 before 《Paxos Made Simple》, so we don't think our implementation is wrong. Of course, it is difficult to achieve 0 bugs in specific implementations, but...

这个“优化”看似减少了chosen的耗时，但实则对耗时降低没有任何帮助，反而会降低吞吐，且无法进行成员变更。这里解释一下为什么，假设A是Proposer，B是acceptor。 几个耗时的假设： 1. 写磁盘耗时 1ms 2. rtt 2ms 我们来看看加了这个”优化“后的情况是怎样的。 1. A 自己先 accept， 写磁盘消耗 1ms，网络发送 accept 请求给 B 消耗 1ms 2. B 收到 accept 请求写磁盘消耗 1ms， ”优化”之后 B chosen。然而 B...

经验上建议将热启动耗时控制在小于租约时间，这样之前的master会优先继续成为master。 指定master的方法不可行，一旦有了租约，必须得严格遵守租约。

这里定时器和ioloop处理的正常消息是协同工作，不可分割的。什么是协同工作？意思就是定时器的产生源是来自于正常处理的消息，所以当定时器处理完所有的定时事件之后，在处理正常消息之前是不会有新的定时事件产生的，可以理解为定时器的生产和消费是在同一个线程上的。而你似乎要解决的问题是支持跨线程的纯定时器问题？这个完全则是另外一个问题了。

@lemon0910 您好，这里收集的是跟PhxPaxos直接有关的文章。

@buptmiao 感谢，已添加到WIKI。

@chenneal 非常感谢，已添加到WIKI。

@zhengcf 谢谢，已添加到WIKI。