Raft实现报告(二)

简介: Raft实现报告(二)

Raft实现报告(二)

Leader election

Raft使用心跳机制去触发Leader选举,当server开启时就作为follower运行,一个server会一直保持这种状态只要他能一直收到来自Leader或candidate的有效RPC。Leader会发送周期性的心跳(AppendEntries RPC,将该条RPC中的log条目变为空即可)给所有的follower去维持他的主导权,如果一个follower在一段时间内没有接收到这种有效交流,这种时间叫做选举超时(election timeout),该follower就会假设当前已经没有有效的Leader在了,就会发起一轮选举去选择新的leader。

follower在开始一场新的选举的时候,会增加自己的term(在论文中提到,raft系统中的逻辑时钟)然后转变为candidate状态,然后他会投票给自己,然后并行对集群中所有server发出RequestVote RPC请求。该candidate会持续这种状态直到以下几种情况发生之后转变。

  • 该candidate赢得了选举
  • 其他server赢得选举并变成leader
  • 一段时间过去了之后,没有产生leader也就是分票了

下面就来讨论这几种情况,还有一个问题就是:

以前提到会出现的一种情况,在一个时间段内发生的事请,可能server并不知道,那这个时候如果他觉得已经收不到心跳了,开启Leader选举,但与此同时,现有时间段的Leader还存在并且与其他server保持良好沟通,这个时候怎么办?因为为了保持选举安全,每个时间段至多只有一个leader。第二种情况会解释这个问题。

第一种情况:如果集群中绝大多数服务器都投票给了candidate,那么他就会赢得这场选举,每一个server最多只能投一个candidate在这段时间内,先到先服务的基础原则。一旦candidate赢得选举,它就会变成leader,然后他就会发送心跳消息给所有的服务器建立管理,同时避免新选举的发生。

第二种情况:在等待投票的时候,candidate可能会收到AppendEntriesRPC(我现在先理解为更新状态RPC请求)来自其他server(A)表达server(A)此时要成为Leader了,如果Leader(server A)的term(这里是逻辑时间记录变量)最后跟candidate当前记录的term一样大,那么candidate会意识到该leader是合法的,承认server(A),然后candidate会变回follower状态。如果RPC中记录的term小于了candidate的当前term,candidate将会拒绝这次RPC更新,继续维持candidate状态等待投票

换句话说,candidate在等待过程中,如果收到比他term新的消息,说明结果已经出来了,leader产生,其他的candidate胜出,自己选举失败,变回follower。如果更新信息比较旧,则继续选举等待投票。

论文中没有提到一个candidate如何感知自己获得了更多的票啊?

第三种情况:第三种可能的结果就是candidate们没有一个人赢下或者失败,如果许多的follower同时变成了candidate。他们都会投给自己,产生分票,所以没有人会获得更多的选票,但这种情况发生的时候,每一个candidate将会超时,然后产生新一轮选举通过增加他的term(后来我觉得term也可以理解为阶段,集群中的所有服务器记录当前阶段,就像git中提交的点。如果term的数值非常小,那他肯定很旧,并且大家再每次选举时,都会更新到下一阶段,也就是term单调递增)然后发起新的RequestVote RPC请求,前文说到,在一个时间段中只会产生一种结果,要么有leader大家相安无事,要么没选出来leader,新的leader选举将会发生在新的时间段(term我觉得就是时间段的抽象)中。

并且如果没有额外的干预,这种分票情况肯定会无限的重复下去。

如何避免分票

然后!Raft使用了随机的选举超时机制确保分票情况很少发生,即便发生也会很快解决。首先,为了防止分票,选举的超时时间会从固定间隔的事件中随机抽取(比如150-300ms之间的时间),所以在大多数情况下,只有一个server超时,不会发生大家都超时同时选举的情况,或是少发生。他会赢下选举然后发送心跳给其他server,在这些server超时之前。并且,每个candidate会重置他的超时时间(reset election timeout)在以下一次选举的时候,也就是说,不仅超时时长是随机的,并且在每次选举前还会改变。这就会减少新一轮选举的分票情况发生。

论文中提到的RPCs

  • AppendEntries RPC: Leader调用来复制日志条目,同时用于心跳机制
  • RequestVote RPC: candidates调用来收集投票

Question

  1. 发起leader选举的follower,投票给自己是必然的吗?
  2. candidate如何感知自己的票已经足够多了可以成为leader?

reference

https://pdos.csail.mit.edu/6.824/papers/raft-extended.pdf


相关文章
|
存储 算法
Raft实现报告(七)
Raft实现报告(七)
|
存储 安全
Raft实现报告(14)
Raft实现报告(14)
|
存储 索引
Raft实现报告(五)
Raft实现报告(五)
|
存储 索引
Raft实现报告(15)
Raft实现报告(15)
|
开发工具 git
Raft实现报告(四)
Raft实现报告(四)
|
存储 索引
Raft实现报告(16)
Raft实现报告(16)
|
算法 安全
Raft实现报告(13)
Raft实现报告(13)
|
Linux
Raft实现报告(18)
Raft实现报告(18)