imaffe commented on issue #2056: URL: https://github.com/apache/rocketmq/issues/2056#issuecomment-636621667
> 我感觉你的反对票的目的是，如果有任何一个follower在投票过程中发现自己的日志记录比candidate新，那么这个candidate就应该退化为follower。是这个意思吗 问题是这样实现的话就已经不是raft协议了，我认为这样实现是不对的，会导致liveness甚至是safety的问题。 考虑这样一个情况 node 7 在 term = 6 期间把一条log复制到了 node 6 上，然后node 7 宕机。 这个时候，如果按照你的实现，只有可能node 6 能成为candidate，因为node 1 2 3 4 5 的日志记录都比node 6 的要旧。 可是这样的话假设node 1 具有最短的timeout间隔而node 6 具有最长的timeout间隔。这也就意味着即使node 1 本应最先成为leader，却因为多出来的条件而导致不能成为leader，就违背了任意不同node采用不同timeout时长的初衷了。 更重要的是这样做并没有什么意义，candidate就没有必要比每一个node的日记记录都要新，才用你说的反对票机制并不能带来额外的好处 > 这是为了避免发生新leader在当选后刚提议消息只被少数结点获取就跟着这些少数结点永久性宕机这种情况时，永久性不能恢复生产的及其特殊情况 我不认为这种情况会在raft协议中出现，如果只是少数派节点宕机那么raft一定能选出一个leader来继续工作，如果您能提供一个详细的example说明为什么会出现少数节点宕机会导致永久不能恢复生产的话，非常感谢～ 至于新的提案里的loggedTerm, loggerIndex 在raft里就有这样的概念， 叫lastLogTerm 和 lastLogIndex， termWated 就是 raft 里的 term， 不同的是raft 里的term是 “当前节点所见到过的最大term“。 总而言之，新的提案对raft的核心步骤做出了修改，将一个原本宽松的条件升级成了一个更为严格的条件，必须得证明这样做不会影响livenss我们才能讨论实现的可能。（safety 被损害的可能性不大，毕竟让leader选举更严格了） ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
