imaffe commented on issue #2056: URL: https://github.com/apache/rocketmq/issues/2056#issuecomment-636441247
> > > 因少部分结点认可过更大的选举term导致当选leader所广播消息暂时不受自身认可 > > > > > > 我觉得这可能不是一个问题，感觉这是raft协议期望发生的事情。 > > 可以再详细讲一下为什么 > > > 情况2:结点【5，6，7】等少数结点接受结点7该term=7的选举，结点7未作为leader执行职责，但此时因为【5，6，7】结点已经认可了term=7的任期，会导致结点1以term=6所发送提议无法被接受，但结点1因为已经此实确实获取多数结点认可，在提议被多数接受后会进行提交。可惜目前所用的raft协议未考虑该情况下的处理方案。 > > > > > > 这种情况出问题了嘛，非常感谢～ > > 因为这样会引发部分结点对真实leader（当选leader结点已受大多数结点认可并履行职责）的不认可导致的一定时期内的分区问题。该分区问题本来可通过无条件接受提交指令（能发出提交指令肯定说明已经受到了多数结点接受）来得以快速恢复 可以详细解释一下什么是提交指令嘛，我记得raft里没有提交指令。提交与否是由某个log是否在当前term内copy到多数节点上决定的。term =6 的提议如果在**term = 6 期间**被复制到了多数节点上，那么这个值就一定被commit了，不需要再做额外的请求使其commit。 我感觉您描述的应该不是一个safety的问题，而是一个performance的问题。并且您描述里的分区，具体指的是什么呢？node 7 肯定不可能成为 leader， 而 - node 1 要么永远都联系不到 5，6，7， 因此node 1 一直都不知道有一个term 为 7 的node，因此node 1 可以继续成为leader 并正常运行 - node 1 可以联系到 5 ，6 ， 7 因此退化成为follower，把自己的term 也改成 7 。 如果node 7 一直不能成为 leader， 那么某个follower 会 timeout 为candidate 并使用 term 8 进行投票 这里面分区会发生在什么时候呢？ 非常感谢~ ---------------------------------------------------------------- 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]
