在RAFT算法中,有三个角色
- follower(跟随者)
- candidate(候选人)
- leader(领导者)
这类共识算法的核心点在于少数服从多数,当集群中不存在leader的时候,可以用上面说到的最简单的办法随机指定。在RAFT算法中,每个redis节点上都有一个计时器,它们的计时时间就是随机生成的(50ms-150ms),集群中的redis nodes各自生成一个计时器。
初始状态
开始倒计时,第一个到期的redis从follower变成candidate,开始像其他节点发送竞选消息,先到先得,第一任leader就这样产生了。每个redis节点都维护了一个变量term,但一个redis从follower变成candidate后,它会将自己本地的term+1,同时把+1后的term发给其他节点。
candidate发送竞选消息
当follower收到了一个竞选消息,它会拿自己的term和message中的term进行比较,如果自身term小于message的term,则接受candidate为leader。follower会以response的形式告诉candidate,竞选成功的消息。当投票过半数(包括candidate自己的一票),candidate正式竞选成功。一旦第一轮竞选完成,意味着系统达到稳态。
接下来在集群运行过程中,leader会在cluster-node-timeout(?)时间内发送心跳检测到各个followers,表明自己仍然存活。如果leader因为网络原因或内部原因挂了。此时余下followers会再次发起选举。选举过程和上面描述的一样。
重新发生选举
看到这里可能出现一个问题,如果新一次选举完成,但是原始的leader又恢复了,对于整个集群来说,岂不是出现了两个leader。这就是通常所说的脑裂现象。对于这种情况redis提供了两个配置:
min-slaves-to-write:主节点可以写入的最少从节点数
min-slaves-max-lag:主从进行数据复制时,从库给主库发送ACK消息的最大延迟秒数。
它意味着一旦leader可以写入的followers数目小于min-slaves-to-write或者follower返回给leader复制的ack消息超过了min-slaves-max-lag时,当前leader不能写入。这样即便原始leader还能功能,也无法继续接收客户端的写入请求,对于整个集群来说,还是只有一个leader在对外工作。
网友评论