分布式架构中的共识机制——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在对外工作。