分布式架构中的共识机制——Redis-RAFT

在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正式竞选成功。一旦第一轮竞选完成,意味着系统达到稳态。
followers返回竞选结果

接下来在集群运行过程中,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在对外工作。

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

推荐阅读更多精彩内容