理解raft(2) proVote

问题

FollowerA在选举超时后,没收到心跳, 然后会发起选举,并转为Candidate。每次发起选举时,会把Term加一。但是由于网络隔离,或者说其他的大部分节点还正常连着leader,因此它不会被选成Leader,可是也不会收到Leader的消息,所以会一直不断地发起选举。Term会不断增大。

一段时间之后,这个节点的Term会非常大。在网络恢复之后,这个节点会把它的Term传播到集群的其他节点,导致其他节点更新自己的term,变为Follower。然后触发重新选主,但这个旧的Follower_2节点由于其日志不是最新,并不会成为Leader。整个集群被这个网络隔离过的旧节点扰乱,显然需要避免的。

举例:

有A,B,C,D,E五台机,A是leader,某个时刻A,B出现了分区,但是A,C,D,E以及B,C,D,E都可以互相通信。B在超时没有收到心跳后,把term+1,发起leader选举,如果这段时间C,D,E没有写入更新的日志,由于B的term更大,就会被选为leader,A在后面的RPC中因为自己的term较小也会被降为follower。问题是A成为follower之后又会按照上面B的方式发起选举成为leader,同理B也会再次发起选举,这样周而复始会造成很大的网络开销。

解决方案

上面描述的是非对称网络分区的情况,如果不做特殊处理,会反复出现新的选举,打断正常的 IO,这里一般可以通过 pre-vote 解决,例如,每次发起选举之前,先发起 pre-vote 如果获得大多数 pre-vote 选票,再增大 term 发起选举 vote 投票。为了避免问题描述的情况,其他节点只需要在收到 pre-vote 请求时,判断一下 leader 是否还在,一般实现上,判断最近和 leader 是否正常通信,如果有,那么说明 leader 正常在线,直接拒绝 pre-vote 即可。

或者用租约,follower只要在租期(属于某个leader)内,如果不是强制转移leader,那么就忽略term大的votemsg。

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 最近看了Ongaro在2014年的博士论文《CONSENSUS: BRIDGING THEORY AND PRAC...
    山本聪阅读 4,636评论 3 11
  • 前言 这是一篇学习raft论文的总结,主要是对看论文过程中难以理解的几个问题的记录。系统性的讲解还是得看raft论...
    asmer阅读 14,597评论 3 38
  • 最近看了Ongaro在2014年的博士论文《CONSENSUS: BRIDGING THEORY AND PRAC...
    山本聪阅读 6,915评论 2 19
  • 10月3日,我和爸爸妈妈一起,到襄阳古隆中游玩,目睹一下诸葛亮的家乡。 才下火车,又上公交,人还在车上,心早已飞向...
    王亿健阅读 503评论 0 2
  • 我们不知道死亡会在什么时候来临,因为它随时都可能到来,我第一次看到西藏生死书里说“在活着的时候准备死亡”时特别触动...
    9875a59cf4af阅读 256评论 0 0