Redis哨兵模式下如何进行故障转移

前言

  Redis哨兵模式下分为数据节点和哨兵节点(不存储数据)，前者至少一主一从，后者至少一个哨兵，所以总共至少三个节点。本文章讲述，当主节点发生故障时，哨兵节点将从节点转换为主节点的流程。

主观下线和客观下线

  主观下线：
  每个哨兵节点会每隔1s向主节点、从节点、其他哨兵节点发送ping命令，若超过down-after-milliseconds(配置文件中的配置，单位毫秒)没有有效回复，那么该哨兵节点认为对方是主观下线的。

  客观下线：
  哨兵节点主观下线的是主节点时，该哨兵节点向其他哨兵节点发送sentinel is-master-down-by-addr命令(runid参数等于"*")，征求意见：如果超过quorum(配置文件中的配置)个数的回复是下线了，那么该哨兵会认为主节点是客观下线的。

哨兵节点选举leader

  哨兵节点认为主节点是客观下线时，哨兵节点之间会做一个领导者选举，选出一个节点作为领导者(leader)进行故障转移的工作。

1. 哨兵节点认为主节点是客观下线时，会向其他哨兵节点发送sentinel is-master-down-by-addr命令，要求将自己设置为leader
2. 收到命令的哨兵节点，如果没有同意过其他哨兵节点的sentinel is-master-down-by-addr命令(runid参数等于哨兵节点的runid)，就同意该请求，否则拒接
3. 发送命令的哨兵节点发现自己的票数已经大于等于quorum和哨兵节点数量/2+1，那么它将成为领导者
4. 上述过程没有没有选举出leader或者选举出多个，将重新进行一次选举

 注：sentinel is-master-down-by-addr有4个参数：ip、port、current_epoch、runid。前2个是主节点的ip和端口号，current_epoch表示纪元，是个整数，代表一次选举，进行下一次选举时该值+1；runid有2种值，为"*"时表示向其他哨兵节点询问主节点下线的判断，为当前哨兵节点的runid时，希望对方同意自己成为leader的请求。

leader故障转移的流程：

1. 从节点中过滤掉"“不健康”(主观下线、断线)、5s内没有回复哨兵节点的ping命令、与主节点失联超过10*down-after-milliseconds；然后按照优先级 -> 复制偏移量最大(复制最完整) -> runid最小的逻辑(先按照优先级找，没找到，再按照复制偏移量找，找到了就选择这个从节点了，依次类推)来选择一个从节点
2. 对选出来的从节点，执行slaveof no one命令让其成为主节点
3. 向剩余的从节点发送slaveof ip port命令，让它们成为新主节点的从节点
4. 哨兵节点对旧主节点保持关注，当其恢复后发送slaveof ip port命令将其设置为从节点，并去同步数据