zhangyixin1222 commented on issue #2056: URL: https://github.com/apache/rocketmq/issues/2056#issuecomment-636449082
> > > > 因少部分结点认可过更大的选举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 进行投票 > > 这里面分区会发生在什么时候呢？ > > 非常感谢~ raft协议中leader履行职责中在广播日志提议后如果收到了多数响应会发出提交指令的，并向客户端反馈结果（这跟zk是一样的）。而且协议本身明确了收到多数赞同票就可以作为leader，即即使567结点没赞同，但只要1234多数结点赞同就会进入leader状态（因为raft或zk的一致性在于保证提交的消息及多数认可的提议绝对不丢失，不会因为只有少数结点存在着提议日志就因噎废食）。因为通过pre-vote获取候选人资格这一前提保证了候选人持有多数结点具有的最新日志。结点7如果快了一拍，在结点234中任意一个结点收到结点1提议消息之前收到选票也是会获取leader资格的（这仅会使的结点1发现提议不收认可自动切换到寻找leader状态），该情况下结点7就进入leader状态。新选leader会将新term的空日志跟所知的旧term的记录日志一次性提议保障不落下之前的有效提议（即已提交的或多数认可的提议）。退化为follower在于自身已经感知到自身所持日志纪录并非最新，在因为未获得最新选举term不必要进入follower。 ---------------------------------------------------------------- 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]
